Kubernetes Architecture Explained

# Kubernetes Architecture Explained

Introduction

Kubernetes (K8s) is an open-source container orchestration platform that automates deploying, scaling, and operating application containers. Originally developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF), Kubernetes provides a framework for running distributed systems resiliently.

This tutorial explains Kubernetes architecture, including the control plane, worker nodes, core components, and how they work together to manage containerized workloads.

Learning Objectives

By the end of this tutorial, you will be able to:

• Explain Kubernetes architecture and core components
• Describe the control plane and worker node components
• Understand the Kubernetes API and declarative model
• Explain how the scheduler, controller manager, and etcd work
• Describe pod lifecycle and container runtime integration
• Understand Kubernetes networking model
• Design Kubernetes clusters for production

Technical Background

Kubernetes Cluster Architecture

flowchart TB
    subgraph Control Plane
    API[API Server]
    Sched[Scheduler]
    CM[Controller Manager]
    ETCD[(etcd)]
    CCM[Cloud Controller Manager]
    end
    
    subgraph Worker Node 1
    Kubelet1[Kubelet]
    KProxy1[Kube-Proxy]
    Pod1[Pod]
    CR1[Container Runtime]
    end
    
    subgraph Worker Node 2
    Kubelet2[Kubelet]
    KProxy2[Kube-Proxy]
    Pod2[Pod]
    CR2[Container Runtime]
    end
    
    User[User/Developer] -->|kubectl/API| API
    API --> ETCD
    API --> Sched
    Sched -->|Assign Pod| Kubelet1
    Sched -->|Assign Pod| Kubelet2
    CM -->|Watch State| API
    Kubelet1 -->|Run Container| CR1
    Kubelet2 -->|Run Container| CR2
    KProxy1 -->|Network| Pod1
    KProxy2 -->|Network| Pod2

Control Plane Components

| Component | Description | Runs On | |-----------|-------------|---------| | API Server | Frontend for Kubernetes API; handles all REST operations | Control plane nodes | | etcd | Consistent key-value store for cluster state | Control plane nodes | | Scheduler | Assigns pods to nodes based on resource availability | Control plane nodes | | Controller Manager | Runs controllers that regulate cluster state | Control plane nodes | | Cloud Controller Manager | Interacts with cloud provider APIs | Control plane nodes |

Worker Node Components

| Component | Description | |-----------|-------------| | Kubelet | Agent that runs on each node; ensures pods are running | | Kube-Proxy | Network proxy that implements Kubernetes Service concept | | Container Runtime | Software that runs containers (containerd, CRI-O, Docker) | | kube-proxy | Maintains network rules on nodes |

Prerequisites

• Understanding of containerization (Docker)
• Basic knowledge of Linux networking
• Understanding of YAML syntax
• Familiarity with cloud computing concepts

Hardware and Software Requirements

| Component | Requirement | |-----------|-------------| | Control Plane | 2+ CPU, 4+ GB RAM per node | | Worker Node | 2+ CPU, 4+ GB RAM per node | | OS | Linux (Ubuntu, RHEL, or similar) | | Container Runtime | containerd, CRI-O, or Docker | | Network | CNI plugin (Calico, Flannel, Cilium) |

Step-by-Step Implementation

Phase 1: Control Plane Components

#### API Server

The API server (kube-apiserver) is the central component of the control plane. It exposes the Kubernetes API and handles all REST operations. All other components interact with the cluster through the API server.

# Example: Start API server
kube-apiserver \
  --advertise-address=192.168.1.10 \
  --allow-privileged=true \
  --authorization-mode=Node,RBAC \
  --client-ca-file=/etc/kubernetes/pki/ca.crt \
  --etcd-servers=https://127.0.0.1:2379 \
  --service-account-key-file=/etc/kubernetes/pki/sa.pub \
  --service-cluster-ip-range=10.96.0.0/12

#### etcd

etcd is a distributed key-value store that holds all cluster state. It is the single source of truth for Kubernetes.

# Example: Start etcd
etcd \
  --advertise-client-urls=https://127.0.0.1:2379 \
  --cert-file=/etc/kubernetes/pki/etcd/server.crt \
  --data-dir=/var/lib/etcd \
  --initial-cluster=https://127.0.0.1:2380

#### Scheduler

The scheduler watches for newly created pods that have no node assigned and selects the best node for them based on resource constraints, policies, and affinity rules.

#### Controller Manager

The controller manager runs controller processes that watch the cluster state and make changes to move the current state toward the desired state. Controllers include:

• Node controller: Manages node lifecycle
• Replication controller: Maintains correct number of pods
• Endpoints controller: Populates Endpoints objects
• Service account controller: Creates default service accounts

Phase 2: Worker Node Components

#### Kubelet

The kubelet is the primary node agent. It:

