Skip to content

Orchestration Theory

This section covers the theory behind container orchestration, primarily focusing on Kubernetes. It includes architecture deep dives (Control Plane, Worker Nodes, etcd), scheduling algorithms, and certification study notes (e.g., CKA/CKS).

Guides & Concepts

Control Plane High Availability (HA) & The Bootstrap Deadlock

A highly available Kubernetes API server requires a Virtual IP (VIP) so workers can always reach an active control plane node even if one fails. Tools like kube-vip provide this via ARP/BGP.

However, bootstrapping this introduces a "chicken-and-egg" deadlock:

  1. kubeadm init needs to talk to the VIP to initialize the cluster's configuration and certificates.
  2. kube-vip (deployed as a static pod) needs kubeadm to finish initializing the cluster so the necessary RBAC super-admin rules exist before it can securely bind the VIP via leader election.

The Theoretical Solution: The node's OS must manually bind the VIP to its network interface imperatively before running kubeadm init. Once kubeadm finishes and generates the kube-vip static pod manifest, the static pod starts up, assumes control of the VIP, and manages it declaratively from then on.

Overlay Networking Theory

Kubernetes requires that every pod can communicate with every other pod across the cluster without NAT. On bare-metal, physical switches don't know about pod IP addresses.

An Overlay Network (like Flannel or Calico) solves this by creating a virtual network on top of the physical one:

  1. Encapsulation: When Pod A (on Node 1) sends a packet to Pod B (on Node 2), the CNI intercepts it.
  2. It wraps the original packet (Pod A IP -> Pod B IP) inside a new UDP packet (Node 1 IP -> Node 2 IP).
  3. Physical Routing: The physical switch routes the packet based on the Node IPs (which it understands).
  4. Decapsulation: Node 2 receives the packet, the CNI unwraps it, and delivers the original packet to Pod B.