Kubernetes is a desired-state system. You declare what you want (e.g., 3 replicas of a service), and controllers continuously reconcile reality to match.
Practical implications:
In the cloud, Kubernetes is usually paired with managed building blocks: load balancers, managed databases, object storage, IAM, and managed Kubernetes (EKS/AKS/GKE). The hard part isn’t YAML—it’s understanding networking, identity, and failure modes.
You declare intent (desired state) and Kubernetes reconciles toward it. Imperative commands exist, but the operating model is declarative reconciliation.
These map to how traffic and lifecycle work in practice: Deployments create Pods; Services target Pods; Ingress routes external HTTP(S) to Services.
Your service must handle rolling updates with minimal downtime. Which Kubernetes approach most directly supports this, and why?
A Deployment coordinates rollout/rollback and can keep old and new replicas running simultaneously; readiness probes prevent sending traffic to Pods that aren’t ready yet. A single Pod restart is tempting for simplicity but creates downtime. A Service alone doesn’t manage lifecycle or rollout. Ingress handles routing, not versioned replica management by itself—people often conflate “traffic entry” with “release orchestration.”