Kubernetes Architecture Explained with Practical Examples
Kubernetes Architecture Explained with Practical Examples
Kubernetes has become the industry standard for container orchestration, but its complex architecture often intimidates newcomers. This guide provides a kubernetes architecture explained with examples that demystifies each component, showing how they work together to automate application deployment, scaling, and management in production environments.
What You'll Learn
By the end of this guide, you'll understand how Kubernetes cluster components interact to run containerized applications reliably, and you'll be able to identify the role of each control plane and worker node component. You'll be able to explain the entire request flow—from a user submitting a deployment to the application becoming available—using a concrete example.
How It Works: A Layered Architecture with a Real-World Analogy
Think of a Kubernetes cluster as a shipping company. The control plane is the company headquarters where managers make strategic decisions. The worker nodes are the cargo ships that physically carry the containers. Each container on a ship is a Pod, the smallest deployable unit in Kubernetes .
The Control Plane: The Cluster's Brain
The control plane manages the cluster's state and orchestrates all activities . It consists of several critical components:
kube-apiserver acts as the front desk—all communication with the cluster goes through this component. When you run kubectl commands, the API server authenticates your request, validates it, and updates the cluster state stored in etcd, a distributed key-value store that serves as Kubernetes' backing store for all cluster data .
The kube-scheduler watches for newly created Pods that have no assigned node. It intelligently selects the most suitable worker node based on resource requirements, constraints, and policies . For example, if you request a Pod that needs a GPU, the scheduler will only consider nodes with GPU resources.
The kube-controller-manager runs a set of controllers that continuously monitor the cluster state and make corrections. The Node controller detects when nodes go down, the Job controller manages one-off tasks, and the EndpointSlice controller connects Services to Pods .
Worker Nodes: Where Applications Run
Each worker node runs three essential components:
kubelet is the primary node agent that ensures containers are running in a Pod as specified . It receives Pod specifications from the API server and manages the container runtime to start and monitor those containers.
kube-proxy maintains network rules that allow communication to Pods from inside or outside the cluster. It implements the Service concept by forwarding traffic to the correct Pods using packet filtering rules .
The container runtime (such as containerd or CRI-O) is the software responsible for actually running the containers .
Practical Example: Deploying a Web Application
Let's trace what happens when you deploy an Nginx web server:
- You write a Deployment YAML file specifying 3 replicas of the Nginx container.
- You submit it with
kubectl apply -f deployment.yaml. The request reaches the API server. - The API server authenticates you and stores the desired state in etcd.
- The scheduler detects unscheduled Pods and assigns them to worker nodes with available capacity.
- On each assigned worker node, the kubelet receives the Pod specification and instructs the container runtime to pull the Nginx image and start the container.
- The controller-manager continuously verifies that 3 replicas are running, and if a Pod fails, it creates a replacement.
- A Service is created to expose the application, and kube-proxy configures network rules so traffic can reach the Pods.
Why It Matters
Kubernetes' architecture enables capabilities that fundamentally change how organizations deploy and manage software:
Self-healing: If a container crashes or a node becomes unresponsive, controllers automatically replace the failed Pods on healthy nodes, minimizing downtime .
Horizontal scaling: The Horizontal Pod Autoscaler can automatically adjust the number of Pod replicas based on CPU utilization or custom metrics, allowing applications to handle traffic spikes without manual intervention .
Rolling updates and rollbacks: Deployments enable zero-downtime updates. You can gradually replace old Pods with new versions, and if something goes wrong, roll back instantly .
Resource efficiency: The scheduler optimizes Pod placement across nodes, improving resource utilization and reducing infrastructure costs.
By the Numbers
| Metric | Details |
|---|---|
| Initial Release | Kubernetes 1.0 released July 21, 2015 |
| Control Plane Nodes | Production clusters typically run 3 control plane nodes for high availability |
| Worker Nodes | Large clusters can exceed 1,000 worker nodes |
| Default Pods per Node | Up to 110 by default (configurable) |
| API Request Latency | 99th percentile typically under 1 second in well-tuned clusters |
| etcd | Can handle up to ~10,000 writes per second on NVMe storage |
Common Myths vs. Facts
| Myth | Fact |
|---|---|
| "Kubernetes runs containers directly on nodes." | Kubernetes never runs containers directly—they always run inside Pods, which are the smallest deployable units that include networking and storage . |
| "The API server is a single point of failure." | kube-apiserver is designed to scale horizontally by deploying multiple instances with load balancing . |
| "All Kubernetes clusters must run kube-proxy." | Network plugins can implement their own service proxying, making kube-proxy optional in those cases . |
| "Pods should always contain just one container." | Pods can contain multiple tightly coupled containers that share networking and storage, such as a web server and a logging container . |
| "etcd data isn't critical for cluster operation." | etcd is the backing store for all cluster data, and you must have a backup plan for it . |
What You Should Do With This Knowledge
To effectively work with Kubernetes architecture:
- Start with managed Kubernetes if you're new—services like GKE, EKS, or AKS abstract away control plane management so you can focus on applications.
- Learn to read YAML manifests for core resources: Pods, Deployments, Services, and ConfigMaps. These are the fundamental building blocks you'll use daily .
- Use kubectl's describe and logs commands to troubleshoot issues—understanding how components communicate will help you diagnose problems faster.
- Always specify resource requests and limits in your Deployment manifests. This helps the scheduler make optimal placement decisions and prevents resource starvation .
- Explore network policies to secure communication between Pods once you understand the basic architecture.
Frequently Asked Questions
What is the difference between a Deployment and a Service? A Deployment manages the lifecycle of Pod replicas—it ensures a specified number of identical Pods are running and handles updates and rollbacks. A Service provides a stable network endpoint to access those Pods, which are ephemeral and can be replaced at any time .
Why does Kubernetes need etcd? etcd serves as Kubernetes' primary datastore, consistently and durably storing all cluster state information, including which Pods are running, what Services exist, and configuration data . Without etcd, the cluster has no "source of truth" about its desired and actual state.
What happens if a worker node goes down? The Node controller detects node unavailability (typically after a timeout period). The scheduler then reschedules any Pods that were running on the failed node to other healthy nodes, maintaining the desired number of replicas .
How does a Service route traffic to Pods? A Service maintains a set of endpoints—the IP addresses of Pods that match its label selector. kube-proxy on each node programs network rules (iptables or IPVS) that redirect traffic destined for the Service's virtual IP to these endpoints, providing load balancing across Pods .
What's the difference between a Job and a CronJob? A Job creates one or more Pods and ensures they successfully terminate—it's used for one-off tasks like running a database backup. A CronJob creates Jobs on a recurring schedule, useful for periodic maintenance tasks such as daily log cleanup .
Sources
- Kubernetes Official Documentation – Cluster Architecture
- SLAC National Accelerator Laboratory Kubernetes Training Documentation
- KodeKloud Kubernetes Introduction Notes
- LabEx Kubernetes Tutorials and Guides
- Comprehensive Guide to Kubernetes (GitHub)
— Editorial Team
No comments yet.