Kubernetes 101 : What It Is, How It Works, and Why It Matters

Apr 14, 2025

In this second installement in my series of articles, I will cover the container orchestration tool Kubernetes. Since late 2024, I’ve been using Docker a lot for my projects. It’s been a game changer, no more dependency errors, broken setups, or messy environments. It just works. But once I started looking into real-world use cases for Docker, I saw a lot of mentions of Kubernetes, K8s for short.

What is Kubernetes ?

It’s an open source container orchestration platform. Which means that using it you can run, manage, and scale containerized apps accross clusters of machines. It’s designed for large-scale applications, where managing containers manually with Docker quickly gets messy. You have to worry about starting/stopping containers, restarting them when they crash, assigning ports, managing storage, keeping track of their health, and more.

Kubernetes handles all that for you:

It balances traffic across your containers. (load balancing)
It restarts failed ones.
It helps you update your app without downtime.
It scales your app up or down depending on demand.

The Core Concepts

🔹 The Control Plane (Master Node)

This is the brain of the cluster. It runs several components:

API Server – Entry point to the cluster. All tools (like kubectl) talk to it.
Scheduler – Decides which machine runs which container (Pod).
Controller Manager – Keeps tracks of everything and makes sure the actual state matches the desired state.
etcd – A key-value store that holds the cluster’s configuration and state.

In production, you’ll often have multiple control plane nodes for high availability.

🔹 Worker Nodes

These are the actual machines (physical or virtual) that run your app. They host:

Pods are the smallest unit in K8s. Each Pod usually runs one container (but it can run more).
Each Pod gets its own IP address, but if you delete and recreate a Pod, that IP changes that’s why we use Services.

🔹 Services

A Service is a stable network endpoint. It’s an abstraction that sits in front of a group of Pods and routes traffic to them, even if the individual Pods change.

Example of services.yml:

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

🔹 Volumes

Pods are temporary. If one dies, it’s replaced, but any data inside it disappears unless it’s stored externally. Volumes solve this by letting Pods use persistent storage, often provided by your cloud provider or external systems. They live outside the Pod lifecycle.

🔹 Ingress

When you want users to access your app (via HTTP), you don’t expose Pods or Services directly. Instead, you use Ingress. It’s like a smart router that receives incoming traffic and forwards it to the right Service.

It also supports things like:

TLS (HTTPS)
Path-based routing (e.g., /api vs /admin)

🔹 ConfigMap & Secret

ConfigMap – Store plain-text configurations (e.g., app settings, endpoints, etc.).

Example of configmap.yml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_NAME: "MyApp"
  API_ENDPOINT: "https://api.example.com"

Secret – Just like ConfigMap, but encrypted, it’s mainly used for things like API keys or tokens.

Example of secret.yml :

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_PASSWORD: bWVvdw==

Secrets are encoded by default (using base64, but better than plain text). In real setups, you’d use a third-party tool like HashiCorp Vault or a cloud key management service to handle sensitive data

🔹 The Virtual Network

Kubernetes sets up a cluster-wide virtual network that connects all Pods across all nodes — like they’re on the same local network.

Each Pod gets its own IP address.
Pods can talk to each other directly using these IPs, no matter which node they’re on.
You don’t need to set up port forwarding or NAT between nodes — Kubernetes handles it.

This network abstraction is what lets Kubernetes treat multiple worker nodes like one big machine. It’s also what allows Services, Ingress, and other components to route traffic reliably without knowing exactly where each container is running.

🔹 Deployments (blueprints)

A blueprint for your application in Kubernetes that tells the cluster what your app should look like and makes sure it stays that way.

It defines:

What image to run
How many replicas you want
How to roll out updates

Example of deployment.yml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

This will deploy 3 replicas of an NGINX container :

Run 3 Pods with the NGINX image
Expose port 80
Automatically replace any crashed Pods

In another installment of this series, I’ll walk through a hands-on test using Minikube.