Kubernetes Architecture
Understanding Kubernetes architecture is crucial for effectively working with the platform. Let’s explore how Kubernetes components work together.
Overview
Kubernetes follows a master-worker architecture with two main components:
- Control Plane - The brain of the cluster
- Worker Nodes - Run your applications
Control Plane Components
The control plane manages the cluster state and makes decisions about scheduling, scaling, and maintaining desired state.
API Server (kube-apiserver)
The API server is the front-end for the Kubernetes control plane. It exposes the Kubernetes API and processes REST operations.
Key responsibilities:
- Authentication and authorization
- Validating and processing API requests
- Updating etcd with cluster state
etcd
etcd is a consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.
What it stores:
- Cluster configuration
- Resource definitions
- Current state of all objects
Scheduler (kube-scheduler)
The scheduler watches for newly created Pods with no assigned node and selects a node for them to run on.
Selection factors:
- Resource requirements
- Hardware/software constraints
- Affinity and anti-affinity specifications
- Data locality
Controller Manager (kube-controller-manager)
Runs controller processes that regulate the state of the cluster.
Key controllers:
- Node Controller - Monitors node health
- Replication Controller - Maintains correct number of pods
- Endpoints Controller - Populates Endpoints objects
- Service Account Controller - Creates default service accounts
Cloud Controller Manager
Integrates with cloud provider APIs for resources like load balancers and storage volumes.
Worker Node Components
Worker nodes run containerized applications and maintain runtime environment.
kubelet
The kubelet is an agent running on each node, ensuring containers are running in Pods.
Responsibilities:
- Registers node with API server
- Monitors Pod health
- Reports node and Pod status
- Mounts volumes
- Pulls container images
Container Runtime
The container runtime pulls images and runs containers. Kubernetes supports:
- containerd (most common)
- CRI-O
- Docker (deprecated but still used)
kube-proxy
Maintains network rules on nodes, enabling network communication to Pods.
Functions:
- Implements Services abstraction
- Routes traffic to correct Pods
- Load balances requests
Communication Flow
Here’s how components communicate:
- kubectl sends commands to API Server
- API Server validates and stores data in etcd
- Scheduler watches API Server for unscheduled Pods
- Scheduler assigns Pods to nodes via API Server
- kubelet on selected node watches API Server
- kubelet instructs container runtime to start containers
- kubelet reports status back to API Server
Cluster Networking
Kubernetes networking follows these principles:
- Every Pod gets its own IP address
- Pods can communicate without NAT
- Nodes can communicate with Pods without NAT
- The IP a Pod sees is the same IP others see
AddOns
AddOns extend Kubernetes functionality:
- DNS - Cluster DNS for service discovery
- Dashboard - Web-based UI
- Monitoring - Metrics collection (Prometheus, Grafana)
- Logging - Log aggregation (ELK, Loki)
High Availability
Production clusters run multiple control plane instances:
- Multiple API servers (load balanced)
- Multiple etcd instances (clustered)
- Active controller managers with leader election
- Active schedulers with leader election
Viewing Cluster Components
Inspect your cluster components:
# View all pods in kube-system namespacekubectl get pods -n kube-system
# Get detailed info about API serverkubectl get pods -n kube-system -l component=kube-apiserver
# View node statuskubectl get nodes -o wide
# Describe a nodekubectl describe node minikubeNext Steps
Now that you understand Kubernetes architecture, let’s explore Pods - the smallest deployable units in Kubernetes.