Kubernetes

Before We Begin

Kubernetes can feel overwhelming at first, but if you understand the following concepts you will have a smooth journey. Don't worry — we explain each one briefly below so you don't have to leave this page.

Quick YAML Primer

YAML stands for "YAML Ain't Markup Language". It uses indentation to show structure, like Python does for code.

# Lines starting with '#' are comments — ignored by Kubernetes.

name: my-app          # string value — no quotes needed unless it contains special chars
version: "1.0"        # quoted because it looks like a number; quotes keep it a string
replicas: 3           # integer value — no quotes

labels:               # this is a "mapping" (key-value pairs), indented 2 spaces
  env: production     # key: value  (child of 'labels')
  team: backend

ports:                # this is a "sequence" (list), items start with a dash
  - 8080              # first item in the list
  - 9090              # second item

What is a Container?

Think of a container like a shipping container on a cargo ship. It packages your application and all its dependencies together in a standardized box that runs the same way on any machine.

What is Kubernetes?

Imagine you run a pizza restaurant. You have 5 chefs making pizzas. If one chef calls in sick, you have to assign their work to the other 4. If it's Friday night and orders spike, you hire more temporary staff. If one oven breaks, you route orders to working ovens. You want all of this to happen automatically without you micromanaging every detail.

Kubernetes does exactly this — but for your containerized applications.

Why do we need it?

Modern applications are made of many small services (microservices), each running in its own container. Managing hundreds of containers manually across multiple servers is painful. Kubernetes automates:

• Scheduling: "Which server should this container run on?"
• Self-healing: "A container crashed — restart it automatically."
• Scaling: "Traffic doubled — spin up more containers."
• Load balancing: "Spread incoming requests across all healthy containers."
• Rolling updates: "Deploy new version without downtime."
• Configuration management: "Inject environment variables and secrets safely."

The Evolution: Bare Metal → VMs → Containers → Kubernetes

Key Kubernetes Terms at a Glance

Kubernetes Architecture

A Kubernetes cluster has two main parts: the Control Plane (the brain) and Worker Nodes (the muscles). Think of it as a company: the control plane is the management team and worker nodes are the employees doing the actual work.

Control Plane Components

Worker Node Components

Pods — The Smallest Unit

A Pod is the smallest and most basic deployable object in Kubernetes. Think of a Pod as a wrapper around one or more tightly-coupled containers. While most Pods contain just one container, they can contain multiple containers that need to share storage or network.

Creating Your First Pod

You can create a Pod using a YAML manifest file (recommended) or the kubectl run command.

# pod.yaml

apiVersion: v1        # Which Kubernetes API group/version this object uses.
                      # Pods belong to the core "v1" API group.
kind: Pod             # The type of Kubernetes object to create.

metadata:
  name: my-first-pod  # Unique name for this Pod within the namespace.
  labels:             # Key-value tags. Used by Services/ReplicaSets to
    app: my-app       # find and group related Pods (via label selectors).

spec:                 # "spec" describes the DESIRED STATE of the Pod.
  containers:         # A Pod can hold one or more containers.
  - name: nginx-container   # Arbitrary name — used in logs and exec commands.
    image: nginx:1.24       # Docker image to run. Format: image:tag
                            # Always pin a specific tag (not "latest") in production.
    ports:
    - containerPort: 80     # Documents which port the container listens on.
                            # This is informational only — it does NOT publish the port.
                            # A Service is needed to actually route traffic here.

# kubectl apply -f <file>
#   Reads the YAML file and sends it to the API server.
#   Kubernetes creates or updates the described object.
#   -f means "from file" (can also be a URL or a directory).
kubectl apply -f pod.yaml

# kubectl get pods
#   Lists all Pods in the current namespace.
#   Columns: NAME, READY, STATUS, RESTARTS, AGE
#   Add -n <namespace> to check a specific namespace,
#   or --all-namespaces (-A) to see Pods everywhere.
kubectl get pods

# kubectl describe pod <name>
#   Shows the full event log and spec for a Pod.
#   Very useful for debugging — look at the "Events:"
#   section at the bottom when a Pod won't start.
kubectl describe pod my-first-pod

