The hater's guide to Kubernetes

Original Article ↗ Hacker News Discussion ↗

Kubernetes polarizes engineers as a powerful standard for deploying and scaling containers that also introduces substantial complexity, especially for teams that don’t truly need its full feature set. Commenters weigh its benefits—cloud-agnostic APIs, rich tooling, autoscaling, and “one interface” across environments—against operational fragility, steep learning curves, YAML/Helm templating pain, and the cultural tendency to over-engineer. Many argue that simpler options (VMs, ECS, Docker Compose, Nomad, k3s, Dokku) are often sufficient, and that the real challenge is choosing infrastructure proportional to a company’s scale, skills, and business needs rather than following hype.

Overall stance on Kubernetes

  • Many see Kubernetes as powerful but excessively complex; others argue its complexity matches real-world problems at scale.
  • Common view: only a small minority “need” k8s for survival, but a much larger group finds it operationally beneficial.
  • Several compare it to git or systemd: solid core design, painful UX.

Operational complexity & fragility

  • Self-managed clusters are described as fragile: etcd upgrades, undersized control planes, and opaque failures.
  • Managed k8s (GKE/EKS/AKS) is often recommended to avoid control-plane pain, though some still report frequent “strange issues.”
  • Debugging failed Helm deploys, crash loops, and operator/CRD behavior is a recurring complaint.

Tooling: YAML, Helm, operators, alternatives

  • Strong dislike for YAML and especially Helm’s Go-templated YAML; people report subtle spacing/templating bugs.
  • Alternatives mentioned: kustomize, envsubst, Jsonnet, Pulumi, Terraform, CDK, cdk8s; some prefer “just code” over templated YAML.
  • Operators and CRDs are seen as both k8s’ key strength (programmable infra, Ceph/Rook, GitHub operators) and a major source of complexity and cluster-wide coupling.

Autoscaling, deployments, and latency

  • HPAs, VPAs, and KEDA are praised when widely adopted; live-tuning HPAs considered better than 4am manual scaling.
  • Zero-downtime deploys are a major motivator; many note you can also achieve this with simpler blue/green setups and reverse proxies.
  • K8s cold-starts for ephemeral, latency-sensitive workloads are hard to push below ~0.5–2s without deep internals work; some switch to Nomad or custom schedulers.

Cloud, lock‑in, and portability

  • Pro-k8s voices stress: declarative model, built-in load balancing/restarts, observability tools, and especially cloud-agnostic APIs across local, on-prem (k3s), and cloud.
  • Critics counter that real setups still depend heavily on each cloud’s specifics and that “cloud migration” is overemphasized relative to how often it happens.

When not to use Kubernetes & alternatives

  • For simple or small-scale systems, many prefer: ASGs, ECS/Fargate, Cloud Run, Docker Compose, Swarm, Nomad, Dokku, Kamal, plain VMs with scripts.
  • Homelab users often find k3s or just Docker Compose sufficient.

Cultural and organizational dynamics

  • K8s can become a “cleverness trap” and status symbol, spawning platform hero cultures and endless tool layering.
  • Several argue that the real problem is hype-driven adoption and misuse, not the technology itself.