1. Receives pod specifications from the API server 2. Ensures containers described in pods are running 3. Reports node and pod status back to the API server 4. Mounts volumes and downloads secrets

# Example: Start kubelet
kubelet \
  --address=0.0.0.0 \
  --anonymous-auth=false \
  --authorization-mode=Webhook \
  --client-ca-file=/etc/kubernetes/pki/ca.crt \
  --cloud-provider= \
  --cluster-dns=10.96.0.10 \
  --cluster-domain=cluster.local

#### Kube-Proxy

kube-proxy maintains network rules on nodes and implements the Kubernetes Service abstraction. It supports three modes:

• **iptables:** Uses Linux iptables rules (default)
• **ipvs:** Uses Linux IP Virtual Server (better for large clusters)
• **userspace:** Legacy userspace proxy

#### Container Runtime

The container runtime runs containers. Kubernetes supports any runtime implementing the Container Runtime Interface (CRI):

• containerd
• CRI-O
• Docker (via cri-dockerd, deprecated)

Phase 3: Kubernetes Objects

#### Pod

The pod is the smallest deployable unit in Kubernetes. A pod contains one or more containers that share storage, network, and a specification for how to run them.

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

#### Deployment

Deployments manage replica sets and provide declarative updates for pods.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

#### Service

Services enable network access to a set of pods.

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

Phase 4: Kubernetes API and Declarative Model

Kubernetes uses a declarative model where you describe the desired state, and Kubernetes works to maintain it.

# Apply desired state
kubectl apply -f deployment.yaml

# Check current state
kubectl get deployments

# Describe resource details
kubectl describe deployment nginx-deployment

# Delete resource
kubectl delete -f deployment.yaml

Phase 5: Kubernetes Networking

#### Network Model

Kubernetes networking follows these principles:

1. All pods can communicate with all other pods without NAT 2. All nodes can communicate with all pods without NAT 3. The IP a pod sees itself as is the same IP others see it as

#### Service Types

| Type | Description | |------|-------------| | ClusterIP | Internal cluster IP (default) | | NodePort | Exposes service on node port | | LoadBalancer | Cloud provider load balancer | | ExternalName | Maps to external DNS name |

#### Ingress

Ingress manages external access to services, typically HTTP/HTTPS.

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

Expected Output

• Understanding of Kubernetes architecture components
• Knowledge of control plane and worker node responsibilities
• Ability to create and manage Kubernetes objects
• Understanding of Kubernetes networking model
• Foundation for production Kubernetes deployment

Verification Procedures

| Check | Method | Expected Result | |-------|--------|-----------------| | Cluster health | `kubectl cluster-info` | Control plane responding | | Node status | `kubectl get nodes` | All nodes Ready | | Pod status | `kubectl get pods` | All pods Running | | API connectivity | `kubectl get all` | Resources listed | | Component status | `kubectl get componentstatuses` | All components healthy |

Troubleshooting Scenarios

| Issue | Diagnosis | Resolution | |-------|-----------|------------| | Pod in Pending state | No node available or resources insufficient | Add nodes; reduce resource requests | | Pod in CrashLoopBackOff | Application crashing | Check pod logs; fix application | | Node NotReady | Kubelet not running or network issue | Check kubelet; verify node network | | Service not reachable | Wrong selector or port | Verify service selector matches pod labels | | DNS not working | CoreDNS not running | Check CoreDNS pod; verify cluster DNS config |

Best Practices

• **Use declarative configuration:** Store all Kubernetes objects in YAML files
• **Use labels and selectors:** Organize resources with meaningful labels
• **Set resource requests and limits:** Prevent resource exhaustion
• **Use health probes:** Configure liveness and readiness probes
• **Use namespaces:** Organize resources by environment or team
• **Use RBAC:** Implement least-privilege access control
• **Use health probes:** Configure liveness and readiness probes
• **Monitor cluster:** Track node, pod, and application health

Security Considerations

• **RBAC:** Implement role-based access control
• **Pod Security Standards:** Enforce security policies
• **Network Policies:** Control pod-to-pod communication
• **Secrets:** Use Kubernetes Secrets for sensitive data
• **Container images:** Scan images for vulnerabilities
• **API server access:** Restrict access to the Kubernetes API

Conclusion

Kubernetes architecture provides a robust foundation for container orchestration. Understanding the control plane, worker nodes, core components, and networking model is essential for designing and operating production Kubernetes clusters. With this knowledge, you can deploy, scale, and manage containerized applications reliably.

References

• Kubernetes Documentation: https://kubernetes.io/docs/home/
• Kubernetes Architecture: https://kubernetes.io/docs/concepts/architecture/
• CNCF: https://www.cncf.io/
• Kubernetes Components: https://kubernetes.io/docs/concepts/overview/components/
• Kubernetes Objects: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/