# kubectl logs <pod-name>
#   Prints stdout/stderr from the container.
#   Add -f to stream logs in real time (like tail -f).
#   Add --previous to see logs of a crashed container.
kubectl logs my-first-pod

# kubectl exec -it <pod-name> -- <command>
#   Opens an interactive shell inside a running container.
#   -i = keep stdin open  |  -t = allocate a TTY (terminal)
#   -- separates kubectl flags from the command to run.
#   Replace /bin/bash with /bin/sh for Alpine-based images.
kubectl exec -it my-first-pod -- /bin/bash

# kubectl delete pod <name>
#   Removes the Pod. Kubernetes sends SIGTERM to the container,
#   waits for graceful shutdown (30s by default), then force-kills.
#   Note: if managed by a Deployment, a new Pod is created immediately.
kubectl delete pod my-first-pod

Pod Lifecycle Phases

ReplicaSets — Ensuring High Availability

A ReplicaSet ensures that a specified number of identical Pod replicas are running at all times. If a Pod crashes or is deleted, the ReplicaSet automatically creates a new one. Think of it as the "safety net" that maintains your desired number of running Pods.

# replicaset.yaml

apiVersion: apps/v1   # ReplicaSets are in the "apps" API group, version v1.
kind: ReplicaSet

metadata:
  name: nginx-rs

spec:
  replicas: 3         # The desired number of identical Pod copies.
                      # Controller reconciles: if 2 are running → creates 1 more.
                      #                        if 4 are running → deletes 1.

  selector:           # How the ReplicaSet identifies which Pods it "owns".
    matchLabels:
      app: nginx      # It will manage any Pod that has the label app=nginx.
                      # ⚠️ selector must match the template's labels exactly.

  template:           # Blueprint for the Pods this ReplicaSet will create.
    metadata:
      labels:
        app: nginx    # Every Pod created from this template gets app=nginx.
                      # This must match the selector above.
    spec:
      containers:
      - name: nginx
        image: nginx:1.24
        ports:
        - containerPort: 80

Deployments — The Workhorse

A Deployment is the recommended way to run stateless applications on Kubernetes. It manages a ReplicaSet for you and adds powerful features on top: rolling updates, rollbacks, and scaling. This is the object you will use most frequently in day-to-day Kubernetes work.

# deployment.yaml

apiVersion: apps/v1
kind: Deployment      # Manages a ReplicaSet, which in turn manages Pods.

metadata:
  name: my-app

spec:
  replicas: 3         # Keep 3 Pods running at all times.

  selector:
    matchLabels:
      app: my-app     # The Deployment owns Pods with this label.

  strategy:
    type: RollingUpdate   # Default strategy. Alternative: Recreate
                          # (Recreate kills all old Pods first — causes downtime).
    rollingUpdate:
      maxSurge: 1         # During an update, allow UP TO 1 extra Pod above replicas.
                          # So temporarily up to 4 Pods can run (3 + 1 surge).
      maxUnavailable: 0   # During an update, NEVER let available Pods drop below 3.
                          # Combined with maxSurge:1 this gives zero-downtime updates.

  template:           # Pod blueprint — same as ReplicaSet template.
    metadata:
      labels:
        app: my-app   # Must match spec.selector.matchLabels above.
    spec:
      containers:
      - name: app
        image: my-app:1.0   # Change this value and apply → triggers rolling update.
        ports:
        - containerPort: 3000

Essential kubectl Commands

# kubectl apply -f <file>
#   Creates or updates the Deployment described in the YAML.
#   If the Deployment already exists, Kubernetes calculates
#   the diff and applies only what changed (e.g., a new image).
kubectl apply -f deployment.yaml

# kubectl scale deployment <name> --replicas=<n>
#   Imperatively adjusts the replica count without editing YAML.
#   Kubernetes adds or removes Pods to match the new target.
#   For permanent changes, update replicas: in your YAML instead.
kubectl scale deployment my-app --replicas=5

# kubectl set image deployment/<name> <container>=<image:tag>
#   Patches the container image, which triggers a rolling update.
#   "app" is the container name defined in spec.containers[].name.
#   Kubernetes will progressively replace old Pods with new ones.
kubectl set image deployment/my-app app=my-app:2.0

