Kubernetes container orchestration

Kubernetes (K8s) is a container orchestration system: it manages containers across a group of servers, deciding where containers run, how many run, what happens when they die, how updates roll out, and how traffic reaches them.

Why it exists. On one machine, Docker Compose is enough: you write down which containers run where by hand. Once machines and containers multiply, hand assignment stops working: a machine dies and its containers need a new home, traffic grows and more copies are needed, and nobody can track every container by hand. Kubernetes replaces hand assignment with declared desired state plus reconciliation loops: you declare what you want, the system continuously drives reality toward it.

The cluster at a glance

A cluster is one control plane plus a group of servers. Traffic from users and management traffic from operators travel on two separate paths: user traffic never passes through the API Server, and management traffic never passes through Ingress.

Container

A container is the Docker-style container: one packaged process with its own filesystem, isolated from other processes by Linux namespaces and cgroups. Kubernetes does not run the Docker daemon itself; it runs containers through a container runtime, by default containerd. Docker remains the most common tool for building container images.

Pod

A Pod is the smallest deployable unit: a group of containers that share one IP address and shareable storage volumes, scheduled as a whole onto one Node, never split across Nodes. The scheduling unit must be the Pod rather than the single container, because the scheduler accounts resources for the whole group: two containers asking 1 core each look placeable separately but need 2 cores together. Containers that must share network or storage and live and die together belong in one Pod; the classic shape is the sidecar pattern, an application container plus a log-shipping or proxy sidecar. Independently scalable services stay in separate Pods.

Pod to Node is many-to-one, not one-to-one. One Pod lands on exactly one Node; one Node runs many Pods.

Node, kubelet, kube-proxy, CNI

A Node is one machine in the cluster, physical or virtual. Every Node runs three node-level components. kubelet is a system process on the Node, the Node's agent: it is not a Pod and not a container. It starts and stops containers on behalf of the control plane, runs probes, and reports status. kube-proxy writes the traffic-forwarding rules for Services on the Node. The Container Network Interface (CNI) plugin assigns Pod IP addresses and connects Pod networks across Nodes.

Control plane

The control plane is the cluster's brain. The API Server is the single entry point: all reads and writes pass through it, and components never talk to each other directly. etcd is a distributed key-value store holding the cluster's desired state; the other control-plane components are stateless and recover from etcd. The scheduler decides which Node a new Pod lands on. The controller manager is a set of controllers, each reconciling one concern: the Deployment controller manages ReplicaSets, the ReplicaSet controller manages Pod counts, the Node controller watches Node health, the Endpoints controller maintains the Endpoints table. In cloud environments a cloud controller handles provider-specific work such as load balancers and Node lifecycles.

Desired state and reconciliation

Everything in Kubernetes is declarative: you submit objects such as Deployments and Services, and controllers run reconciliation loops that push actual state toward the declared desired state. A Deployment does not manage Pods directly; it manages a ReplicaSet, and a rolling update is one ReplicaSet scaling down while its replacement scales up.

Scheduling

Scheduling is a one-time decision. Once a Pod is bound to a Node it stays there; Kubernetes does not move running Pods around for balance by default. Placement changes only when a Pod is recreated: Node failure, eviction, rolling update, or scale-out producing new Pods. Traffic alone never moves a running Pod; traffic changes Pod counts through scale-out, and new Pods get new scheduling decisions.

The scheduler reads the Pod definition, which declares everything in advance: each container's resource request, volumes, node selectors, affinity, tolerations, and ports. It sums the ordinary containers' requests into the Pod's total, filters out Nodes that fail any condition (insufficient remaining resources, an unmountable volume, a taint, an affinity rule), then scores the survivors and picks the best. Temporary volumes travel with the Pod and do not constrain scheduling; persistent volumes do, because a disk may exist only in one availability zone or attach only to certain Nodes. Two boundaries matter: the scheduler accounts declared requests, not real-time usage, so an understated request packs too many Pods onto one Node; and a limit caps runtime usage but plays no part in scheduling.

Probes

Probes are configured on containers, written in each container's Pod definition, and executed by the Node's kubelet. A readiness probe decides whether the container enters the Endpoints table: a container that has started but is not ready receives no traffic. A liveness probe decides whether a dead container is restarted: it restarts containers but never touches the table. Readiness gates traffic; liveness gates restarts.

Service and discovery

A Service object is the whole addressing configuration you have to write, once per service: a name, a selector matching a group of Pods, a port callers use, and a targetPort the container actually listens on. The default Service type is ClusterIP, valid only inside the cluster. Callers write the name, never an IP, a Node, or a Pod: the name never changes.

Behind the name, three steps run: the cluster Domain Name System (DNS) service, CoreDNS, resolves the name to a ClusterIP; the ClusterIP is a virtual IP that belongs to no physical network card, so different Services can share port numbers without conflict; kube-proxy forwards traffic by the Endpoints table to a ready Pod. When a Pod dies, moves Nodes, or changes IP, the Endpoints table updates and callers notice nothing, because they only know the name.

Workload objects

