DevOps
Kubernetes
Orchestrates containers across a cluster — scheduling, self-healing, service discovery, autoscaling and rolling updates — from declarative YAML it continuously reconciles to the desired state. It is the standard for running microservices at scale. The trade-off is heavy operational complexity; it is overkill for a small app a single VM or PaaS would serve.
Purpose
Kubernetes orchestrates containers across a cluster of machines: you declare the desired state in YAML — what runs, how many replicas, how it is exposed — and controllers continuously reconcile reality to match, rescheduling failed pods and rolling out updates. It turns a fleet of servers into one programmable platform.
When to Use It
Running many services at scale with self-healing, autoscaling, service discovery and zero-downtime rollouts as platform features rather than per-team code. It is the industry standard for microservice fleets and the portable layer across clouds.
For one small app, it is overkill — a PaaS, a single VM with Compose, or serverless carries far less operational weight.
Trade-offs
Its power costs steep complexity: networking, RBAC, storage, upgrades and a YAML universe of its own. Managed offerings (EKS, GKE, AKS) remove the control plane burden but not the conceptual one. Adopt it when the workload justifies a platform, not for résumé reasons.
Implementation
Core objects: Pods (running containers) managed by Deployments (replicas + rolling updates), exposed by Services (stable virtual IPs) and Ingress (HTTP routing); config and secrets injected via ConfigMaps/Secrets. Set resource requests/limits and liveness/readiness probes — the scheduler and rollouts are only as good as what you declare.