# kubectl rollout status deployment/<name>
#   Blocks and shows real-time progress of a rolling update.
#   Exits 0 when all replicas are updated, or non-zero on timeout.
#   Great to use in CI/CD pipelines to verify deployments succeed.
kubectl rollout status deployment/my-app

# kubectl rollout undo deployment/<name>
#   Rolls back to the previous ReplicaSet revision.
#   Add --to-revision=<n> to go back to a specific version number.
#   Kubernetes simply sets the Deployment's image back to the old one.
kubectl rollout undo deployment/my-app

# kubectl rollout history deployment/<name>
#   Shows all saved revisions of this Deployment.
#   Each 'kubectl apply' or 'set image' creates a new revision.
#   Add --revision=<n> to see the exact spec of a past revision.
kubectl rollout history deployment/my-app

Rolling Update — Zero Downtime Deployment

Services — Stable Networking

Pods are ephemeral — they come and go, and each time a new Pod starts, it gets a new IP address. If you have 3 Pods running your web app, how does a database Pod know which IP to call? This is the problem Services solve.

A Service gives a stable virtual IP (ClusterIP) and DNS name to a group of Pods. kube-proxy load-balances traffic across all healthy Pods matching the Service's selector.

Service Types

# service.yaml — ClusterIP (internal only)

apiVersion: v1
kind: Service

metadata:
  name: my-app-svc      # Other Pods in the cluster can reach this Service
                        # by DNS: my-app-svc.<namespace>.svc.cluster.local
                        # or just "my-app-svc" within the same namespace.

spec:
  type: ClusterIP       # Default type. Only reachable from within the cluster.
                        # kube-proxy assigns a stable virtual IP (VIP) to this Service.

  selector:
    app: my-app         # Routes traffic to ALL Pods that have label app=my-app.
                        # Pods are added/removed from routing dynamically as they
                        # come and go — the Service always stays at the same VIP.

  ports:
  - port: 80            # The port clients use to call this Service.
                        # e.g., http://my-app-svc:80
    targetPort: 3000    # The port the container is actually listening on.
                        # The Service translates: client:80 → container:3000.

---
# LoadBalancer — exposes to the internet via a cloud load balancer

apiVersion: v1
kind: Service
metadata:
  name: my-app-lb
spec:
  type: LoadBalancer    # Tells the cloud provider (AWS/GCP/Azure) to provision
                        # an external load balancer and assign a public IP.
                        # The assigned IP appears in: kubectl get svc my-app-lb
                        #   → EXTERNAL-IP column.

  selector:
    app: my-app

  ports:
  - port: 80            # Internet-facing port on the cloud load balancer.
    targetPort: 3000    # Internal container port traffic is forwarded to.

Namespaces — Virtual Clusters

Imagine a large office building shared by multiple companies. Each company has its own floor with locked access — they can see each other exists but can't accidentally walk into each other's rooms. Namespaces do the same for Kubernetes resources.

Namespaces provide a way to divide cluster resources between multiple users, teams, or environments (e.g., dev, staging, production) within a single cluster.

# kubectl get namespaces
#   Lists all namespaces in the cluster (shorthand: kubectl get ns).
#   You'll see the built-in ones: default, kube-system, kube-public.
kubectl get namespaces

# kubectl create namespace <name>
#   Creates a new namespace imperatively.
#   Alternatively: kubectl apply -f namespace.yaml
#   (where the YAML has kind: Namespace)
kubectl create namespace dev

# kubectl apply -f <file> -n <namespace>
#   The -n flag targets a specific namespace for this command.
#   If omitted, the command uses whatever namespace your
#   kubeconfig context is currently set to (often "default").
kubectl apply -f deployment.yaml -n dev

# kubectl get pods -n <namespace>
#   Lists Pods only in the specified namespace.
#   You must specify -n every time, or change the default below.
kubectl get pods -n dev

# kubectl get pods --all-namespaces   (shorthand: -A)
#   Lists Pods across ALL namespaces in one view.
#   Adds a NAMESPACE column to the output so you can see
#   which namespace each Pod belongs to.
kubectl get pods --all-namespaces

