Why Kubernetes

# ===== The problem =====
# 'I have 30 services, each as a container, that need to run across 8 nodes.'
# Without orchestration:
#   - You manually start/stop containers
#   - You write scripts to restart on failure
#   - You hand-roll service discovery (where IS the user-service today?)
#   - You build deployment tooling for rolling updates
#   - You wire up healthchecks + autoscaling + logging
# That is a multi-team distraction from the product.

# ===== What Kubernetes provides =====
# 1. Declarative state
#    YAML describes WHAT you want. Controllers reconcile reality.
# 2. Scheduling
#    Pods land on suitable nodes; resource requests + limits enforced.
# 3. Self-healing
#    Crashed pod -> rescheduled. Crashed node -> pods move.
# 4. Service discovery + load balancing
#    Service abstraction gives stable DNS + virtual IPs.
# 5. Rolling updates + rollbacks
#    Built-in deployment strategy with progress + rollback.
# 6. Configuration + secrets
#    ConfigMaps and Secrets injected into pods.
# 7. Autoscaling
#    HPA (pods), VPA (vertical), Cluster Autoscaler (nodes).
# 8. Extension points
#    CRDs + operators implement custom resources (ArgoCD, Cert-Manager, ...)

# ===== Common alternatives =====
# Nomad         simpler scheduler from HashiCorp; less ecosystem
# ECS / Fargate AWS-only; less primitives but easy
# Docker Swarm  largely deprecated
# Mesos         largely deprecated
# Plain VMs     possible at small scale; pain at 30+ services
# PaaS          (Heroku, Fly, Railway, Render): hide K8s; good for small apps

# ===== When NOT to use Kubernetes =====
# - One service, one box
# - Small team without ops capacity
# - Apps that fit a PaaS happily
# Don't pick K8s because it is fashionable; pick it because you have the problem.

# ===== When Kubernetes earns its weight =====
# - 5+ services, multiple environments
# - Multi-team or multi-tenant platform
# - Need rolling deploys + autoscaling + self-healing
# - Hybrid / multi-cloud requirements

# ===== The cost =====
# - Operational complexity (control plane upgrades, networking, security)
# - YAML proliferation; Kustomize / Helm to manage
# - Long learning curve for new joiners
# - Cloud bills (control plane + nodes + storage + egress)

# ===== Managed K8s is the right choice for most teams =====
# EKS / GKE / AKS handle the control plane.
# Your team focuses on workloads + policies.

# ===== Patterns to internalise =====
# - YAML in git as the source of truth
# - GitOps (ArgoCD / Flux) to reconcile from git
# - One namespace per environment or per team
# - Probes + requests + limits on every container

# ===== Pitfalls =====
# - Adopting K8s without the problem it solves
# - Self-managing the control plane when EKS / GKE / AKS would do
# - Tight coupling to vendor-specific extensions (lock-in)
# - Treating K8s as a substitute for application architecture

# Once you have many containers + scaling + rolling deploys, K8s earns its keep.
# Below that, plain Docker / ECS / Fly / Render is usually simpler.