Kubernetes Basics
Kubernetes Architecture — Master and Worker Nodes
Kubernetes utilizes a distributed master-worker architecture to maintain the desired state of containerized applications across a cluster. Understanding this split is critical because it decouples the control plane intelligence from the execution environment, allowing for high availability and scalability. You reach for this architectural knowledge whenever you need to troubleshoot deployment failures, optimize resource allocation, or secure your infrastructure boundaries.
The Control Plane: The Cluster's Brain
The Control Plane, or master node, acts as the central nervous system of your cluster. It is responsible for making global decisions, such as scheduling and detecting or responding to cluster events. The most critical component here is the API Server, which serves as the gateway for all internal and external communication. By centralizing the API, Kubernetes ensures that any state changes are validated and authorized before being persisted to the cluster store. This design is crucial because it creates a single point of truth, ensuring that all components agree on the current state. When you ask the system to perform an action, the API Server processes that request, updates the desired state in the database, and informs the relevant controllers. Without this architectural separation, managing state across hundreds of machines would lead to inconsistent data and unpredictable application behavior.
# Use kubectl to verify the control plane components are running
kubectl get pods -n kube-system # Displays internal cluster control plane podsThe Worker Node: The Execution Engine
Worker nodes are the heavy lifters of the architecture. Their primary purpose is to execute the actual application containers as instructed by the Control Plane. Each worker node runs the Kubelet, an agent that ensures containers are running in pods as expected. If the Control Plane tells a worker node to start a container, the Kubelet communicates with the container runtime to pull the image and start the process. This separation of duties—where the Control Plane handles policy and the Worker Node handles execution—enables horizontal scalability. You can add more worker nodes to the cluster without ever needing to touch the Control Plane logic. This modularity means that if a worker node experiences a hardware failure, the Control Plane simply notices the health check failure and moves the workload to a healthy node, maintaining uptime without manual intervention.
# Check the status of all nodes in your cluster
kubectl get nodes # Lists worker nodes and their current operational statusThe etcd Component: Persistent Configuration
Every Kubernetes cluster relies on etcd, a distributed key-value store that serves as the backbone for the cluster state. This is where all configuration data, secrets, and status updates reside. Because Kubernetes is declarative, it must constantly compare the 'actual state' of the world with the 'desired state' saved in etcd. By using a distributed store, the architecture ensures that even if one master node fails, the state can be recovered or synchronized with other members of the cluster. Understanding etcd is essential because it explains why Kubernetes is so resilient; the system does not 'lose' its configuration simply because a node reboots. The persistence of etcd allows the Control Plane to recover its intelligence even after a total power loss, effectively restoring the cluster to the exact state it held moments before the outage.
# Inspect the etcd member status (requires proper certificate access)
etcdctl endpoint status --write-out=table # Shows the health of the state storeThe Kube-Proxy: Maintaining Network Rules
Within each worker node, the kube-proxy component functions as the primary network administrator. It maintains network rules on nodes, which allow network communication to your pods from inside or outside the cluster. Its job is to handle the complexity of how traffic is routed to the correct pod, regardless of which node that pod is currently residing on. Without kube-proxy, the distributed nature of worker nodes would make networking a nightmare, as IP addresses for pods change dynamically whenever they are replaced or rescheduled. By abstracting these network rules, kube-proxy provides a stable interface for services. It is the reason you can point traffic to a service name rather than a specific, ephemeral IP address of a container, making the infrastructure feel like a single, unified machine rather than a chaotic collection of separate, disconnected hardware nodes.
# Verify the kube-proxy daemonset running in the cluster
kubectl get daemonset kube-proxy -n kube-system # Shows network agent configurationThe Controller Manager: Enforcement of State
The Controller Manager is the component that actually makes things happen based on the instructions in the API Server. It runs various controller processes that continuously monitor the state of the cluster. For example, if you define a deployment with three replicas, the Deployment Controller notices if only two are running and immediately requests the creation of a third pod to reach the desired state. This feedback loop is the heart of Kubernetes. By constantly reconciling the current world with the desired intent, the controller manager removes the need for human oversight during routine scaling or self-healing events. It is a proactive mechanism that ensures your application stays in the configured state, even when faced with node crashes or network partitions. This is the definition of autonomous infrastructure management in a distributed system environment.
# Describe a deployment to see the controller's logic in action
kubectl describe deployment <deployment-name> # Shows current vs desired replica stateKey points
- The Control Plane functions as the central authority for all cluster decisions and state updates.
- Worker nodes serve as the execution environment for running application containers and workloads.
- The API Server acts as the primary communication gateway between all internal cluster components.
- The Kubelet agent on each worker node ensures that containers are running and healthy.
- The etcd component provides a highly available and consistent store for all cluster configuration data.
- Kubernetes uses a declarative model to ensure the actual state matches the desired state.
- Kube-proxy handles network connectivity and load balancing for services across the entire cluster.
- Controller loops automatically reconcile differences between current system state and desired deployment objectives.
Common mistakes
- Mistake: Thinking the Control Plane schedules its own pods. Why it's wrong: The Kube-scheduler only manages scheduling for Worker Nodes, not the internal Control Plane components. Fix: Understand that static pods or manifest-based management are used for Control Plane components.
- Mistake: Assuming the API Server is a database. Why it's wrong: The API Server is an interface that validates requests; etcd is the actual key-value store database. Fix: Treat the API Server as the RESTful gateway and etcd as the storage backend.
- Mistake: Believing Worker Nodes can communicate directly without a Kubelet. Why it's wrong: The Kubelet is the essential agent required to communicate with the API Server and manage the container runtime. Fix: Ensure Kubelet is active on every node to maintain cluster participation.
- Mistake: Deploying applications directly onto the Master Node. Why it's wrong: Master nodes are reserved for cluster management to maintain stability and security. Fix: Always use Taints and Tolerations to prevent user workloads from scheduling on the control plane.
- Mistake: Confusing Kube-proxy with a Load Balancer. Why it's wrong: Kube-proxy handles network rules on individual nodes to facilitate pod communication, not external traffic balancing. Fix: Use a Service object or Ingress Controller for traffic balancing.
Interview questions
What is the fundamental difference between the Master node and the Worker node in a Kubernetes cluster?
The Master node, also known as the Control Plane, acts as the brain of the Kubernetes cluster. It is responsible for maintaining the desired state, managing the cluster's API, and scheduling workloads. Conversely, Worker nodes are the workhorses; they host the actual containerized applications inside pods. The Worker node runs the kubelet and kube-proxy, ensuring containers remain healthy, while the Master node oversees the orchestration, communication, and decision-making processes to keep the entire system functioning according to the defined configurations.
Can you explain the role of the kubelet on a Worker node?
The kubelet is the primary node agent that runs on every Worker node in the cluster. Its job is to ensure that containers are running in pods as described by the PodSpecs provided by the Control Plane. It monitors the health of containers and reports back to the Master node via the API server. If a container fails, the kubelet restarts it. It effectively bridges the gap between the orchestration layer and the local container runtime, ensuring the physical hardware executes the cluster's instructions.
What is the function of the etcd component, and why is it located on the Master node?
etcd is a distributed, consistent key-value store used as Kubernetes' backing store for all cluster data. It is located on the Master node because it acts as the 'source of truth' for the entire cluster state. Every configuration change, secret, or pod definition is stored here. Because the Master node manages orchestration, it requires direct, low-latency access to this database to ensure that all decisions regarding scheduling and node management are based on the most accurate and current information available within the cluster infrastructure.
Compare the functions of the kube-scheduler and the kube-controller-manager in the Kubernetes Control Plane.
The kube-scheduler and the kube-controller-manager serve distinct purposes in maintaining cluster state. The scheduler's sole job is to watch for newly created pods with no assigned node and select a healthy node for them to run on, considering resource requirements and policies. The controller-manager, however, is a daemon that embeds the core control loops, such as the Node Controller or Replication Controller. While the scheduler makes placement decisions, the controller-manager actively observes the cluster to ensure the actual state matches the desired state, such as scaling deployments or replacing failed nodes.
How does the API Server interact with the various components of the Master and Worker nodes?
The API Server is the central gateway to the Kubernetes cluster; all communication flows through it. When you run a command, you talk to the API Server. It authenticates requests and persists data to etcd. The Master node components, like the scheduler, watch the API Server for new tasks. On the Worker side, the kubelet watches the API Server for pod assignments. This centralized model ensures that no component acts independently without updating or receiving instructions from the cluster's primary interface, maintaining synchronization across the entire distributed system.
Describe the architectural flow when a developer deploys a new container image to a Kubernetes cluster.
When a developer updates a deployment via `kubectl`, the request hits the API Server, which records the new desired state in etcd. The deployment controller notices the change and creates a new ReplicaSet. The scheduler then identifies the new pods, checks node capacity, and assigns them to specific Worker nodes. Upon assignment, the kubelet on that target node detects the new pod specification, pulls the Docker image from the registry, and starts the container using the local container runtime. The kube-proxy then updates network rules to ensure the new pod is reachable, completing the full lifecycle deployment.
Check yourself
1. If the etcd component fails, what is the immediate impact on the Kubernetes cluster functionality?
- A.Existing pods on worker nodes stop running immediately
- B.The cluster becomes read-only and state changes cannot be persisted
- C.The kubelet automatically restarts the etcd service
- D.The API server continues to schedule new pods normally
Show answer
B. The cluster becomes read-only and state changes cannot be persisted
The API server relies on etcd for state; if etcd is down, the cluster state cannot be updated, making it read-only. Pods continue running (A is wrong), kubelet manages nodes, not etcd (C is wrong), and scheduling requires state updates (D is wrong).
2. Which component is primarily responsible for ensuring that the desired state of the cluster matches the current state?
- A.Kube-scheduler
- B.Kube-proxy
- C.Controller Manager
- D.Container Runtime
Show answer
C. Controller Manager
The Controller Manager runs control loops that watch the state and make changes to reach the desired state. Scheduler just assigns nodes (A), proxy handles networking (B), and runtime manages containers (D), not cluster state.
3. What is the primary role of the Kubelet on a Worker Node?
- A.Directing traffic between services
- B.Managing the lifecycle of containers based on pod specifications
- C.Storing the configuration of the entire cluster
- D.Communicating with other worker nodes to share memory
Show answer
B. Managing the lifecycle of containers based on pod specifications
The Kubelet ensures containers described in PodSpecs are running and healthy. Traffic routing is Kube-proxy (A), cluster configuration is in etcd (C), and memory sharing is not a standard Kubernetes feature (D).
4. Why does the Kubernetes architecture separate the Control Plane from Worker Nodes?
- A.To allow workers to run different operating systems than the master
- B.To isolate management processes from application workloads for security and stability
- C.To enable the master node to host the container runtime interface
- D.To reduce the number of IP addresses required for the cluster
Show answer
B. To isolate management processes from application workloads for security and stability
Separation prevents application crashes or resource exhaustion from affecting the cluster management. Masters don't have to use different OS (A), runtime is for workers (C), and IP count isn't the architectural driver (D).
5. When a user submits a manifest to the API Server, what is the sequence of events?
- A.API Server updates etcd, then Scheduler assigns a node, then Kubelet executes
- B.Kube-proxy assigns the node, then API Server updates etcd
- C.Container Runtime creates the pod, then API Server updates etcd
- D.Controller Manager deploys the pod, then Scheduler updates the API Server
Show answer
A. API Server updates etcd, then Scheduler assigns a node, then Kubelet executes
The API Server validates the request and writes to etcd; the Scheduler notices the new pod and assigns it to a node; the Kubelet on that node sees the assignment and starts the container. Others (B, C, D) incorrectly assign responsibilities.