# kubectl config set-context --current --namespace=<ns>
#   Changes the DEFAULT namespace for your current kubeconfig context.
#   After this, you no longer need to pass -n dev on every command.
#   Run 'kubectl config view --minify' to verify the active context.
kubectl config set-context --current --namespace=dev

ConfigMaps & Secrets

Hard-coding configuration (database URLs, API keys, feature flags) directly into container images is bad practice. It makes images non-portable and secrets insecure. Kubernetes provides two objects to solve this:

• ConfigMap — Stores non-sensitive key-value configuration data.
• Secret — Stores sensitive data (passwords, tokens, keys) encoded in base64.

# configmap.yaml

apiVersion: v1
kind: ConfigMap

metadata:
  name: app-config      # Pods reference this by name.

data:                   # All values here are plain strings — no base64 encoding.
  DATABASE_HOST: "postgres.default.svc.cluster.local"
                        # Full DNS name of a Service in the cluster.
                        # Format: <service-name>.<namespace>.svc.cluster.local
  APP_PORT: "3000"
  LOG_LEVEL: "info"

  config.properties: | # The pipe "|" means multi-line string literal.
    max-connections=100 # This entire block is stored as a single file-like value.
    timeout=30s         # Useful for mounting as a config file inside a container.

---
# secret.yaml

apiVersion: v1
kind: Secret

metadata:
  name: app-secret

type: Opaque            # "Opaque" = generic secret (arbitrary key-value data).
                        # Other types: kubernetes.io/tls, kubernetes.io/dockerconfigjson

data:                   # Values MUST be base64-encoded.
                        # Encode: echo -n "password123" | base64
                        # Decode: echo "cGFzc3dvcmQxMjM=" | base64 --decode
  DATABASE_PASSWORD: cGFzc3dvcmQxMjM=   # base64("password123")
  API_KEY: c2VjcmV0a2V5                 # base64("secretkey")
                        # ⚠️ base64 is encoding, NOT encryption.
                        # The real security comes from RBAC restricting who
                        # can read Secrets, and optionally etcd encryption-at-rest.

Injecting ConfigMaps & Secrets into Pods

spec:
  containers:
  - name: app
    image: my-app:1.0

    # ── Method 1: Single env var pulled from a ConfigMap key ──────────────
    # The container sees DB_HOST as a normal environment variable.
    # It does NOT know it came from a ConfigMap — just like export DB_HOST=...
    env:
    - name: DB_HOST             # Name of the env var inside the container.
      valueFrom:
        configMapKeyRef:
          name: app-config      # Name of the ConfigMap object.
          key: DATABASE_HOST    # Which key from that ConfigMap to use.

    # ── Method 2: Single env var pulled from a Secret key ─────────────────
    # Kubernetes automatically base64-DECODES the value before injecting it.
    # So the container receives the plain-text password, not the encoded form.
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret      # Name of the Secret object.
          key: DATABASE_PASSWORD

    # ── Method 3: Load ALL keys from a ConfigMap as env vars at once ──────
    # Every key in app-config becomes an env var automatically.
    # Useful when you have many config values and don't want to list each one.
    envFrom:
    - configMapRef:
        name: app-config

    # ── Method 4: Mount a ConfigMap as files inside the container ─────────
    # Each key in the ConfigMap becomes a separate file under /etc/config/.
    # e.g., /etc/config/LOG_LEVEL, /etc/config/config.properties
    # The app can read these files at runtime. Updates propagate automatically.
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config    # Directory inside the container where files appear.

  volumes:
  - name: config-volume         # Must match the volumeMount name above.
    configMap:
      name: app-config          # Which ConfigMap to expose as files.

Volumes & Persistent Storage

Container filesystems are ephemeral — when a Pod dies, any data written inside it is gone. If your database Pod crashes and restarts, you don't want to lose all your data! Volumes solve this by providing storage that outlives a container (and sometimes even a Pod).

Storage Concepts

# PersistentVolumeClaim — a request for storage from the cluster.

apiVersion: v1
kind: PersistentVolumeClaim

metadata:
  name: my-pvc          # The Pod will reference this PVC by this name.

