☸️ Kubernetes - Orchestration at Scale

Kubernetes is a declarative system. You don’t tell K8s how to do something; you define the desired state in a YAML file, and the “Control Plane” works tirelessly to match reality to that definition.

🧱 1. The Core Objects

To master K8s, you must understand the hierarchy of its abstractions.

The Pod

The smallest deployable unit. It’s a wrapper around one or more containers.

Programmer Insight: Pods are ephemeral (they die and are replaced). Never store data inside a Pod’s local storage; use Persistent Volumes.

The Deployment

This manages the life cycle of Pods. It handles rolling updates and rollbacks.

ReplicaSet: Inside the Deployment, this ensures the correct number of Pods are running at any given time. If a node fails, the Deployment notices and starts the Pods on a healthy node.

The Service (Networking)

Since Pods die and get new IP addresses, you need a stable “entry point.”

ClusterIP: Internal communication between services.
NodePort: Exposes the service on a specific port on every Node (rarely used in production).
LoadBalancer: Integrates with your cloud provider (AWS/GCP/Azure) to create a real external load balancer.

🛣️ 2. Ingress: The Smart Gateway

While a Service handles L4 (TCP) traffic, Ingress handles L7 (HTTP/HTTPS) traffic.

Ingress Controller: (e.g., Nginx, Traefik, or Istio) The actual server that processes the rules.
Rules: It acts as a reverse proxy, routing api.myapp.com to the backend-service and myapp.com to the frontend-service.
TLS/SSL: This is where you usually terminate SSL certificates (often automated via Cert-Manager).

📈 3. Autoscaling: Handling the Peaks

A Programmer ensures the cluster breathes with the traffic.

HPA (Horizontal Pod Autoscaler): Scales the number of Pods based on CPU or Memory usage.
VPA (Vertical Pod Autoscaler): Adjusts the Resource Limits (CPU/RAM) of existing Pods.
Cluster Autoscaler: If the HPA wants more Pods but the nodes are full, this triggers the cloud provider to spin up an entirely new Virtual Machine (Node).

🛠️ Implementation Patterns

1. Resource Requests & Limits

This is the most common cause of cluster instability.

Requests: What the Pod is guaranteed to get. K8s uses this to decide which node to place the Pod on.
Limits: The maximum the Pod can consume. If a Pod hits its RAM limit, it is OOMKilled (Out Of Memory).
Programmer’s Move: Always set these. Without them, one “noisy neighbor” Pod can consume all resources and crash the entire node.

2. Probes: Health Checks

K8s needs to know if your app is actually working.

Liveness Probe: “Is the app alive?” If this fails, K8s restarts the Pod.
Readiness Probe: “Is the app ready to handle traffic?” If this fails, K8s stops sending traffic to this Pod (useful during slow startups).

3. ConfigMaps & Secrets

Never bake configuration or passwords into your Docker image.

ConfigMaps: For non-sensitive data (API URLs, environment names).
Secrets: For sensitive data (DB passwords, API keys). These are base64 encoded (not encrypted by default—use SealedSecrets or HashiCorp Vault for true security).

⚖️ The Deployment Workflow

When you update an image, K8s performs a Rolling Update:

Starts a new Pod with the new image.
Waits for the Readiness Probe to pass.
Terminates an old Pod.
Repeats until all Pods are updated.

Zero Downtime: If the new version crashes on startup, K8s stops the rollout, leaving the old, healthy Pods running.

💡 Note: Don’t manage YAML files manually for large projects. Use Helm (the package manager for K8s) to create templates, or ArgoCD for a GitOps approach where your cluster automatically syncs whenever you push to a specific Git branch.