Skip to main content
To understand the current state of package management for Kubernetes, we first need to agree on what a “package” means in this context. When you inspect a complex Kubernetes application—take the Argo CD dashboard below as an example—you’ll find many components and Kubernetes objects deployed and orchestrated together. Each of those objects is part of a broader package that includes manifests, CRDs, configuration, and dependencies.
The image shows a user interface of a software application, displaying a dashboard with several tiles representing different applications, each with options to sync, refresh, or delete. It includes filters for sync and health status on the left side.
What a Kubernetes package typically contains
The image shows a diagram featuring categories such as Manifests, CRDs, Configuration Values, and Dependencies, each represented by icons, with YAML file bundles below. There's also a cartoon character on the left.
Typical package lifecycle Package management workflows generally include four core phases. Each phase benefits from automation, validation, and observability to reduce risk and operational overhead.
The image illustrates "A Typical Package Lifecycle" with four steps: Test, Configure, Install, and Update, each represented within colored boxes.
Two common, historical approaches Without a unified package manager, operators have typically relied on:
  • Raw Kubernetes manifests — full control, but hard to scale for complex apps and upgrades.
  • Helm — a widely-used package manager that offers templating and dependency support, but it doesn’t address every operational requirement (for example, strict namespace isolation for dependencies).
Package manager wishlist An ideal Kubernetes package manager would solve the major pain points operators face today:
  1. Full package definition capabilities, including CRDs, manifests, lifecycle hooks, and metadata.
  2. Clear and declarative dependency management, with namespace and installation separation.
  3. Simple, safe install and upgrade workflows, including rollbacks and health-aware upgrades.
  4. Real-time state and health monitoring for installed packages.
  5. Flexible templating plus secure secret injection and management.
  6. Native GitOps support for declarative workflows, auditability, and observability.
The image displays a "Package Management Wish List" with nine items including package definition, customization, and GitOps, among others. Each item is numbered and presented in a blue-green gradient box.
An example: umbrella charts and namespace isolation A common practical shortcoming involves how Helm handles dependencies. Consider an umbrella Helm chart that depends on another chart. Here’s an umbrella chart example for an NVIDIA GPU Operator that depends on the Node Feature Discovery chart:
When you install this umbrella chart, Helm typically renders and installs both the parent chart and its dependency into the same target namespace. That causes components representing different logical packages to live together in one namespace, which breaks common best practices for isolation and lifecycle management.
Umbrella charts make dependency installation easy, but they do not provide built-in, declarative control over installing dependencies into separate namespaces. That often forces operators to adopt additional conventions or tooling to achieve proper isolation.
Current package management pain points Comparing today’s tooling with the wishlist shows several recurring issues operators face:
  • Dependency management: handling complex graphs, version constraints, and cross-package interactions is inconsistent across tools.
  • Configuration complexity: large, nested values.yaml files make customization and overrides error-prone.
  • Secret injection: secure secrets handling often depends on external tools (for example, SealedSecrets or External Secrets) and extra integration work.
  • Umbrella chart limitations: namespace collisions and ambiguous installation scope can complicate multi-tenant deployments.
  • CRD updates: safely upgrading CRDs is difficult; Helm’s CRD handling is limited and can cause upgrade friction.
  • Lacking GitOps standardization: no single standard exists for how packages should be packaged and operated in GitOps workflows like Argo CD.
The image lists common package management bottlenecks, including dependency management, configuration complexity, secret injection, umbrella charts, CRD updates, and lacking GitOps support.
Links and references Keywords: Kubernetes package management, Helm umbrella charts, CRDs, GitOps, namespace isolation, secrets injection, package lifecycle, Argo CD.

Watch Video