Core Architecture
Understanding the fundamental architecture of Kubernetes and how its components work together to orchestrate containers.
Control Plane Components
The control plane is the brain of Kubernetes, making global decisions about the cluster and responding to cluster events. It consists of several critical components that work together to maintain the desired state of your cluster.
API Server (kube-apiserver)
The front-end for the Kubernetes control plane
- Primary interface: All cluster operations go through the API server
- Authentication & Authorization: Validates and authorizes all API requests
- RESTful API: Exposes Kubernetes API using standard HTTP/HTTPS
- Horizontal scaling: Can run multiple instances for high availability
- Validation: Validates and configures data for API objects
etcd
Consistent and highly-available key-value store for all cluster data
- Cluster state: Stores all cluster configuration and state
- Source of truth: The only persistent data store in the control plane
- Raft consensus: Uses Raft algorithm for distributed consensus
- Watch mechanism: Components can watch for changes to specific keys
- Backup critical: Regular backups are essential for disaster recovery
Scheduler (kube-scheduler)
Assigns pods to nodes based on resource requirements and constraints
- Pod placement: Watches for newly created Pods with no assigned node
- Resource aware: Considers CPU, memory, and custom resource requirements
- Affinity rules: Respects node affinity, pod affinity, and anti-affinity
- Taints and tolerations: Honors node taints and pod tolerations
- Scoring: Ranks nodes and selects the most suitable one
Controller Manager (kube-controller-manager)
Runs controller processes that regulate the state of the cluster
- Node Controller: Monitors node health and responds to node failures
- Replication Controller: Maintains correct number of pods for ReplicaSets
- Endpoints Controller: Populates Endpoints objects (joins Services & Pods)
- Service Account Controller: Creates default ServiceAccounts for namespaces
- Reconciliation loop: Continuously works to match desired state
Cloud Controller Manager
Runs controllers that interact with cloud providers
- Node Controller: Checks if nodes are deleted from cloud provider
- Route Controller: Sets up routes in the cloud infrastructure
- Service Controller: Creates, updates, and deletes cloud load balancers
- Volume Controller: Creates, attaches, and mounts volumes
- Cloud-specific: Separates cloud-dependent code from core Kubernetes
Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
Kubelet
The primary node agent that ensures containers are running in pods
- Pod lifecycle: Takes PodSpecs and ensures containers are running and healthy
- Container runtime: Communicates with container runtime (Docker, containerd, CRI-O)
- Node registration: Registers the node with the API server
- Health checks: Performs liveness and readiness probes
- Resource reporting: Reports node and pod resource usage
Kube-proxy
Network proxy that maintains network rules on nodes
- Service abstraction: Implements Kubernetes Service concept
- Load balancing: Distributes traffic across pod endpoints
- iptables/IPVS: Uses iptables or IPVS rules for packet forwarding
- Connection routing: Routes requests to appropriate backend pods
- Session affinity: Supports sticky sessions when configured
Container Runtime
Software responsible for running containers
- CRI-compliant: Must implement Container Runtime Interface (CRI)
- containerd (Most Popular): Graduated CNCF project, industry standard, lightweight and efficient
- CRI-O: Kubernetes-specific runtime, lightweight, OCI-compliant
- Docker Engine: Legacy support via cri-dockerd shim (Docker runtime deprecated in K8s 1.24+)
- Image management: Pulls container images from registries with caching and layer optimization
- Resource isolation: Uses Linux cgroups and namespaces for security and resource limits
2025 Update: containerd is now the de facto standard, used by all major cloud providers (EKS, GKE, AKS). Docker runtime support was removed in Kubernetes 1.24 (May 2022).
Core Kubernetes Objects
Kubernetes uses persistent entities called objects to represent the state of your cluster.
Pod
Smallest deployable unit; one or more containers that share resources
Service
Stable network endpoint for a set of pods with load balancing
Deployment
Declarative updates for Pods and ReplicaSets with rollback capability
Namespace
Virtual clusters for multi-tenancy and resource organization
ConfigMap
Non-confidential configuration data in key-value pairs
Secret
Sensitive information like passwords, tokens, or keys
Volume
Directory accessible to containers in a pod for persistent storage
Ingress
HTTP/HTTPS routing to services based on rules and hostnames
How It All Works Together
Example: Creating a Deployment
- kubectl apply: User creates a Deployment using kubectl, which sends request to API server
- API Server: Validates the request, authenticates user, and stores object in etcd
- Controller Manager: Deployment controller watches for new Deployments and creates ReplicaSet
- Controller Manager: ReplicaSet controller sees new ReplicaSet and creates Pod objects
- Scheduler: Notices unscheduled Pods and assigns them to appropriate nodes
- Kubelet: Node's kubelet sees Pods assigned to it and instructs container runtime
- Container Runtime: Pulls images and starts containers according to Pod spec
- Kube-proxy: Updates network rules to route traffic to new pods
The Reconciliation Loop
Kubernetes operates on a reconciliation model: controllers continuously compare the desired state (stored in etcd) with the actual state (running workloads) and take action to reconcile any differences.
This declarative approach means you describe what you want, and Kubernetes figures out how to make it happen, even in the face of failures or changes.
Key Takeaways
- Kubernetes uses a master-worker architecture with control plane and node components
- The API server is the central component that all other components interact with
- etcd is the single source of truth for all cluster state and must be backed up regularly
- Controllers continuously reconcile desired state with actual state
- Understanding the architecture is crucial for troubleshooting and optimization