spec:
  accessModes:
  - ReadWriteOnce       # This volume can be mounted read-write by ONE node at a time.
                        # For databases, RWO is the correct choice — only one node
                        # should write at a time. (RWX requires NFS or similar.)

  storageClassName: fast-ssd
                        # Tells Kubernetes WHICH storage backend to use.
                        # "fast-ssd" is an example StorageClass name defined by
                        # your cluster admin. Cloud clusters come with classes like
                        # "gp2" (AWS), "standard" (GCP), "managed-premium" (Azure).
                        # Omit storageClassName to use the cluster's default.

  resources:
    requests:
      storage: 5Gi      # How much storage you need. Kubernetes finds (or creates)
                        # a PersistentVolume that satisfies this request.

---
# Pod using the PVC

apiVersion: v1
kind: Pod
metadata:
  name: db-pod
spec:
  containers:
  - name: postgres
    image: postgres:15
    volumeMounts:
    - name: data                          # Must match the volume name below (not the PVC name).
      mountPath: /var/lib/postgresql/data # Where Postgres expects to find its data files.
                                          # Data written here persists even if the Pod is deleted.

  volumes:
  - name: data                  # Internal name used to link volumeMount ↔ volume source.
    persistentVolumeClaim:
      claimName: my-pvc         # Name of the PVC defined above.
                                # Kubernetes mounts the bound PersistentVolume here.

Access Modes

Ingress — Smart HTTP Router

A LoadBalancer Service creates one cloud load balancer per Service — this can get expensive. Ingress is a single entry point that routes incoming HTTP/S traffic to different Services based on the URL path or hostname.

Think of Ingress as a smart reverse proxy or API gateway sitting in front of all your Services.

# ingress.yaml

apiVersion: networking.k8s.io/v1   # Ingress moved to this stable API in K8s 1.19+.
kind: Ingress

metadata:
  name: my-ingress
  annotations:                     # Annotations pass extra config to the Ingress Controller.
    nginx.ingress.kubernetes.io/rewrite-target: /
    # ↑ Strips the path prefix before forwarding to the backend.
    # e.g., /api/users → / (the backend only sees /users, not /api/users).
    # Different controllers use different annotation keys.

spec:
  ingressClassName: nginx          # Selects which Ingress Controller handles this object.
                                   # Allows multiple controllers (nginx + traefik) in one cluster.

  tls:                             # Enable HTTPS. The controller terminates TLS here,
  - hosts:                         # so backends only need to handle plain HTTP internally.
    - example.com
    secretName: tls-secret         # A kubernetes.io/tls Secret containing cert.pem + key.pem.
                                   # Create with: kubectl create secret tls tls-secret
                                   #              --cert=cert.pem --key=key.pem

  rules:
  - host: example.com              # Only route requests with this Host header.
                                   # Omit host to match ALL hostnames.
    http:
      paths:
      - path: /api                 # Match requests starting with /api.
        pathType: Prefix           # Prefix = /api, /api/users, /api/v2/... all match.
                                   # Exact = only /api matches (not /api/users).
        backend:
          service:
            name: api-service      # Forward to this Service.
            port:
              number: 80

      - path: /                    # Catch-all: everything not matched above.
        pathType: Prefix           # More specific paths (/api) are matched first.
        backend:
          service:
            name: web-service
            port:
              number: 80

Health Probes — Self-Healing

How does Kubernetes know if your app is actually working? A container could be running but the app inside might be stuck or not ready to accept traffic. Health Probes let you tell Kubernetes exactly how to check your app's health.

