Written by sumitbhoyar

Kubernetes

Kubernetes is an open‑source platform that automatically runs, scales, and heals containerized applications across a cluster of machines.

1. What Kubernetes is and why its components are used together

Kubernetes is a container orchestration system. Containers package your app and its dependencies. Kubernetes makes sure those containers run reliably on a group of machines called a cluster.

At a high level, Kubernetes is made of two big parts:

  • The control plane: the “brain” that decides what should run where.
  • The worker nodes: the “hands” that actually run your containers as pods (small groups of one or more containers).

The control plane provides a single API where you describe your desired state: “Run 3 copies of this service”, “Expose it on port 80”, etc. The worker nodes report their status and run the workloads the control plane assigns them.

All the components work together so that you can think in terms of applications and desired state, instead of individual servers and ad‑hoc scripts.

2. The specific problems Kubernetes solves

Kubernetes becomes useful when you outgrow “a few containers on a couple of VMs.” It focuses on a few core problems:

  1. Scheduling and placement
    When you have many containers and many machines, deciding “which container runs on which machine” is non‑trivial.
    Kubernetes’ scheduler continuously looks at the cluster and picks appropriate nodes for each pod, based on CPU, memory, and constraints.
  2. Keeping the desired state
    You declare what you want (e.g., 5 replicas of a service). Kubernetes control loops keep checking reality against that desired state.
    If a pod dies or a node disappears, Kubernetes replaces it automatically.
  3. Self‑healing and resilience
    Containers crash. Nodes can fail. Kubernetes detects these failures and recreates or reschedules pods without human intervention, improving uptime.
  4. Scaling up and down
    As load changes, you can scale replicas or even nodes. Kubernetes can integrate with autoscalers so your app scales based on CPU, requests, or custom metrics.
  5. Service discovery and load balancing
    Pods come and go, and their IPs change. Kubernetes Services provide a stable address and automatically route traffic to healthy pods, balancing load.
  6. Portable, cloud‑agnostic deployment
    Kubernetes can run on‑prem, on any major cloud, or in hybrid setups. Your deployment model stays consistent as you move environments.

In short, Kubernetes turns a group of machines into a reliable, programmable application platform.

3. High‑level integration flow (conceptual)

Here is how things work together when you deploy and run an app on Kubernetes:

  1. You define desired state
    You describe what you want in Kubernetes resources: for example, a Deployment that says “run this container image, 3 replicas, with these resource limits.”
  2. The API server stores and exposes the state
    The API server receives these definitions and stores them in etcd, a distributed key‑value store that represents the cluster’s state.
  3. Controllers ensure reality matches the desired state
    Controllers (part of the control plane) continuously watch the API server.
  • If a Deployment says 3 replicas and only 1 pod exists, the controller manager creates more pods until the count matches.
  1. Scheduler places pods on worker nodes
    Whenever there is a “pending” pod, the scheduler chooses a suitable worker node (enough resources, correct constraints) and assigns the pod there.
  2. Kubelet runs and monitors pods on each node
    On every worker node, a kubelet agent talks to the API server, learns which pods should run on that node, and uses the container runtime (e.g., containerd) to start and monitor containers.
  3. Networking routes traffic to the right pods
    Each pod gets an IP address. A CNI plugin sets up networking so pods across nodes can talk.
    kube‑proxy on each node ensures that Service IPs route to the correct backend pods and load balance traffic.
  4. Continuous reconciliation and self‑healing
    The control plane keeps watching: if a node dies, if a pod crashes, or if you change a spec (e.g., scale from 3 to 10 replicas), Kubernetes reacts until the actual state once again matches the desired state.

From your perspective, you focus on declaring intent, while Kubernetes manages the ongoing work to maintain it.

4. Plain text diagram of main components and flows

Below is a simplified logical view (not every component, just the essentials):

                   +----------------------+
                   |      You / CI/CD     |
                   |  (kubectl / API)     |
                   +----------+-----------+
                              |
                              v
                     +--------+---------+
                     |   API Server     |  <-- Front door to the cluster
                     +--------+---------+
                              |
                 (stores desired & current state)
                              v
                          +---+---+
                          | etcd  |
                          +---+---+
                              ^
          watches state       |        writes updated state
   +--------------------------+-----------------------------+
   |                                                        |
   v                                                        v
+--------+                                      +------------------+
|Scheduler|  <-- decides which node             | Controller Mgr   |
+--------+      runs each Pod                   | (various loops)  |
        \                                       +--------+---------+
         \                                                |
          \-----------------------------------------------/
                              |
                              | assigns pods to nodes
                              v
         =======================================================
         |                 Worker Nodes                        |
         |                                                    |
         |  +----------------+     +----------------+        |
         |  | Node 1         |     | Node 2         |  ...   |
         |  |                |     |                |        |
         |  | +-----------+  |     | +-----------+  |        |
         |  | | kubelet   |<-------->| kubelet   |  |        |
         |  | +-----------+  |     | +-----------+  |        |
         |  | +-----------+  |     | +-----------+  |        |
         |  | |kube-proxy|<-------->|kube-proxy |  |        |
         |  | +-----------+  |     | +-----------+  |        |
         |  | +-----------+  |     | +-----------+  |        |
         |  | |Pod(s)    |   |     | |Pod(s)    |   |        |
         |  | +-----------+  |     | +-----------+  |        |
         |  +----------------+     +----------------+        |
         =======================================================
                              ^
                              |
                     Service IPs / Load Balancing
                     for traffic into the cluster

