Cluster Architecture, Installation & Configuration
Core mental model
The control plane is the API server (front door and admission/RBAC enforcement), etcd (the only state store), scheduler (binds Pods to nodes), and controller-manager (reconciliation loops). Every node runs kubelet (Pod lifecycle), kube-proxy or equivalent (Service dataplane), and a CRI runtime. Static Pods are read from /etc/kubernetes/manifests by kubelet and mirror Pods appear in the API.
Installation and upgrade
kubeadm init bootstraps certificates, kubeconfig, control-plane static Pods, and add-ons; kubeadm join uses a bootstrap token and CA hash. A CNI plugin must be installed before nodes become Ready. Upgrades are ordered: upgrade kubeadm, run kubeadm upgrade plan/apply on the first control plane, upgrade kubelets and kubectl, then drain/upgrade/uncordon workers one at a time.
RBAC and identity
Roles and RoleBindings are namespaced; ClusterRoles and ClusterRoleBindings are cluster-scoped. A RoleBinding can bind a ClusterRole but grants only in its namespace. Use kubectl auth can-i --as=system:serviceaccount:ns:name to verify.
Trap: editing a static Pod manifest directly is correct; kubectl delete on a mirror Pod does not remove it. Trap: etcd restore needs a fresh data-dir and matching endpoints/advertise URLs, not overwriting a live member casually. Trap: kubeconfig context and namespace can make commands act on the wrong cluster.
Worked example: to back up etcd, run etcdctl snapshot save /backup/etcd.db with the etcd certificates and endpoints from the static Pod manifest; verify with snapshot status.