spec:
  containers:
  - name: my-app
    image: my-app:1.0

    # ── Startup Probe ─────────────────────────────────────────────────────
    # Purpose: Give slow-starting apps time to initialize.
    # While this probe is running, liveness and readiness probes are PAUSED.
    # If it fails more than failureThreshold times → container is killed.
    # If it succeeds once → it never runs again; liveness/readiness take over.
    startupProbe:
      httpGet:                  # Probe type: send an HTTP GET request.
        path: /healthz          # The URL path your app exposes for health checks.
        port: 8080              # The port to hit (must be containerPort).
      failureThreshold: 30      # Number of consecutive failures before giving up.
      periodSeconds: 10         # How often to probe (in seconds).
                                # Total timeout = failureThreshold × periodSeconds
                                # = 30 × 10s = 5 minutes before killing the container.

    # ── Liveness Probe ───────────────────────────────────────────────────
    # Purpose: Detect deadlocks or hung processes and restart the container.
    # Your /healthz endpoint should verify the app is responsive
    # (e.g., can process requests), NOT check external dependencies.
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10   # Wait this many seconds after container start
                                # before the FIRST liveness check. Gives the app
                                # time to become ready without failing immediately.
      periodSeconds: 15         # Probe interval: check health every 15 seconds.
      failureThreshold: 3       # Restart the container after 3 consecutive failures.
                                # Total tolerated downtime before restart: 3 × 15s = 45s.

    # ── Readiness Probe ──────────────────────────────────────────────────
    # Purpose: Control when traffic is sent to this Pod.
    # A failing readiness probe does NOT restart the container —
    # it only removes the Pod from the Service's endpoint list.
    # Useful during: startup warm-up, config reload, DB migration, etc.
    readinessProbe:
      httpGet:
        path: /ready            # Separate endpoint from /healthz — can check DB
        port: 8080              # connections, cache warm-up, etc.
      initialDelaySeconds: 5
      periodSeconds: 5          # Check every 5s. When it passes again, the Pod
      failureThreshold: 2       # is automatically added back to Service endpoints.

Resource Requests & Limits

Without constraints, a single runaway container could consume all CPU and memory on a node, starving other containers. Kubernetes lets you specify resource requests and limits per container.

spec:
  containers:
  - name: app
    image: my-app:1.0
    resources:
      requests:           # MINIMUM resources guaranteed to this container.
                          # The Scheduler uses these to decide which node to place the Pod on.
                          # A node is considered "full" when sum(requests) ≥ node capacity.
        memory: "256Mi"   # 256 Mebibytes (1 Mi = 1,048,576 bytes).
                          # Other valid units: Ki, Mi, Gi, Ti  (binary)
                          #                   K, M, G, T       (decimal SI)
        cpu: "250m"       # 250 millicores = 0.25 of one CPU core.
                          # "1" = 1 full CPU core. "500m" = 0.5 CPU.
                          # CPU is a compressible resource — the container can
                          # burst above its request if the node has spare capacity.

      limits:             # MAXIMUM resources this container can use.
                          # Enforced at runtime by the Linux kernel (cgroups).
        memory: "512Mi"   # If the container tries to use more than 512Mi of RAM,
                          # the kernel's OOM killer terminates it immediately.
                          # You'll see: OOMKilled in 'kubectl describe pod'.
        cpu: "500m"       # If the container tries to use more than 0.5 CPU,
                          # the kernel throttles it (slows it down).
                          # Unlike memory, the container is NOT killed for CPU overuse.

StatefulSets — For Stateful Applications

Deployments are great for stateless apps (like web servers), where all Pods are identical and interchangeable. But what about databases like PostgreSQL or Redis clusters? Each instance needs a stable identity, stable network hostname, and stable storage. Enter StatefulSets.

apiVersion: apps/v1
kind: StatefulSet

metadata:
  name: postgres

spec:
  serviceName: postgres   # Name of a "headless" Service (clusterIP: None) that gives
                          # each Pod a stable DNS entry:
                          # postgres-0.postgres.default.svc.cluster.local
                          # postgres-1.postgres.default.svc.cluster.local
                          # This lets Pods address each other by name (needed for clustering).

  replicas: 3             # Pods are created in order: postgres-0, then postgres-1, then postgres-2.
                          # Each waits to be Running+Ready before the next starts.

  selector:
    matchLabels:
      app: postgres

  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data

  volumeClaimTemplates:   # KEY DIFFERENCE from Deployments:
                          # Each Pod gets its OWN PVC automatically.
                          # postgres-0 → PVC "data-postgres-0"  (10Gi)
                          # postgres-1 → PVC "data-postgres-1"  (10Gi)
                          # postgres-2 → PVC "data-postgres-2"  (10Gi)
                          # These PVCs persist even if the StatefulSet is deleted,
                          # protecting your data from accidental loss.
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

DaemonSets — One Pod Per Node

