Link Search Menu Expand Document

Why Not Helm

Helm filled a gap that existed historically for templating kubernetes yaml manifests, that gap no longer exists and has been filled in mainline kubernetes with the introduction of kustomize. During the time that this gap existed Helm acquired wide adoption and became the defacto package manager for kubernetes which continues to drive further adoption. Due to helm's popularity it is often adopted without sufficient analysis of its suitability for particular environments and use cases.

Helm is great for

  • accelerating development by making it easy to install 3rd party services in your kubernetes clusters
  • providing 3rd parties with a convenient package manager like experience for installing your services in their kubernetes clusters.

Helm isn't great for

  • decreasing complexity in mature clusters
  • co-operating with GitOps operators and methods
  • co-operating with dynamically scaled environments (HPA scaled services)
  • (historically) operating in restricted security contexts/namespaces/etc.
  • managing complex services after initial installation

In what I'm referring to as a "mature" cluster, many choices will have been made with regard to common services and integrations (ingress, logging, metrics, service mesh, secrets managements, etc.) Helm charts are often very opinionated and do not allow for those choices to be integrated easily. Helm charts also represent a significant and opaque abstraction over what are often complex services, this frequently presents significant challenges to upgrading these services when required.