What job interviews taught me about Kubernetes

Original Article ↗ Hacker News Discussion ↗

Kubernetes is increasingly treated as the default deployment platform, even for small startups, because it offers uniform workflows, strong ecosystem support, and a large pool of engineers familiar with its concepts. Commenters argue over whether those benefits justify the operational complexity, rapid upgrade cadence, and cloud integration headaches, especially when simpler options like VMs, ECS, Nomad, or PaaS platforms might suffice. Several note that managed Kubernetes offerings and LLMs have lowered the barrier to entry, but warn that troubleshooting, stateful services, and long-term maintenance still demand real expertise.

Kubernetes as the new default

  • Many commenters say Kubernetes has effectively “won” over VM+systemd and most other orchestrators, largely due to:
    • Managed offerings on major clouds becoming mature and turnkey.
    • A huge ecosystem of tools, companies, and talent built around it.
    • It acting as a “lingua franca” for infrastructure and GitOps.

Fit for small teams and startups

  • Strong disagreement about when Kubernetes makes sense:
    • Some see it as reasonable even for very small teams if they’re already “cloud native,” citing uniform deployments, easier onboarding, and shared knowledge.
    • Others view adopting k8s at 2–3 engineers as a red flag: unnecessary complexity vs just using VMs or simpler container platforms.
    • Several argue the article’s non-technical benefits (operational/organizational) don’t outweigh complexity at very small N.

Complexity, upgrades, and ecosystem churn

  • Many note k8s is not “batteries included”: ingress, cert management, DNS, storage, and GitOps add multiple controllers with their own upgrade cycles and breaking changes.
  • Upgrade cadence is seen as:
    • A feature (regular security and drift control with “push-button” cluster upgrades).
    • Or a burden (constant API churn, ingress/gateway changes, keeping addons in sync).
  • Some emphasize the networking and DNS layers (e.g., CoreDNS scaling, overlays) as overkill for many startups.

Alternatives and “simpler” stacks

  • Frequent mentions of:
    • Traditional “linux + web server + database + language runtime” on VMs, often managed with Ansible, shell scripts, or NixOS.
    • Lighter orchestrators and PaaS-like tools (Nomad, Docker Swarm, ECS/Fargate, Cloud Run, Heroku-like systems, custom “kube-lite” projects).
  • A recurring pattern: teams try k8s, then some retreat to simpler, more “boring” setups for reduced operational load.

LLMs and ease of use

  • Some claim LLMs make k8s and Terraform dramatically easier: generating manifests, Helm charts, dashboards, and debugging clusters.
  • Others strongly warn against using LLMs to work on systems you don’t understand, because errors are subtle and high-impact.

Stateful workloads and managed services

  • Several argue durable state (databases, blob stores, caches) is usually better kept outside Kubernetes via managed cloud services:
    • Managed offerings are considered more reliable and easier to migrate than in-cluster stateful operators.
  • Others report success with modern k8s-native database operators but admit they add significant complexity.

Hiring, hype, and culture

  • Kubernetes is seen as:
    • Attractive for hiring and resume-building; some call this “resume++” or hype-driven.
    • Also a safe, standard choice for CTOs who want to avoid bespoke infra and rely on widely understood patterns.
  • Some criticize adopting k8s as masking cultural/process problems with tooling rather than fixing fundamentals.