DevopsIntermediate20 min readUpdated March 2025

Kubernetes Architecture

Kubernetes (K8s) is the de facto standard for container orchestration. It automates deployment, scaling, and management of containerized applications across clusters of machines. Understanding its architecture is essential for operating it effectively.

What is Kubernetes?

Kubernetes is an open-source container orchestration system originally developed by Google (based on their internal Borg system) and donated to the CNCF in 2014.

It solves the operational challenges of running containers at scale: - Scheduling — Deciding which node to run each container on - Self-healing — Restarting failed containers, replacing unhealthy nodes - Scaling — Automatically scaling applications up or down based on load - Service discovery — Containers find each other by name, not IP - Rolling updates — Deploy new versions with zero downtime - Secret management — Store and inject sensitive configuration

The Control Plane (Master Node)

The Control Plane is the brain of Kubernetes. It makes global decisions about the cluster and detects/responds to cluster events. It consists of:

kube-apiserver — The front-end for the Kubernetes control plane. All communication (kubectl, nodes, controllers) goes through the API server. It validates and processes REST requests.
etcd — A distributed key-value store that holds all cluster state and configuration. The single source of truth for the cluster. Always back this up!
kube-scheduler — Watches for newly created Pods with no assigned node and selects a node for them to run on based on resource requirements, affinity rules, and constraints.
kube-controller-manager — Runs controller loops that watch the cluster state and make changes to move toward the desired state (Node Controller, Replication Controller, Endpoints Controller).
cloud-controller-manager — Integrates with cloud provider APIs (AWS, GCP, Azure) to manage load balancers, storage volumes, and node lifecycle.

Worker Nodes

Worker nodes are the machines (VMs or physical servers) that run your application containers. Each worker node runs:

kubelet — An agent that runs on each node. It communicates with the API server and ensures containers described in PodSpecs are running and healthy.
kube-proxy — A network proxy that maintains network rules on nodes. It implements the Kubernetes Service concept by forwarding traffic to the correct Pod.
Container Runtime — The software that runs containers. Kubernetes supports containerd (default), CRI-O, and Docker (via shim). Implements the Container Runtime Interface (CRI).

The Kubernetes Object Model

Everything in Kubernetes is an object — a persistent entity that represents the desired state of your cluster. You declare the desired state in YAML manifests and submit them to the API server. Kubernetes continuously works to make the actual state match the desired state (the reconciliation loop).

yaml

# Every Kubernetes object has these four required fields:
apiVersion: apps/v1       # API group and version
kind: Deployment          # Type of object
metadata:
  name: my-app            # Unique name within namespace
  namespace: production   # Logical grouping
  labels:
    app: my-app
    version: "1.0"
spec:                     # Desired state (what you want)
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: myrepo/my-app:1.0
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "64Mi" cpu:"250m"
          limits:
            memory: "128Mi" cpu:"500m"
# status:                 # Actual state (managed by Kubernetes, read-only)

kubectl: The Kubernetes CLI

kubectl is the command-line tool for interacting with Kubernetes clusters. It communicates with the kube-apiserver.

bash

# ---- Cluster Info ----
kubectl cluster-info
kubectl get nodes                          # List all nodes
kubectl describe node worker-1             # Detailed node info

# ---- Working with Resources ----
kubectl apply -f deployment.yaml           # Create/update from manifest
kubectl get pods                           # List pods in default namespace
kubectl get pods -n production             # List pods in specific namespace
kubectl get all -n production              # List all resources in namespace
kubectl describe pod my-app-abc123         # Detailed pod info + events
kubectl logs my-app-abc123                 # Pod logs
kubectl logs -f my-app-abc123             # Follow logs
kubectl exec -it my-app-abc123 -- bash    # Shell into pod

# ---- Scaling and Updates ----
kubectl scale deployment my-app --replicas=5
kubectl set image deployment/my-app my-app=myrepo/my-app:2.0
kubectl rollout status deployment/my-app
kubectl rollout undo deployment/my-app    # Rollback to previous version

# ---- Namespaces ----
kubectl create namespace staging
kubectl config set-context --current --namespace=staging

Namespaces and Resource Isolation

Namespaces provide a mechanism for isolating groups of resources within a single cluster. They are useful for:

- Multi-tenancy — Separate teams or projects in the same cluster - Environment separation — dev, staging, production in one cluster - Resource quotas — Limit CPU/memory per namespace - RBAC — Grant permissions scoped to a namespace

Default namespaces: default (user workloads), kube-system (Kubernetes components), kube-public (publicly readable), kube-node-lease (node heartbeats).

Key Takeaways

The Control Plane (API server, etcd, scheduler, controllers) manages the cluster; worker nodes run workloads.
etcd is the single source of truth — always back it up in production.
Kubernetes uses a reconciliation loop: continuously comparing desired state (spec) to actual state (status).
Every resource is declared as a YAML manifest with apiVersion, kind, metadata, and spec.
kubectl apply -f is the primary way to create and update resources declaratively.

Contact Us

Have a question or feedback? Fill out the form below or reach us directly at support@nvaitraining.com