Kubernetes Fundamentals practice questions

etcd is the cluster's source of truth, but access to it is deliberately funneled through a single component: the kube-apiserver.

Centralizing etcd access in the API server means authentication, authorization, admission control, and validation happen in exactly one place before any state changes. The controller manager and kubelet are plausible distractors because they constantly read and update state, but they always do so via API requests - if they wrote to etcd directly, they would bypass every security and validation layer.

1. A component or user submits a change through the Kubernetes API.
2. The kube-apiserver validates the request and authorizes the caller.
3. The kube-apiserver alone persists the resulting object into etcd.

Exam tip: Only kube-apiserver talks to etcd - every other component goes through the API server.

etcd is the consistent, highly available key-value datastore that backs all Kubernetes cluster data - the definitive record of the cluster's desired and observed state.

Every API object lives in etcd, which is why losing etcd without a backup means losing the cluster's state. The distractors assign etcd active behaviors - running containers, balancing traffic, scheduling - but etcd is purely a datastore: the scheduler, kube-proxy, and the container runtime perform those actions, and etcd just records the outcomes via the API server.

1. The kube-apiserver writes every created or updated object into etcd.
2. Controllers and the scheduler read that state (through the API server) to make decisions.
3. Because etcd holds the source of truth, backing it up is how you back up the cluster.

Exam tip: etcd is the cluster's key-value source of truth - it stores state, and only the API server accesses it.

kube-scheduler has one narrow responsibility: assigning unscheduled Pods to nodes based on resource requirements, constraints, and policies.

Scheduling is a decision, not an action. The scheduler picks the node and writes that binding to the Pod via the API server - then its involvement ends. The tempting distractor is starting containers: many assume the scheduler places and launches Pods, but the kubelet on the chosen node notices the assignment and does the launching. Crash restarts are likewise the kubelet's local responsibility.

1. A new Pod is created and has no node assigned.
2. kube-scheduler filters out unsuitable nodes and scores the remaining candidates.
3. It binds the Pod to the best node, and that node's kubelet then starts the containers.

Exam tip: The scheduler only picks the node - the kubelet on that node actually starts the containers.

The kubelet is the primary node agent in Kubernetes: it turns Pod specifications into running containers by working with a container runtime (via the Container Runtime Interface).

Once the scheduler assigns a Pod to a node, that node's kubelet takes over - pulling images, starting containers through the runtime, running health probes, and reporting status back to the API server. kube-proxy is the classic distractor since it also runs on every node, but its domain is Service networking, not container lifecycle.

1. The kubelet sees (via the API server) that a Pod has been assigned to its node.
2. It instructs the container runtime to pull images and start the Pod's containers.
3. It continuously monitors the containers and reports Pod status back to the API server.

Exam tip: kubelet is the per-node agent that makes Pods real by driving the container runtime.

kube-proxy runs on every node and implements the Service abstraction at the network level, keeping forwarding rules in sync with the cluster's Services and endpoints.

When a client sends traffic to a Service's virtual IP, something must translate that into a real Pod IP - that is kube-proxy's rule set at work. The name misleads people into the kubectl-proxying distractor, but kube-proxy never touches API traffic; and Pod IPs come from the CNI plugin, while node placement comes from the scheduler.

1. kube-proxy watches the API server for Services and their endpoint Pods.
2. It programs the node's packet forwarding rules (iptables, IPVS, or similar).
3. Traffic addressed to a Service IP is then redirected to one of the healthy backend Pods.

Exam tip: kube-proxy makes Service virtual IPs work by programming per-node network forwarding rules.

kube-controller-manager is the control plane process that bundles Kubernetes' core controllers - independent reconciliation loops like the ReplicaSet, node, and endpoints controllers.

Controllers are what make Kubernetes declarative: each one watches a slice of the cluster and continuously nudges reality toward what the user asked for. For example, the ReplicaSet controller creates or deletes Pods when the actual count drifts from the requested count. The distractors describe real cluster concerns - etcd operation, the CLI, image delivery - but each belongs to etcd itself, kubectl, and registries plus the runtime respectively.

1. Each controller watches the API server for the objects it is responsible for.
2. It compares the object's desired state with the cluster's observed state.
3. When they differ, it issues API requests (create, update, delete) to converge them.

Exam tip: kube-controller-manager runs the reconciliation loops that continuously push actual state toward desired state.