Kubernetes Architecture & Components Overview

You’re about to run applications in production on Kubernetes. Before you dive into YAML and deployments, you need to understand who does what inside a cluster. Think of this chapter as your mental model — the map you’ll reference every time something breaks.

Let’s walk through the control plane, the worker nodes, and the core objects that glue everything together.

The Control Plane — The Brain of the Cluster

The control plane is the set of components that make global decisions about the cluster. It’s the management layer — it schedules workloads, responds to events, and maintains the desired state.

If the cluster were an airport, the control plane would be the air traffic control tower. The workers (nodes) are the runways and gates where actual planes (your containers) operate.

API Server — The Front Door

Everything talks to the API server. kubectl, CI/CD pipelines, the scheduler, controllers, even the nodes themselves — every single interaction goes through this single endpoint.

In production, your API server must be highly available. On EKS, AWS runs it across three Availability Zones automatically. If you’re self-managing, you need at least three control plane nodes with a load balancer in front.

etcd — The Source of Truth

etcd is a distributed key-value store that holds the entire cluster state — every deployment, every secret, every node, every config map. It’s the cluster’s memory.

Here’s what your etcd backup strategy should look like in practice:

# Backup etcd (self-managed clusters)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# On EKS — etcd is managed by AWS, but back up cluster resources with Velero
velero backup create daily-backup --include-cluster-resources=true --ttl 168h

Controller Manager — The Desired State Enforcer

The controller manager runs controllers — loops that watch the current state of the cluster and work to make it match the desired state.

If you set replicas: 3 on a Deployment and a node dies taking one pod with it, the controller manager detects the drift and schedules a replacement. It never sleeps, never gets distracted.

Scheduler — The Pod Placement Engine

When a new pod is created (with no node assigned), the scheduler picks the best node for it. It evaluates:

• Resource requirements — does the node have enough CPU/memory?
• Affinity and anti-affinity rules — should this pod run near or away from other pods?
• Taints and tolerations — is the pod allowed on this node?
• Node health — is the node reporting ready?

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: payment-service
          topologyKey: "topology.kubernetes.io/zone"

Worker Nodes — Where the Work Happens

Worker nodes are the machines (EC2 instances, bare metal, or VMs) that run your containerized applications. Each node runs three essential components:

kubelet — The Node Agent

The kubelet is an agent that runs on every node. It registers the node with the control plane and ensures containers are running as instructed by the API server.

If the kubelet stops reporting, the control plane marks the node as NotReady after a timeout and reschedules the pods elsewhere. This is why monitoring kubelet health is critical.

Container Runtime — Actually Running Things

The container runtime is the software that pulls images and runs containers. In modern Kubernetes, that’s almost always containerd or CRI-O. Docker was deprecated as a runtime after Kubernetes 1.24.

kube-proxy — Network Rules Manager

kube-proxy maintains network rules on each node. It implements Kubernetes Services by managing iptables or IPVS rules, routing traffic to the right pods.

Node Groups & Instance Diversity

In production, you rarely have a single pool of identical nodes. Different workloads have different needs:

Pods & Higher-Level Controllers

The pod is the smallest deployable unit in Kubernetes. But in production, you almost never create pods directly — you use controllers that manage pods for you.

Deployments — The Workhorse

Deployments manage stateless applications. They handle:

• Running a specified number of replicas
• Rolling updates with zero downtime
• Rollbacks to a previous version
• Horizontal scaling (manual or via HPA)

A production-ready Deployment has three things you should never skip:

Here’s what a production-ready Deployment looks like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  namespace: production
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: payment-api
              topologyKey: "topology.kubernetes.io/zone"
      containers:
        - name: app
          image: myapp/payment-api:v2.1.4
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: 500m
              memory: 768Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5

StatefulSets — For Apps That Need Identity

StatefulSets are for stateful applications — databases, message brokers, anything that needs stable network identities and persistent storage.

Each pod in a StatefulSet gets:

• A stable hostname (e.g., db-0, db-1, db-2)
• Its own persistent volume (that survives rescheduling)
• Ordered, graceful deployment and scaling

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  template:
    spec:
      containers:
        - name: postgres
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 100Gi

DaemonSets — One Pod Per Node

DaemonSets ensure every node runs a copy of a pod. They’re perfect for:

• Log shippers — Fluent Bit, Filebeat
• Monitoring agents — Node Exporter, Datadog agent
• Network plugins — Calico, Cilium
• Security agents — Falco, Aqua

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: observability
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    spec:
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:3.0
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

Jobs & CronJobs — One-Time & Scheduled Tasks

Jobs run a set of pods to completion — useful for batch processing, database migrations, or data exports. CronJobs add a schedule:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: myapp/backup-tool:1.0
              command: ["pg_dump", "-Fc", "myapp_prod", "-f", "/backups/dump.sqlc"]
          restartPolicy: OnFailure

Services — Stable Networking for Ephemeral Pods

Pods come and go. They get rescheduled, replaced, and restarted. Services provide a stable endpoint (a virtual IP and DNS name) that persists regardless of pod churn.

Namespaces — Organizing Your Cluster

Namespaces are virtual clusters within your physical cluster. They provide:

• Isolation — separate teams, environments, or applications
• Scope — for resource names (you can have a payment-api service in both staging and prod namespaces)
• Policy boundaries — RBAC, network policies, and resource quotas apply at the namespace level

kubectl create namespace production
kubectl create namespace staging

kubectl config set-context prod --namespace=production
kubectl config set-context stage --namespace=staging

What’s Next?

Now that you understand the architecture, the next guide will cover High Availability Architecture — designing your cluster to survive failures, including control plane redundancy, multi-AZ distribution, and upgrade strategies.