Kubernetes container orchestration

Control Plane & Worker Nodes

A Kubernetes cluster has two halves: the control plane that makes global decisions (scheduling, detecting failures, responding to events) and worker nodes that run your actual application containers.

Control Plane

kube-apiserver is the front door -- every kubectl command, every internal component, and every webhook hits this REST API. It validates requests, persists state to etcd, and serves as the hub for all cluster communication.

etcd is the single source of truth: a distributed key-value store holding all cluster state. Losing etcd without backups means losing the cluster.

kube-scheduler watches for newly created Pods with no assigned node, then picks the best node based on resource requirements, affinity rules, taints, and other constraints.

kube-controller-manager runs a collection of control loops (Deployment controller, ReplicaSet controller, Node controller, etc.) that continuously reconcile desired state with actual state.

Worker Nodes

kubelet is the node agent. It takes PodSpecs from the API server and ensures the described containers are running and healthy. It reports node status back to the control plane.

kube-proxy maintains network rules on each node, implementing the Service abstraction by programming iptables or IPVS rules so that traffic to a Service ClusterIP reaches the right Pod.

Container runtime (containerd, CRI-O) does the actual work of pulling images, creating containers, and managing their lifecycle via the Container Runtime Interface (CRI).

Pods, Deployments, Services & Ingress

A Pod is the smallest deployable unit -- one or more containers sharing the same network namespace and storage volumes. Pods are ephemeral; they get an IP but that IP dies with the Pod.

A Deployment manages a ReplicaSet, which in turn manages Pods. It gives you declarative updates, rollback history, and scaling. You almost never create Pods directly.

Service Types

Because Pod IPs are transient, a Service provides a stable virtual IP (ClusterIP) and DNS name that load-balances traffic across matching Pods.

Ingress

Ingress sits in front of Services and provides HTTP/HTTPS routing -- host-based and path-based rules, TLS termination, and more. It requires an Ingress Controller (NGINX, Traefik, or a cloud-native one) to function.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

ConfigMap, Secret, Storage & Specialized Workloads

Pod Networking, CNI & Service Mesh

Kubernetes networking has one fundamental rule: every Pod gets its own IP, and any Pod can reach any other Pod without NAT. This flat network model is implemented by a CNI plugin.

CNI Plugins

Network Policies

By default, all Pods can talk to all Pods. A NetworkPolicy is a firewall rule scoped to a namespace that restricts ingress and/or egress traffic based on Pod labels, namespace selectors, or CIDR blocks.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}       # applies to all pods in namespace
  policyTypes:
  - Ingress             # deny all inbound by default

Service Mesh

A service mesh (Istio, Linkerd) adds a sidecar proxy to every Pod, giving you mutual TLS, traffic shaping, retries, circuit breaking, and distributed tracing -- all without changing application code.

Autoscaling, Resource Management & Pod Placement

Autoscaling

HPA (Horizontal Pod Autoscaler) adds or removes Pod replicas based on CPU, memory, or custom metrics. VPA (Vertical Pod Autoscaler) adjusts resource requests/limits on existing Pods. Cluster Autoscaler adds or removes nodes when Pods cannot be scheduled or nodes are underutilized.

Resource Requests & Limits

requests are what the scheduler uses to find a node with enough capacity. limits are the hard ceiling enforced by the kubelet -- exceed memory limits and your container gets OOMKilled; exceed CPU limits and it gets throttled.

Scheduling Constraints

Taints & Tolerations: A node taint repels Pods unless the Pod has a matching toleration. Used to reserve nodes (e.g., GPU nodes, dedicated tenant nodes).

Node Affinity: Schedule Pods to nodes matching label expressions (required or preferred). Like a more expressive nodeSelector.

Pod Affinity / Anti-Affinity: Co-locate Pods together (affinity) or spread them apart (anti-affinity) based on topology domains (zone, node). Anti-affinity is critical for HA -- ensuring replicas land on different nodes or zones.

PodDisruptionBudget (PDB): Limits how many Pods in a Deployment can be down simultaneously during voluntary disruptions (node drains, cluster upgrades). For example, minAvailable: 2 ensures at least 2 replicas stay running.

Rolling, Blue-Green & Canary

Rolling Update (default)

Kubernetes gradually replaces old Pods with new ones, controlled by maxUnavailable and maxSurge. Zero-downtime by default. Easy rollback with kubectl rollout undo.

Blue-Green

Run two identical environments (blue = current, green = new). Once the green environment is verified, switch the Service selector to point at green. Instant rollback by switching back. Downside: requires double the resources during transition.

Canary

Route a small percentage of traffic (e.g., 5%) to the new version. Monitor error rates and latency. Gradually increase traffic if metrics look good. Requires either weighted Service routing (via Istio, Linkerd, or Argo Rollouts) or manual ReplicaSet manipulation.