Kubernetes (K8s)

1. Why Kubernetes Exists

You know Docker. You can run containers. But what happens when your app gets popular?

• You need to run 50 copies of your API across 10 servers to handle the traffic
• If one container crashes, something needs to automatically restart it
• When you deploy a new version, you want zero downtime -- no one should notice the update
• You need to distribute traffic evenly across all those containers
• Some containers need more CPU, others need more memory -- you need smart scheduling

Doing all of this manually with docker run commands would be a nightmare. Kubernetes automates all of it.

2. K8s Architecture

A Kubernetes cluster is a group of machines (physical or virtual) that run your containers together. There are two types of machines in a cluster:

Control Plane (The Brain)

This is the management layer. It makes all the decisions -- where to run containers, when to restart them, how to scale. You never run your app on the control plane. It has these components:

Worker Nodes (The Muscle)

These are the machines that actually run your containers. Each node has:

3. Core Objects: Pods, Deployments, Services

Everything in Kubernetes is an object defined in YAML. There are three you absolutely need to understand:

Pod -- The Smallest Unit

A Pod is the smallest thing you can deploy in Kubernetes. It's a wrapper around one or more containers that share the same network and storage.

Deployment -- Managing Pods

A Deployment tells Kubernetes: "I want N copies of this Pod running at all times." It handles:

• Replication -- Run 3 copies of my API
• Rolling updates -- Deploy a new version without downtime
• Rollback -- If the new version is broken, go back to the old one
• Self-healing -- If a Pod crashes, start a new one

Service -- Exposing Pods to Traffic

Pods get random IP addresses that change every time they restart. You can't hard-code those IPs. A Service gives your Pods a stable address and load-balances traffic across them.

4. Writing K8s YAML

Everything in K8s is declared in YAML files. You tell Kubernetes what you want, and it makes it happen. Here are the essential configs:

Deployment YAML

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api               # Name of this deployment
spec:
  replicas: 3                # Run 3 copies of this Pod
  selector:
    matchLabels:
      app: my-api             # Find Pods with this label
  template:                   # Pod template
    metadata:
      labels:
        app: my-api           # Label for this Pod
    spec:
      containers:
        - name: api
          image: myapp:1.0    # Docker image to run
          ports:
            - containerPort: 3000
          env:
            - name: DATABASE_URL
              value: "postgres://user:pass@db-service:5432/mydb"
          resources:
            requests:           # Minimum resources needed
              memory: "128Mi"
              cpu: "100m"       # 100 millicores = 0.1 CPU
            limits:             # Maximum resources allowed
              memory: "256Mi"
              cpu: "500m"

Service YAML

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-api-service
spec:
  type: ClusterIP             # Internal only (default)
  selector:
    app: my-api               # Route to Pods with this label
  ports:
    - port: 80                # Port other services use
      targetPort: 3000        # Port on the container

Now other services in the cluster can reach your API at http://my-api-service:80. K8s handles load balancing across all 3 Pods.

Applying YAML

# Create or update resources from a file
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# Apply all YAML files in a directory
kubectl apply -f ./k8s/

# Delete resources
kubectl delete -f deployment.yaml

5. Networking & Service Discovery

K8s networking follows simple rules:

• Every Pod gets its own IP address
• Pods can communicate with any other Pod without NAT
• Services provide stable DNS names

How Services Find Pods

Services use label selectors. When you create a Service with selector: { app: my-api }, it automatically finds all Pods with that label and routes traffic to them. If a Pod dies and a new one starts with the same label, the Service picks it up automatically.

DNS Inside the Cluster

# Service "my-api-service" in namespace "default" is accessible at:
my-api-service                          # Short name (same namespace)
my-api-service.default                  # With namespace
my-api-service.default.svc.cluster.local  # Fully qualified

Ingress -- Exposing to the Internet

An Ingress is a set of rules for routing external HTTP traffic to your Services. Think of it as a reverse proxy (like Nginx) that K8s manages for you.

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

6. Storage & ConfigMaps

ConfigMaps -- Non-Secret Configuration

Store configuration data separately from your container image. This lets you change config without rebuilding.

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"

Secrets -- Sensitive Data

# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  DB_PASSWORD: "supersecret123"
  API_KEY: "sk-abc123"

Using ConfigMaps and Secrets in Pods

spec:
  containers:
    - name: api
      image: myapp:1.0
      envFrom:                    # Load all keys as env vars
        - configMapRef:
            name: app-config
        - secretRef:
            name: db-credentials
      # OR load individual keys:
      env:
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: DB_PASSWORD

Persistent Volumes -- Durable Storage

Just like Docker volumes, Pods need persistent storage for databases. K8s uses PersistentVolumeClaims (PVC) to request storage:

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-storage
spec:
  accessModes:
    - ReadWriteOnce           # One node can write at a time
  resources:
    requests:
      storage: 10Gi           # 10 GB of storage

# Use it in a Pod
spec:
  containers:
    - name: postgres
      image: postgres:16
      volumeMounts:
        - name: db-data
          mountPath: /var/lib/postgresql/data
  volumes:
    - name: db-data
      persistentVolumeClaim:
        claimName: db-storage

7. Scaling & Self-Healing

Manual Scaling

# Scale to 5 replicas
kubectl scale deployment my-api --replicas=5

# Scale to 0 (stops all pods, saves resources)
kubectl scale deployment my-api --replicas=0

Horizontal Pod Autoscaler (HPA)

Automatically scale based on CPU or memory usage:

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # Scale up when CPU > 70%

Self-Healing

Kubernetes constantly watches your Pods. If one crashes, it immediately starts a replacement. This happens because the Controller Manager compares the desired state (3 replicas) with the actual state (2 running) and reconciles the difference.

You can also define health checks so K8s restarts unhealthy containers:

spec:
  containers:
    - name: api
      image: myapp:1.0
      livenessProbe:            # Is the container alive?
        httpGet:
          path: /health
          port: 3000
        initialDelaySeconds: 10
        periodSeconds: 15
      readinessProbe:           # Is it ready to receive traffic?
        httpGet:
          path: /ready
          port: 3000
        initialDelaySeconds: 5
        periodSeconds: 5

8. Essential kubectl Commands

# ===== VIEWING RESOURCES =====
kubectl get pods                    # List all pods
kubectl get pods -o wide            # With more detail (node, IP)
kubectl get deployments             # List deployments
kubectl get services                # List services
kubectl get all                     # List everything

# ===== DETAILED INFO =====
kubectl describe pod my-pod         # Detailed pod info + events
kubectl describe deployment my-api  # Deployment details

# ===== LOGS =====
kubectl logs my-pod                 # View pod logs
kubectl logs -f my-pod              # Follow logs (real-time)
kubectl logs my-pod -c my-container # Specific container in pod

# ===== DEBUGGING =====
kubectl exec -it my-pod -- bash     # Shell into a pod
kubectl port-forward my-pod 3000:3000  # Forward local port to pod

# ===== APPLYING & DELETING =====
kubectl apply -f deployment.yaml    # Create/update from file
kubectl delete -f deployment.yaml   # Delete from file
kubectl delete pod my-pod           # Delete a specific pod

# ===== SCALING =====
kubectl scale deployment my-api --replicas=5

# ===== ROLLOUTS =====
kubectl rollout status deployment my-api   # Watch deployment progress
kubectl rollout history deployment my-api  # See revision history
kubectl rollout undo deployment my-api     # Rollback to previous version

# ===== CONTEXT =====
kubectl config get-contexts         # See available clusters
kubectl config use-context my-cluster  # Switch clusters
kubectl get namespaces              # List namespaces
kubectl -n production get pods      # Pods in a specific namespace

9. Running K8s Locally (Minikube)

You don't need a cloud account to learn K8s. Minikube runs a single-node K8s cluster on your laptop.

# Install Minikube (on Linux with curl)
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# Start a cluster
minikube start

# Check it's running
kubectl get nodes

# Build images inside Minikube (so it can find them)
eval $(minikube docker-env)
docker build -t myapp:1.0 .

# Access a service
minikube service my-api-service

# Dashboard (web UI)
minikube dashboard

# Stop the cluster
minikube stop

# Delete the cluster
minikube delete

10. Kubernetes vs Docker Compose