What would a Kubernetes 2.0 look like

Original Article ↗ Hacker News Discussion ↗

Role and Complexity of Kubernetes Today

  • Many see Kubernetes as powerful but over-complex for most users: “common tongue” of infra with a combinatorial explosion of plugins, operators and CRDs.
  • Others argue it’s already much simpler than the Puppet/Terraform/script piles it replaced and is “low maintenance” when managed (EKS/AKS/GKE, k3s, Talos).
  • Several comments stress that the underlying problem—large distributed systems—is inherently complex; k8s just makes that complexity explicit.
  • A recurring complaint: it’s misapplied to small/simple workloads where a VM, Docker Compose, or a lightweight PaaS would suffice.

What People Want from a “Kubernetes 2.0”

  • Dramatically simpler core:
    • “Boring pod scheduler” + RBAC; push service discovery, storage, mesh, etc. to separate layers.
    • Fewer knobs, less chance to “foot-gun” yourself; more opinionated and less pluggable by default.
  • Batteries included:
    • Sane, blessed defaults for networking, load balancing, storage, metrics, logging, UI, and auth instead of assembling CNCF Lego.
    • Immutable OS-style distribution with auto-updates and built-in monitoring/logging, user management, and rootless/less-privileged operation.
  • Better UX:
    • Higher-level workflows for “deploy an app, expose it, scale it,” Heroku-like flows, or Docker-Compose-level simplicity.
    • Clearer, more stable APIs and slower-breaking changes; people are tired of constant version churn.

Configuration: YAML, HCL, and Alternatives

  • Strong dislike of Helm’s text templating and YAML’s footguns; long manifests are hard to maintain.
  • Disagreement on HCL:
    • Pro: typed, schema’d, good editor support, already works well via Terraform.
    • Con: confusing DSL, awkward loops/conditionals, module pain; many would rather use CUE, Dhall, Jsonnet, Starlark, or just generate JSON/YAML from a real language.
  • Several note k8s already exposes OpenAPI schemas and protobufs; config could remain data (JSON/YAML/whatever) with richer generators on top.

State, Storage, etcd, and Networking

  • Persistent storage called out as a major weak spot: CSI + cloud volumes behave inconsistently; on-prem Ceph/Longhorn/others are hard to run “production-grade.”
  • et cetera:
    • Some want etcd swap-out (Postgres, pluggable backends); others defend etcd’s design and safety.
    • Large-cluster etcd scaling issues and fsync costs discussed in detail; some vendors already run non-etcd backends.
  • Networking:
    • Desire for native IPv6-first, simpler CNIs, and multi-NIC/multi-network friendliness.
    • Frustration that cluster setup starts with “many options” instead of one good default stack.

Security, Multi‑Tenancy, and Service Mesh

  • Calls for first-class, identity-based, L7-aware policies and better, built-in pod mTLS to make meshes optional.
  • Some argue k8s is “deeply not multi-tenant” in practice; others say current RBAC/NetworkPolicies + CNIs (e.g., Cilium) are already close.

Higher-Level Abstractions and AI

  • Long history of k8s abstractions/DSLs (internal platforms, Heroku-likes); most either only fit narrow cases or grow to k8s-level complexity.
  • New idea: keep k8s as-is but put an AI layer in front to author & manage manifests, turning config debates into implementation details.
  • Counterpoint: even with AI, you still want a concise, strict, canonical underlying format.

Alternatives and Experiments

  • Mentions of k3s, OpenShift, Nomad, wasm runtimes, globally distributed or GPU-focused schedulers, and custom “Kubernetes 2.0”-style platforms (e.g., simpler PaaS, serverless/actors, ML-focused orchestrators).
  • Meta-view: any new system will likely repeat the cycle—start simple, gain features, become complex, and prompt calls for “X 2.0” again.