A DaemonSet ensures that exactly one copy of a Pod runs on every node (or a selected subset of nodes). Whenever a new node joins the cluster, the DaemonSet automatically places a Pod on it. When a node is removed, the Pod is garbage-collected.

apiVersion: apps/v1
kind: DaemonSet         # Automatically places ONE Pod per node (or per selected nodes).

metadata:
  name: log-collector

spec:
  selector:
    matchLabels:
      app: log-collector

  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
      - name: fluentd
        image: fluentd:v1.16
        volumeMounts:
        - name: varlog
          mountPath: /var/log   # Inside the container — fluentd reads logs from here.

      volumes:
      - name: varlog
        hostPath:               # hostPath mounts a directory FROM the node's filesystem
          path: /var/log        # INTO the container. This gives the log-collector access
                                # to all logs written by processes on that node.
                                # ⚠️ Use hostPath carefully — it breaks Pod portability and
                                # can expose sensitive node data. Only use it for infra Pods
                                # like log collectors and monitoring agents.

Jobs & CronJobs — Batch Workloads

Deployments run continuously (web servers, APIs). But sometimes you need to run a task to completion — like a database migration, a report generator, or a one-time data import. That's what Jobs are for.

A CronJob runs a Job on a scheduled interval — just like a Unix cron task, but for Kubernetes.

# job.yaml — run a database migration exactly once

apiVersion: batch/v1
kind: Job               # Manages Pods that run to completion (not indefinitely).

metadata:
  name: db-migration

spec:
  completions: 1        # How many Pods must complete successfully for the Job to be "done".
                        # Set completions: 5 to process 5 independent work items.

  parallelism: 1        # How many Pods can run simultaneously.
                        # completions:5, parallelism:2 → runs 2 at a time, 3 rounds total.

  backoffLimit: 3       # Maximum number of retries before the Job is marked as Failed.
                        # Each failed Pod = 1 retry. After 3 failures, Kubernetes gives up.

  template:
    spec:
      restartPolicy: OnFailure  # OnFailure = restart the container on the SAME Pod.
                                # Never = create a new Pod for each retry (cleaner logs).
                                # ⚠️ 'Always' is NOT allowed — it would loop forever.
      containers:
      - name: migration
        image: my-app:1.0
        command: ["python", "manage.py", "migrate"]
        # command overrides the container image's default ENTRYPOINT + CMD.
        # Each element in the list is a separate argument (no shell string splitting).

---
# cronjob.yaml — generate a report every day at midnight

apiVersion: batch/v1
kind: CronJob           # Creates a new Job object on a time-based schedule.

metadata:
  name: daily-report

spec:
  schedule: "0 0 * * *" # Standard cron syntax (5 fields):
                        # ┌─ minute (0-59)
                        # │ ┌─ hour (0-23)
                        # │ │ ┌─ day of month (1-31)
                        # │ │ │ ┌─ month (1-12)
                        # │ │ │ │ ┌─ day of week (0-7, 0=Sunday)
                        # 0 0 * * *  → at 00:00 (midnight) every day
                        # */5 * * * * → every 5 minutes
                        # 0 9 * * 1  → every Monday at 09:00

  jobTemplate:          # The Job spec to create on each schedule trigger.
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: report-gen
            image: report-generator:1.0
            command: ["python", "generate_report.py"]

RBAC — Access Control

Role-Based Access Control (RBAC) controls who can do what in your Kubernetes cluster. Without RBAC, any user or service could read secrets, delete Pods, or modify any resource — a serious security risk.

RBAC has four key objects:

• Role — Grants permissions within a specific namespace
• ClusterRole — Grants permissions cluster-wide (or defines reusable roles)
• RoleBinding — Attaches a Role to a User/ServiceAccount in a namespace
• ClusterRoleBinding — Attaches a ClusterRole cluster-wide

# Role: read-only access to Pods in the 'dev' namespace.
# Think of a Role as a JOB DESCRIPTION (what actions are allowed).

apiVersion: rbac.authorization.k8s.io/v1
kind: Role              # Namespace-scoped. For cluster-wide: use ClusterRole.

metadata:
  namespace: dev        # This Role only grants permissions WITHIN the 'dev' namespace.
  name: pod-reader      # Arbitrary name used by RoleBindings to reference this Role.

