In the context of the CKA exam, Kubernetes architecture is defined by a master-worker model separating the Control Plane from Worker Nodes.
The **Control Plane** is the cluster's brain. The `kube-apiserver` acts as the frontend, processing REST requests and serving as the only component that comm…In the context of the CKA exam, Kubernetes architecture is defined by a master-worker model separating the Control Plane from Worker Nodes.
The **Control Plane** is the cluster's brain. The `kube-apiserver` acts as the frontend, processing REST requests and serving as the only component that communicates directly with `etcd`. `etcd` is a highly available key-value store that persists the cluster's state. The `kube-scheduler` assigns new Pods to nodes based on resource availability, taints, and tolerations. The `kube-controller-manager` runs control loops (like the ReplicaSet or Node controllers) to ensure the current state of the cluster matches the desired state. Ideally, these run as Static Pods on the master node.
**Worker Nodes** are the compute machines running workloads. The `kubelet` is the primary agent on every node; it registers the node with the API server and manages the lifecycle of Pods, ensuring containers are running and healthy. It interacts with the **Container Runtime** (e.g., containerd or CRI-O) via the Container Runtime Interface (CRI) to execute containers. `kube-proxy` manages networking rules on each node, facilitating communication between Pods and Services via IPTables or IPVS.
Mastery of these components is essential for the 'Cluster Architecture, Installation & Configuration' domain, particularly when bootstrapping clusters with kubeadm or troubleshooting broken components.
Kubernetes Components & Architecture
Why is it Important? Understanding Kubernetes architecture is the foundational knowledge required for the Certified Kubernetes Administrator (CKA) exam. It falls under the 'Cluster Architecture, Installation & Configuration' domain, which accounts for 25% of the exam. Without grasping how components interact, you cannot effectively troubleshoot cluster failures, install a cluster from scratch (kubeadm), or perform maintenance tasks like upgrades and etcd backups.
What is it? A Kubernetes cluster is divided into two main functional areas: the Control Plane (the brain) and the Worker Nodes (the muscle).
1. The Control Plane Components: - kube-apiserver: The front-end of the control plane. It validates and configures data for API objects (pods, services, etc.) and is the only component that interacts directly with etcd. - etcd: A consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. If etcd is lost, the cluster state is lost. - kube-scheduler: Watches for newly created Pods with no assigned node and selects a node for them to run on based on resource requirements and constraints. - kube-controller-manager: Runs controller processes (like Node Controller, Job Controller) that monitor the state of the cluster and try to move the current state towards the desired state. - cloud-controller-manager: Embeds cloud-specific control logic (only present if running on a cloud provider like AWS/GCP/Azure).
2. The Worker Node Components: - kubelet: An agent that runs on each node in the cluster. It ensures that containers are running in a Pod. - kube-proxy: Maintains network rules on nodes. These rules allow network communication to your Pods from network sessions inside or outside of your cluster. - Container Runtime: The software that is responsible for running containers (e.g., containerd, CRI-O).
How it Works The workflow generally follows this pattern: A user sends a request (via kubectl) to the kube-apiserver. The API server authenticates the request and stores the desired state in etcd. The kube-scheduler notices a new pod needs to be created and assigns it to a specific node. The kubelet on that target node receives the instruction from the API server and instructs the Container Runtime to start the container. Meanwhile, kube-proxy updates network rules to ensure traffic can reach the new service.
How to Answer Questions in the Exam Questions in this domain often involve troubleshooting a broken cluster or backing up data.
1. Identify the Failure: If `kubectl get nodes` returns an error connecting to localhost:8080, check if the kube-apiserver is running. 2. Check Component Status: Use `kubectl get pods -n kube-system` to see if control plane pods are running. If they are crashed, check logs. 3. Service vs. Pod: Remember that on a kubeadm cluster, control plane components usually run as Static Pods, while the kubelet runs as a systemd service.
Exam Tips: Answering Questions on Kubernetes Components and Architecture - Know where the configs live: Most static pod manifests are located at `/etc/kubernetes/manifests/`. If the API server or Scheduler is misconfigured, this is where you edit the YAML file to fix it. - Kubelet Troubleshooting: If a node is 'NotReady', check the kubelet service first: `systemctl status kubelet` and `journalctl -u kubelet`. - Etcd Snapshots: You will likely be asked to backup or restore etcd. Memorize the command `etcdctl snapshot save` and know where the certificates are located (usually `/etc/kubernetes/pki/etcd`). - Process Listing: If you can't use kubectl, use `crictl ps` or `docker ps` (depending on the runtime) on the node to see if the component containers are actually running.