Container orchestration

Every orchestrator solves the same set of problems: cluster membership and health (which nodes exist and are alive), scheduling (bin-packing workloads onto nodes subject to resource requests, affinity and anti-affinity, taints and topology spread), lifecycle (restart, rolling update, rollback), service discovery and load balancing, configuration and secret distribution, storage attachment, and autoscaling. The dominant design, inherited from Google's Borg (described in the 2015 EuroSys paper) and its successor Omega, is declarative: operators submit a desired state to an API, it is persisted in a consistent store, and independent control loops continuously compare desired and observed state and act on the difference. This level-triggered reconciliation is what makes the system self-healing - a controller does not need to see the event that broke something, only the current gap.

The cluster state store is the critical component. Kubernetes keeps it in etcd, which uses Raft consensus, so a control plane is usually run as three or five members to tolerate one or two failures while keeping a majority quorum. Swarm mode embeds its own Raft store in the manager nodes; HashiCorp Nomad likewise runs Raft among its servers. Losing quorum freezes changes but normally leaves running workloads untouched, because node agents (kubelet in Kubernetes) keep existing containers alive.

Kubernetes has become the de facto standard; Docker Swarm mode survives for small setups, Nomad schedules containers alongside VMs and plain binaries, and managed services such as Amazon ECS provide proprietary orchestration. Scheduling quality depends on honest resource requests: without them the scheduler overcommits, and under memory pressure the kubelet evicts pods, starting with those in the BestEffort QoS class.

Security concerns follow from centralisation. The orchestrator API can create workloads with any image, mount secrets and, unless prevented by admission policy, start privileged pods, so API access is effectively root on every node. NIST SP 800-190 lists orchestrator countermeasures such as least-privilege administrative access, separating workloads of different sensitivity onto different hosts, encrypted network traffic between nodes and trustworthy node enrolment. Typical real-world failures include API servers or dashboards exposed to the internet, overly broad RBAC bindings, unencrypted secrets in the state store and flat pod networks without network policy. Orchestration is distinct from configuration management (Ansible, Puppet), which converges machine state, and from GitOps, which is a way of feeding desired state into the orchestrator.