5. Alternative tools and how their models compare

Several systems provide similar orchestration or abstract it away. The important differences are in scope, abstractions, and how much of the system you see.

Docker Swarm

  • What it is: Orchestration built into Docker, with manager and worker nodes, and “services” that describe desired containers.
  • System model vs Kubernetes:
  • Simpler architecture: fewer component types (manager, worker, service, task) versus Kubernetes’ many controllers and objects.
  • Still has a control plane and workers, but less layered: no etcd exposed, fewer APIs, and fewer built‑in concepts like Deployments or Ingress.
  • Good mental model: “Docker with clustering,” whereas Kubernetes is a general platform with a rich API and many control loops.

HashiCorp Nomad

  • What it is: A general‑purpose scheduler for containers and non‑container workloads (VMs, batch jobs, legacy apps).
  • System model vs Kubernetes:
  • Focuses on scheduling and cluster management, while delegating service discovery and secrets to other tools (Consul, Vault).
  • Uses job specifications and a simpler control plane; fewer built‑in resource types than Kubernetes, which has a large API surface and many controllers.
  • Treats orchestration like “one powerful scheduler plus integrations,” whereas Kubernetes is “a full platform with many controllers and resource kinds.”

Managed / serverless container platforms

Examples: AWS ECS, Google Cloud Run, Azure Container Apps.

  • What they are: Cloud‑provider services that hide most of the orchestration system.
  • System model vs Kubernetes:
  • You see higher‑level units (tasks, services, revisions) and never manage a cluster, API server, or etcd.
  • The provider runs an internal control plane; you only interact with a simplified API and autoscaling knobs.
  • Good mental model: “I submit containers and traffic rules; the provider runs an invisible orchestrator for me.”

In summary:

  • Kubernetes exposes a rich, extensible control plane with many resource types and controllers.
  • Docker Swarm keeps a simpler, Docker‑centric model.
  • Nomad is a lean scheduler that composes with other HashiCorp tools.
  • Managed/serverless platforms hide orchestration internals behind higher‑level APIs.

6. Sample Kubernetes configuration file (to see the system in action)

Below is a minimal example that shows how you describe desired state in Kubernetes.
It defines:

  • A Deployment: runs a replicated stateless app.
  • A Service: gives that app a stable network endpoint.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-web
spec:
  replicas: 3                      # Desired number of pod replicas
  selector:
    matchLabels:
      app: demo-web                # Pods belonging to this Deployment
  template:
    metadata:
      labels:
        app: demo-web              # Labels applied to pods
    spec:
      containers:
        - name: demo-web-container
          image: nginx:1.25        # Container image to run
          ports:
            - containerPort: 80    # Port exposed by the container

---
apiVersion: v1
kind: Service
metadata:
  name: demo-web-svc
spec:
  type: ClusterIP                  # Internal virtual IP inside the cluster
  selector:
    app: demo-web                  # Targets pods with this label
  ports:
    - port: 80                     # Service port
      targetPort: 80               # Container port in the pods

How the system processes this:

  1. Submit the manifest
    You send this YAML to the Kubernetes API server.
  2. API server and etcd
  • API server validates it and stores both the Deployment and Service objects in etcd as desired state.
  1. Deployment controller creates ReplicaSet and Pods
  • The Deployment controller sees the new Deployment.
  • It creates a ReplicaSet and pods so that replicas: 3 is satisfied.
  • These pods appear as “pending” until scheduled.
  1. Scheduler assigns pods to nodes
  • Scheduler looks at available nodes and binds each pod to some node.
  1. kubelet and container runtime start containers
  • On each selected node, kubelet sees the new pods assigned to that node.
  • It asks the container runtime to pull nginx:1.25 and start the containers.
  1. Service and kube‑proxy wire networking
  • The Service selects pods with app: demo-web.
  • kube‑proxy on each node programs rules so traffic to demo-web-svc’s virtual IP:80 is load‑balanced across those pods.
  1. Ongoing reconciliation
  • If a pod crashes, the ReplicaSet controller creates a replacement until there are always 3 healthy pods.
  • If you change replicas to 5, the controller creates two more pods; scheduler and kubelets handle placement and startup.

This small file encodes all the instructions the system needs: what to run, how many copies, and how to reach them. The control plane and worker nodes collaborate (via the loops described earlier) to continuously maintain that state.

Leave a comment