rules:                  # A list of permission rules. Subject gets ALL of these.
- apiGroups: [""]       # "" = the core API group (Pods, Services, ConfigMaps, Secrets).
                        # For apps/v1 resources: apiGroups: ["apps"]
                        # For batch/v1: apiGroups: ["batch"]
  resources: ["pods", "pods/log"]
                        # Which resource types are covered.
                        # "pods/log" is a sub-resource (kubectl logs).
                        # "pods/exec" would allow kubectl exec.
  verbs: ["get", "list", "watch"]
                        # What actions are allowed on those resources.
                        # get    = read one object      (kubectl get pod my-pod)
                        # list   = list all objects     (kubectl get pods)
                        # watch  = stream changes       (kubectl get pods -w)
                        # create = create new objects
                        # update = modify existing      (kubectl apply)
                        # patch  = partial update
                        # delete = remove objects

---
# RoleBinding: grants the pod-reader Role TO Alice, in the 'dev' namespace.
# Think of a RoleBinding as an EMPLOYMENT CONTRACT (who gets which job description).

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding

metadata:
  namespace: dev
  name: alice-pod-reader

subjects:               # WHO gets the permissions (can list multiple subjects).
- kind: User            # User = human identity authenticated by the cluster.
                        # Other kinds: Group (team of users), ServiceAccount (for Pods/apps).
  name: alice           # Must match the username in the user's TLS certificate or OIDC token.
  apiGroup: rbac.authorization.k8s.io

roleRef:                # WHAT Role/ClusterRole to grant. Immutable after creation.
  kind: Role            # Use ClusterRole here if referencing a ClusterRole.
  name: pod-reader      # Name of the Role defined above.
  apiGroup: rbac.authorization.k8s.io

Helm — The Package Manager for Kubernetes

Deploying a real application might require 10-15 YAML files for Deployments, Services, ConfigMaps, Ingress, Secrets, RBAC, etc. Managing all of these individually is tedious. Helm is the package manager for Kubernetes that bundles all related YAML files into a Chart and lets you install, upgrade, and uninstall applications with a single command.

# brew install helm
#   Installs the Helm CLI on macOS via Homebrew.
#   Linux: curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
brew install helm

# helm repo add <alias> <url>
#   Registers a Chart repository under a local alias.
#   Bitnami is a popular repo with production-ready charts
#   for PostgreSQL, Redis, Kafka, WordPress, etc.
helm repo add bitnami https://charts.bitnami.com/bitnami

# helm repo update
#   Fetches the latest chart index from all registered repos.
#   Run this before searching or installing to get fresh versions.
helm repo update

# helm search repo <chart-name>
#   Searches locally cached repo indexes.
#   Shows available versions, app version, and description.
#   Add --versions to list all available chart versions.
helm search repo bitnami/postgresql

# helm install <release-name> <chart> [flags]
#   Installs the chart and names this instance "my-postgres".
#   --set key=value overrides default values from values.yaml.
#   --namespace deploys into a specific namespace (must exist).
#   Helm records the full rendered YAML as a "release" in a Secret.
helm install my-postgres bitnami/postgresql \
  --set auth.postgresPassword=secret \
  --namespace production

# helm upgrade <release-name> <chart> [flags]
#   Updates an existing release with new values or a new chart version.
#   Helm performs a diff and applies only the changed Kubernetes objects.
#   Add --install to create the release if it doesn't exist yet.
helm upgrade my-postgres bitnami/postgresql \
  --set image.tag=15.3.0

# helm list -A
#   Lists all Helm releases across all namespaces.
#   Shows release name, namespace, revision, status, and chart version.
#   -A = --all-namespaces (same as kubectl's -A flag)
helm list -A

# helm rollback <release-name> <revision>
#   Rolls the release back to a specific revision number.
#   Each install/upgrade increments the revision counter.
#   Use 'helm history my-postgres' to see all past revisions.
helm rollback my-postgres 1

# helm uninstall <release-name>
#   Deletes all Kubernetes objects that were created by this release.
#   Also removes Helm's internal release history from the cluster.
helm uninstall my-postgres