K8s Architecture

The cluster at a glance

Kubernetes is a declarative system: you describe the desired state — "run three copies of this app" — and controllers work continuously to make reality match. Everything you create is an object stored in etcd, and every object has a spec (what you want) and a status (what exists). Internalize that loop and the rest of Kubernetes starts to feel obvious.

Pods: the smallest deployable unit

You never deploy bare containers — you deploy Pods. A Pod is one or more containers that share a network namespace, an IP, and storage volumes. They are born, do work, and die; you never repair a Pod, you replace it. That ephemerality is a feature: it forces you to externalize state and logs instead of treating servers as pets.

• Sidecars: helper containers in the same Pod — log shippers, proxies, config reloaders.
• Init containers: run to completion before the main containers start — migrations, dependency waits.
• Pods get their IP from the cluster CNI; the IP dies with the Pod, which is why you never address Pods directly.

Labels and selectors: the grouping mechanism

Almost every Kubernetes relationship is built on labels — key/value tags on objects — matched by selectors. A Service finds its Pods by label selector; a Deployment manages Pods the same way. Labels are also how you slice costs, route canaries (version: v2), and scope network policies. Get labeling conventions right on day one — retrofitting them later is painful.

Deployments and ReplicaSets: declaring desired state

A Deployment says "keep N replicas of this Pod template running, and roll out changes this way." Under the hood it manages a ReplicaSet, which is the dumb counter that actually maintains the replica count. Separating the two is what enables rollouts: a new ReplicaSet scales up while the old scales down.

• Rolling updates (the default): replace Pods gradually, honoring maxUnavailable and maxSurge.
• Recreate: tear everything down, then start fresh — for stateful or singleton workloads.
• Rollback: kubectl rollout undo — because every deploy should have an exit plan.

Probes: telling Kubernetes what "healthy" means

Kubernetes can't see inside your app, so you tell it how to check:

• readinessProbe: is this Pod ready for traffic? Failing Pods are removed from Service endpoints — no restarts, just no traffic.
• livenessProbe: is this Pod alive? Failures trigger a container restart.
• startupProbe: for slow-starting apps — disables liveness/readiness until the app has booted.

Services: stable networking for ephemeral pods

Pods die constantly, so Kubernetes gives you a Service: a stable virtual IP and DNS name (my-svc.my-ns.svc.cluster.local) that load-balances across the current healthy Pods. Types:

• ClusterIP (default) — reachable only inside the cluster. The right default for most things.
• NodePort — exposes the Service on a static port of every node. Useful for debugging, rarely for production.
• LoadBalancer — provisions a cloud load balancer pointing at the Service.

Ingress: getting traffic in

One step above Services: Ingress routes external HTTP/S traffic by host and path to Services, handling TLS termination. The Ingress resource is just config — you also need an Ingress controller (NGINX, Traefik, HAProxy, or a cloud one) actually running in the cluster to enforce it. Pair it with cert-manager and TLS certificates become fully automatic.

Resources, requests, and autoscaling

Every container should declare requests (what the scheduler guarantees) and limits (the ceiling). Without requests, the scheduler is flying blind and nodes get overcommitted; without limits, one greedy container can starve its neighbors. The combination also drives the Horizontal Pod Autoscaler, which scales replica counts on CPU, memory, or custom metrics — the foundation of "scale on demand."

ConfigMaps and Secrets

Configuration doesn't belong in container images. ConfigMaps hold non-sensitive config (feature flags, file mounts); Secrets hold credentials, base64-encoded and ideally encrypted at rest via etcd encryption. Mount them as files or inject as environment variables — files are better for anything that might rotate without a restart.

Storage: volumes that outlive Pods

Container filesystems are ephemeral, so persistent data needs PersistentVolumes: cluster-level storage provisioned by a StorageClass (EBS, Azure Disk, Ceph…), claimed by Pods through PersistentVolumeClaims. The claim is the contract — developers ask for "10Gi, fast" and the cluster figures out the rest. Remember the access modes: ReadWriteOnce vs ReadWriteMany decides whether your data can be shared.

Jobs and CronJobs

Not everything is a long-running service. Jobs run Pods to completion — migrations, batch processing, one-off scripts. CronJobs schedule them like cron. They get the same scheduling, resources, and observability as everything else, which beats a dusty crontab on a forgotten VM every time.

Namespaces: one cluster, many teams

Namespaces partition a cluster into virtual workspaces — dev, staging, prod, or per-team. They scope names, and combined with ResourceQuotas, LimitRanges, RBAC, and NetworkPolicies they give you real multi-tenancy: teams can't step on each other's resources, and a runaway namespace can't eat the cluster.

The journey of a request

Put it together: a request hits the Ingress controller, which routes by host/path to a Service; the Service load-balances to a ready Pod IP via kube-proxy; the Pod's containers — placed by the scheduler, configured by ConfigMaps, storing state in PVCs — answer. Every hop is declarative, replaceable, and observable. That's the whole architecture: simple parts, composed.