Cluster components
A Kubernetes cluster is a fleet of cooperating processes. You interact directly with only a couple of them, but the exam expects you to know which component does what - especially that everything routes through the kube-APIserver and that the scheduler assigns but does not launch Pods.
A cluster is a set of computers (virtual machines on GKE, but they can be physical). One is the control plane (coordinates the whole cluster); the rest are nodes (run the Pods).
Control-plane components
- kube-APIserver - the only component you interact with directly. It accepts commands that view or change cluster state (including launching Pods), and it authenticates incoming requests, decides whether they are authorized and valid, and manages admission control.
- kubectl - the command-line client. It connects to the kube-APIserver and talks to it using the Kubernetes API.
- etcd - the cluster's database. It reliably stores cluster state: all configuration data plus dynamic information like which nodes are in the cluster, what Pods should run, and where.
- kube-scheduler - assigns Pods to nodes. It evaluates each Pod's requirements and picks the most suitable node, obeying constraints you define (hardware, software, policy) and affinity / anti-affinity rules.
- kube-controller-manager - continuously monitors cluster state through the kube-APIserver and, whenever current state drifts from desired state, makes changes to reconcile it. The work is done by loops of code called controllers (e.g. a Deployment keeps 3 nginx Pods running; the Node Controller reacts when a node goes offline).
- kube-cloud-manager - manages the controllers that talk to the underlying cloud provider (e.g. wiring in Google Cloud load balancers and storage volumes).
Any query or change to cluster state - from kubectl or any other component -
must be addressed to the kube-APIserver. Even etcd is never touched directly; the
kube-APIserver reads and writes the database on behalf of the rest of the system.
kube-scheduler does not start Pods. When it finds a Pod with no assigned node, it chooses a node and writes that node's name into the Pod object. A node's kubelet is what actually launches the Pod.
Node components
Each node runs a small family of components:
- kubelet - Kubernetes' agent on each node. When the kube-APIserver wants to start a Pod on a node, it connects to that node's kubelet. The kubelet uses the container runtime to start the Pod, monitors its lifecycle (readiness and liveness probes), and reports back to the kube-APIserver.
- container runtime - the software that launches a container from a container image. Kubernetes supports several; GKE's node OS uses containerd, the runtime component of Docker.
- kube-proxy - maintains network connectivity among the Pods in a cluster. In open-source Kubernetes this uses the iptables firewalling built into the Linux kernel.
- kubelet = the control plane's agent on each node; the only thing that launches Pods locally.
- container runtime on GKE nodes = containerd (Docker's runtime component).
- kube-proxy networking mechanism in open-source Kubernetes = iptables.
Everything above the nodes - kube-APIserver, etcd, scheduler, controller managers - is provisioned and managed by GKE. It still exposes an IP address for your Kubernetes API requests, but you never provision or babysit the control plane infrastructure. Node management then depends on your operating mode: Autopilot manages nodes for you; Standard leaves node configuration to you.