A ReplicaSet keeps a specified number of Pod replicas running: it replaces dead Pods and deletes extras. Its replicas are equal peers, every one serving traffic, with no primary and no standby. High availability and capacity are two effects of the same mechanism: one dead replica leaves the rest serving, and N replicas share the load. A ReplicaSet manages counts only, not versions, and you normally never create one directly: you create a Deployment, which creates and manages it. A StatefulSet is for stateful services: stable names, stable storage per replica, ordered start and stop; a replacement Pod reattaches the same disk. A DaemonSet runs exactly one Pod on every matching Node: one per Node, following Node count rather than a replica count; monitoring agents and log collectors are the typical use. A Job runs a task to completion and stops; a CronJob is its scheduled form.

Ingress and inside versus outside

An Ingress object is pure configuration: a rule mapping a host and path to a Service. It forwards no traffic by itself. The Ingress Controller is the real gateway: a ready-made component, usually a Deployment of Nginx or Traefik Pods, whose control loop watches Ingress objects and regenerates its own configuration, while its data plane receives external traffic and forwards it. A fresh cluster ships no Ingress Controller; you install one once, after which it runs as an ordinary workload managed by Kubernetes itself.

External exposure is opt-in; internal is the default. A Service with no Ingress rule is unreachable from outside and needs no extra internal configuration. Service-to-service traffic never passes through Ingress: it goes east-west, calling the other Service's name directly, resolved by cluster DNS and forwarded by kube-proxy. Two honest qualifications: Pods can reach each other by default, so real isolation needs NetworkPolicy, which requires a supporting network plugin; and management traffic (kubectl) travels through a bastion host, a VPN, or a provider private endpoint, not through Ingress.

Adding a Node

Adding a Node is a hot operation: the cluster keeps running, nothing restarts, and existing Pods are untouched. With kubeadm, the cluster's own bootstrap tool, the control plane issues a join command carrying three things: the API Server address, a short-lived bootstrap token acting as a one-time invitation, and the control-plane certificate hash so the new Node can verify it talks to the genuine control plane. The new Node's kubelet uses the token for its first connection, then completes Transport Layer Security (TLS) bootstrapping: it requests a certificate, and from then on authenticates with its own Node certificate while the token expires. Node identity carries Node-only permissions, not administrator permissions. Managed clusters hide this behind a provider API: add Nodes to a Node pool and the provider performs the join.

Once registered through its Node object and kubelet heartbeats, the new Node is immediately schedulable, and empty Nodes score well, so new Pods land there first. But existing Pods do not move: the relief for a tight service comes from adding Nodes plus scaling replicas, manually or through the HorizontalPodAutoscaler (HPA), which adjusts replica counts by CPU, memory, or custom metrics. New replicas land on the new Nodes and the load spreads.

Global and edge

Kubernetes handles traffic inside one cluster; global traffic steering lives above it. A user reaches a global entry point first, which picks a cluster, and only then does Kubernetes routing begin. The global layer uses geographic or latency-based DNS routing, anycast, and global load balancers. Two declarations must not be confused: placement declarations, such as node affinity stating a service runs only on European Nodes, are Kubernetes business; user-steering declarations, such as European users going to the European cluster, are written at the global layer (DNS rules, load-balancer rules), not in Kubernetes manifests. Lightweight distributions such as KubeEdge and k3s run Kubernetes on edge devices, but user steering still belongs to the outer layer. The multi-cluster Services API covers cross-cluster service discovery, not end-user traffic steering.

A platform of platforms

Kubernetes is deliberately programmable: any software that can call the API Server can control Kubernetes, without modifying Kubernetes itself. Operators are the direct form: controllers running as ordinary Pods that watch custom resources and operate Kubernetes objects, such as a database operator provisioning and failing over a database cluster, cert-manager issuing and renewing TLS certificates, or Argo Rollouts performing canary and blue-green releases. Management tools form the second layer: kubectl, the Dashboard, Lens, k9s, Helm as a package manager for manifests, and GitOps tools such as Argo CD and Flux syncing Git repositories into clusters. Platform layers form the third: Rancher, OpenShift, and managed Kubernetes offerings give developers a simpler interface while driving the Kubernetes API underneath.

Panorama completion

Production needs a few more mechanisms, each one line. Rollout knobs: maxSurge caps how many extra Pods a rolling update may create, maxUnavailable caps how many may be down, and a bad release rolls back. StorageClass provisions a disk on demand from a claim, with no pre-created volume. Autoscaling spans three levels: the HorizontalPodAutoscaler (HPA) for replica counts, the Vertical Pod Autoscaler (VPA) for a single Pod's requests, and the Cluster Autoscaler for Node counts. Observability is not built in: logs beyond container stdout, metrics, and traces come from add-ons such as Prometheus with Grafana and Loki. Security adds NetworkPolicy for isolation, Pod security contexts, and at-rest encryption for Secrets, which are base64-encoded by default, not encrypted. At larger scale, a service mesh such as Istio or Linkerd adds fine-grained traffic control, mutual TLS (mTLS), and circuit breaking that plain Services cannot express.

When not to use Kubernetes

Kubernetes is not the default answer. Few services and small traffic are cheaper on Docker Compose or Coolify. The complexity of upgrades, operations, and troubleshooting only pays off once scale arrives. The same judgement applies inside Kubernetes: it is a set of mechanisms, one per need, composed as needed, not a stack to adopt wholesale.

One line to keep: every need maps to one mechanism, and the mechanisms compose.