Cluster Architecture, Installation, and Configuration
This chapter covers how a Kubernetes cluster is structured, what each control-plane and node component does, and the operational concerns of installing, securing, and backing up a cluster. Understanding the flow of a request through the API server and the role of etcd is foundational for everything else on the exam.
Control plane and node components
A cluster is split into the control plane and worker nodes. The control plane includes the kube-apiserver (the single front end for all cluster operations), etcd (the key-value datastore), the kube-scheduler (which assigns Pods to nodes), and the kube-controller-manager (which runs control loops that drive actual state toward desired state). Each worker node runs a kubelet (which starts and supervises containers) and kube-proxy (which implements Service networking), plus a container runtime such as containerd. Every component communicates through the API server rather than with etcd directly.
etcd and backups
etcd holds the entire declarative state of the cluster, so protecting it is essential. Backups are taken with etcdctl snapshot save, supplying the endpoint and the client TLS certificates. A restore rebuilds the datastore from a snapshot. Because only the API server writes to etcd, a consistent snapshot captures every object, from Deployments to RBAC bindings, without touching individual nodes.
RBAC and access control
Role-Based Access Control governs who can do what. A Role grants permissions within a single namespace and is attached to subjects with a RoleBinding; a ClusterRole and ClusterRoleBinding operate cluster-wide. Following least privilege means preferring namespaced Roles over cluster-wide grants and avoiding powerful groups such as system:masters except where truly required.
kubeadm and static Pods
kubeadm bootstraps clusters and runs the control-plane components as static Pods. Static Pods are defined by manifest files in a directory the kubelet watches (commonly /etc/kubernetes/manifests) and are managed by the kubelet itself, not the scheduler. The API server publishes a read-only mirror of each static Pod so operators can see them with kubectl.