HA control plane topology — the cluster's brain at scale

A single control-plane node puts every API call, every controller, and the whole of the cluster’s state on one machine. Three nodes tolerate the loss of one and five tolerate two, because etcd commits a write only with a majority of members — which is also why an even member count buys nothing. This lesson lays out the production topology component by component: what runs on a control-plane node, what the load balancer in front of the API servers must not become, and how kubeadm assembles it.

The HA control plane topology

The HA control plane topology is the canonical production deployment. The topology is composed of:

• 3 control-plane nodes. The cluster’s brain.
• 1 load balancer. The cluster’s front door.
• 3 etcd members. The cluster’s state.

flowchart TB
    subgraph LB["Load Balancer"]
        LB_NODE["HAProxy / NGINX / cloud LB"]
    end

    subgraph CP["Control Plane (3 nodes)"]
        CP1["control-plane-01"]
        CP2["control-plane-02"]
        CP3["control-plane-03"]
    end

    subgraph ETCD["etcd Cluster (3 members)"]
        ETCD1["etcd-01"]
        ETCD2["etcd-02"]
        ETCD3["etcd-03"]
    end

    LB_NODE --> CP1
    LB_NODE --> CP2
    LB_NODE --> CP3
    CP1 --> ETCD1
    CP2 --> ETCD2
    CP3 --> ETCD3
    ETCD1 --> ETCD2
    ETCD2 --> ETCD3
    ETCD3 --> ETCD1

The HA control plane is the cluster’s brain at scale.

The control plane node

The control plane node is composed of:

• kubelet. The node’s voice.
• containerd. The node’s container runtime.
• kube-apiserver. The cluster’s HTTP API.
• kube-controller-manager. The cluster’s reconciliation.
• kube-scheduler. The cluster’s placement engine.
• etcd (single member). The node’s slice of the cluster’s state.

flowchart LR
    A[kubelet] --> B[containerd]
    B --> C[kube-apiserver]
    B --> D[kube-controller-manager]
    B --> E[kube-scheduler]
    B --> F[etcd]

The control plane node is the cluster’s brain.

The load balancer

The load balancer is the cluster’s front door. The load balancer distributes the API server traffic across the multiple API server instances.

flowchart LR
    A[kubectl] --> B[Load balancer]
    B --> C[API server 1]
    B --> D[API server 2]
    B --> E[API server 3]

The load balancer is the cluster’s front door.

The etcd cluster

The etcd cluster is the cluster’s state. The etcd cluster is composed of 3 members (or 5 for higher availability).

flowchart LR
    A[API server] --> B[etcd-01]
    A --> C[etcd-02]
    A --> D[etcd-03]
    B --> E[RAFT log]
    C --> E
    D --> E

The etcd cluster is the cluster’s state.

The deployment

The deployment is the canonical kubeadm deployment:

# Substitute your own value before running:
LB_ENDPOINT=k8s-api.example.com

# 1. Initialize the first control-plane node
kubeadm init --control-plane-endpoint "$LB_ENDPOINT":6443 --upload-certs

# 2. Join the other control-plane nodes
# The token, CA cert hash and certificate key are printed by the
# `kubeadm init` in step 1 - copy them from that output.
TOKEN=abcdef.0123456789abcdef
CA_CERT_HASH=sha256:9f2c1e0a7b4d63f85c19ae02d47b8c6135ea9d70f3b21c48a6e5d09f7c3b1a24
CERT_KEY=f8e7d6c5b4a3928170695a4b3c2d1e0f9a8b7c6d5e4f30211223344556677889

kubeadm join "$LB_ENDPOINT":6443 --token "$TOKEN" --discovery-token-ca-cert-hash "$CA_CERT_HASH" --control-plane --certificate-key "$CERT_KEY"

# 3. Verify the HA control plane
kubectl get nodes -o wide

The deployment is the HA control plane.

The production discipline

The HA control plane topology is the cluster’s hypothesis. The discipline is to walk the 11-step methodology applied to the HA control plane, identify the cause, apply the remediation. The cluster’s discipline is the same scale-free: every component is justified.

Quiz

Production discipline

• Walk the 11-step methodology. The methodology is the diagnostic.
• Identify the gaps. The gaps are the cluster’s missing components.
• Deploy the HA control plane. The deployment is the cluster’s recovery.
• Verify the HA topology. The verification is the cluster’s evidence.
• Document the HA topology. The runbook is the cluster’s reference.