Helm 4.0

Original Article ↗ Hacker News Discussion ↗

Helm’s complexity and design pain

  • Many describe Helm as “complexity hell”: public charts are over-parameterized, hard to understand, and the default starter chart is seen as hostile to beginners.
  • Structural issue: consumers can only change what authors exposed in values.yaml, so authors add huge, tangled option sets to cover every use case.
  • Text-based Go templating over YAML is heavily criticized: whitespace bugs, unreadable constructs, no easy linting of templates, and “fractal” copy‑paste patterns across charts.
  • Some say this complexity pushed them away from Kubernetes entirely.

Where Helm is considered useful

  • Widely acknowledged value as a de facto package manager for Kubernetes: easy installation of complex third‑party stacks like ingress controllers, cert-manager, Prometheus, Cilium, Traefik, etc.
  • Network effects matter: many vendors only document Helm installs; reverse‑engineering charts into raw manifests or Terraform is tedious.
  • Several report success when:
    • Charts are simple, near‑raw manifests with minimal templating.
    • Teams write “single‑purpose” internal charts, not generic mega‑charts.
    • Helm is used via GitOps tools (ArgoCD/FluxCD) and mostly as helm template.

Alternatives and patterns

  • Kustomize is frequently recommended for internal apps: plain manifests plus overlays; easier to understand and modify than Helm, especially when only one org deploys the app.
  • Some combine Helm + Kustomize or Helm + Flux/Helmfile post‑renderers, but note it becomes “layers on layers” and hard to reason about.
  • Others prefer:
    • Terraform (kubernetes and helm providers), usually just to bootstrap GitOps controllers and infra.
    • General-purpose languages (Python, Go, JS/TS) or CDK8s/Pulumi to generate manifests.
    • CUE/Jsonnet or tools like timoni, kubecfg, Tanka, pkl; these are praised for structured, typed config but tooling and adoption are mixed.

Operational pain points

  • CRDs under Helm are called “a nightmare”: upgrade/remove cycles, circular dependencies, and difficulty recovering from bad states.
  • CLI flag renames in Helm 4 (e.g., --atomic → --rollback-on-failure) are viewed as unnecessarily breaking automation.
  • Charts often obscure the underlying app’s native config; users must grep templates to map upstream docs to chart values.

Broader Kubernetes concerns

  • Several argue Kubernetes (and thus Helm) is overkill for most deployments; Docker Compose, Swarm, or Nomad are preferred at smaller scales.
  • Repeated worry about abstraction-on-abstraction: K8s objects already abstract infrastructure; adding Helm, Kustomize, and GitOps layers can make systems opaque, especially to people lacking fundamentals.