Is the Helm Killer Finally Here?

The recent joint announcement of the open-source Kubernetes Resource Orchestrator (kro, pronounced “crow”) by AWS, Google Cloud, and Azure could represent the most significant shift in Kubernetes application and package management since Helm’s debut in 2016. While Helm became the go-to package manager for the first wave of Kubernetes adopters, kro’s cloud-native-first design addresses some of the systemic pain points that we’ve experienced as Kubernetes matured into an enterprise platform. (kro repo here)

The Elephant in the Cluster: Helm's Growing Pains

Helm enabled widespread adoption of Kubernetes by giving us:

Standardized application packaging (charts)
Basic dependency management (subcharts)
Configuration abstraction (values.yaml)

But as Kubernetes deployments scaled, Helm’s architecture has revealed fundamental constraints in its ability to properly manage dependencies, handle CRD upgrades elegantly, and properly manage lifecycles. No matter how much effort Platform and DevOps teams spent creating clean Helm charts for their end users to self-service k8s, they often ended up spending their days wrangling cluster after cluster regardless.

Will kro be our answer?

kro’s Innovations: Generated, Safe CRDs

The primary building block in kro is the ResourceGraphDefinition (RG). This represents a set of related k8s resources that can be deployed as a single instance. These objects are defined as structured YAML that can be validated at compile-time rather than runtime. The kro docs best explain everything that goes into a ResourceGraphDefinition:

A ResourceGraphDefinition is a custom resource that lets you create new Kubernetes APIs for deploying multiple resources together. It acts as a blueprint, defining:
What users can configure (schema)
What resources to create (resources)
How resources reference each other (dependencies)
When resources should be included (conditions)
What status to expose (status)
When you create a ResourceGraphDefinition, kro generates a new API (a.k.a Custom Resource Definition) in your cluster that others can use to deploy resources in a consistent, controlled way.

Of particular interest in contrast to Helm is the way the schema has been designed in kro. kro’s schema has simple types and claims to be a more “human-friendly and readable syntax” (it looks better than Helm but not perfect).

The API generated from this ResourceGraphDefinition is then provided to end users in the cluster to enable them to safely create instances of this resource with the configurations they are explicitly permitted to make by the schema. Everything else is handled by the CRD generated from the RG, including the correct ordering of dependencies.

To handle dependencies, a Direct Acyclic Graph (DAG) is created based on the way resources are linked in the ResourceGraphDefinition. The generated CRD will then implement this DAG not just in the instantiation of the resource, but also throughout its lifecycle.

Once invoked, here’s how kro leverages the native k8s API to apply the CRD:

kro is designed to use core Kubernetes primitives to make resource grouping, customization, and dependency management simpler. When a ResourceGraphDefinition is applied to the cluster, the kro controller verifies its specification, then dynamically creates a new CRD and registers it with the API server. kro then deploys a dedicated controller to respond to instance events on the CRD. This microcontroller is responsible for managing the lifecycle of resources defined in the ResourceGraphDefinition for each instance that is created.

Built for Platform x Security x Compliance Collaboration

kro allows Platform, Security, and Compliance teams to all work in the same place to provide developers with a secure and compliant way to consume infra. Less sprawl across multiple tools makes it easier for these teams to move quickly and work together without having to test compatibility across sprawling combinations of versions. For end-users, the simplicity of a single tool reduces mistakes and improves the user experience.

What Stands in the Way of kro’s Success?

It’s promising to see the weight of the Big 3 cloud providers behind kro, and is certainly a strong signal that this project has the potential. But no project is guaranteed success. kro isn’t yet production-ready, so its performance at scale remains to be seen. And, the additional complexity of ResourceGraphDefinitions may leave Helm better suited for simple applications or open-source packages. More complexity can be powerful, but it isn’t necessarily elegant (see Kubernetes).

Development is ongoing, so there are still many areas of the tool that aren’t fully scoped out. There’s not yet a Helm-like CLI where packages can be created, uploaded, and installed. There are also some ongoing architecture discussion around the limitations of compile-time validation for things like for-loops and how to handle security. There’s a community slack channel here if you want to join the conversation.

Despite my attention-seeking title, kro likely doesn’t spell the death of Helm, at least not soon. Helm’s simplicity and broad reach give it tremendous staying power. Even though we all have our frustrations with it, teams know what to expect with it. If I had to guess, we will see Helm remain in place for open-source projects and for small teams with adoption of Kro from enterprise platform teams.

A New Era of Kubernetes Management

As Kubernetes matures from container orchestrator to application platform, kro may provide the missing abstraction layer between infrastructure and business logic that Helm couldn’t quite provide. kro will allow platform teams to take full advantage of the power of CRDs without investing in custom controllers or wrangling Helm hell. While Helm charts won’t disappear overnight, their role may diminish as kro’s Kubernetes-native approach becomes the foundation for enterprise-grade Kubernetes.

Additional Reading and Resources

The recent joint announcement of the open-source Kubernetes Resource Orchestrator (kro, pronounced “crow”) by AWS, Google Cloud, and Azure could represent the most significant shift in Kubernetes application and package management since Helm’s debut in 2016. While Helm became the go-to package manager for the first wave of Kubernetes adopters, kro’s cloud-native-first design addresses some of the systemic pain points that we’ve experienced as Kubernetes matured into an enterprise platform. (kro repo here)

The Elephant in the Cluster: Helm's Growing Pains

Helm enabled widespread adoption of Kubernetes by giving us:

Standardized application packaging (charts)
Basic dependency management (subcharts)
Configuration abstraction (values.yaml)

But as Kubernetes deployments scaled, Helm’s architecture has revealed fundamental constraints in its ability to properly manage dependencies, handle CRD upgrades elegantly, and properly manage lifecycles. No matter how much effort Platform and DevOps teams spent creating clean Helm charts for their end users to self-service k8s, they often ended up spending their days wrangling cluster after cluster regardless.

Will kro be our answer?

kro’s Innovations: Generated, Safe CRDs

The primary building block in kro is the ResourceGraphDefinition (RG). This represents a set of related k8s resources that can be deployed as a single instance. These objects are defined as structured YAML that can be validated at compile-time rather than runtime. The kro docs best explain everything that goes into a ResourceGraphDefinition:

A ResourceGraphDefinition is a custom resource that lets you create new Kubernetes APIs for deploying multiple resources together. It acts as a blueprint, defining:
What users can configure (schema)
What resources to create (resources)
How resources reference each other (dependencies)
When resources should be included (conditions)
What status to expose (status)
When you create a ResourceGraphDefinition, kro generates a new API (a.k.a Custom Resource Definition) in your cluster that others can use to deploy resources in a consistent, controlled way.

Of particular interest in contrast to Helm is the way the schema has been designed in kro. kro’s schema has simple types and claims to be a more “human-friendly and readable syntax” (it looks better than Helm but not perfect).

The API generated from this ResourceGraphDefinition is then provided to end users in the cluster to enable them to safely create instances of this resource with the configurations they are explicitly permitted to make by the schema. Everything else is handled by the CRD generated from the RG, including the correct ordering of dependencies.

To handle dependencies, a Direct Acyclic Graph (DAG) is created based on the way resources are linked in the ResourceGraphDefinition. The generated CRD will then implement this DAG not just in the instantiation of the resource, but also throughout its lifecycle.

Once invoked, here’s how kro leverages the native k8s API to apply the CRD:

kro is designed to use core Kubernetes primitives to make resource grouping, customization, and dependency management simpler. When a ResourceGraphDefinition is applied to the cluster, the kro controller verifies its specification, then dynamically creates a new CRD and registers it with the API server. kro then deploys a dedicated controller to respond to instance events on the CRD. This microcontroller is responsible for managing the lifecycle of resources defined in the ResourceGraphDefinition for each instance that is created.

Built for Platform x Security x Compliance Collaboration

kro allows Platform, Security, and Compliance teams to all work in the same place to provide developers with a secure and compliant way to consume infra. Less sprawl across multiple tools makes it easier for these teams to move quickly and work together without having to test compatibility across sprawling combinations of versions. For end-users, the simplicity of a single tool reduces mistakes and improves the user experience.

What Stands in the Way of kro’s Success?

It’s promising to see the weight of the Big 3 cloud providers behind kro, and is certainly a strong signal that this project has the potential. But no project is guaranteed success. kro isn’t yet production-ready, so its performance at scale remains to be seen. And, the additional complexity of ResourceGraphDefinitions may leave Helm better suited for simple applications or open-source packages. More complexity can be powerful, but it isn’t necessarily elegant (see Kubernetes).

Development is ongoing, so there are still many areas of the tool that aren’t fully scoped out. There’s not yet a Helm-like CLI where packages can be created, uploaded, and installed. There are also some ongoing architecture discussion around the limitations of compile-time validation for things like for-loops and how to handle security. There’s a community slack channel here if you want to join the conversation.

Despite my attention-seeking title, kro likely doesn’t spell the death of Helm, at least not soon. Helm’s simplicity and broad reach give it tremendous staying power. Even though we all have our frustrations with it, teams know what to expect with it. If I had to guess, we will see Helm remain in place for open-source projects and for small teams with adoption of Kro from enterprise platform teams.

A New Era of Kubernetes Management

As Kubernetes matures from container orchestrator to application platform, kro may provide the missing abstraction layer between infrastructure and business logic that Helm couldn’t quite provide. kro will allow platform teams to take full advantage of the power of CRDs without investing in custom controllers or wrangling Helm hell. While Helm charts won’t disappear overnight, their role may diminish as kro’s Kubernetes-native approach becomes the foundation for enterprise-grade Kubernetes.

Additional Reading and Resources

The recent joint announcement of the open-source Kubernetes Resource Orchestrator (kro, pronounced “crow”) by AWS, Google Cloud, and Azure could represent the most significant shift in Kubernetes application and package management since Helm’s debut in 2016. While Helm became the go-to package manager for the first wave of Kubernetes adopters, kro’s cloud-native-first design addresses some of the systemic pain points that we’ve experienced as Kubernetes matured into an enterprise platform. (kro repo here)

The Elephant in the Cluster: Helm's Growing Pains

Helm enabled widespread adoption of Kubernetes by giving us:

Standardized application packaging (charts)
Basic dependency management (subcharts)
Configuration abstraction (values.yaml)

But as Kubernetes deployments scaled, Helm’s architecture has revealed fundamental constraints in its ability to properly manage dependencies, handle CRD upgrades elegantly, and properly manage lifecycles. No matter how much effort Platform and DevOps teams spent creating clean Helm charts for their end users to self-service k8s, they often ended up spending their days wrangling cluster after cluster regardless.

Will kro be our answer?

kro’s Innovations: Generated, Safe CRDs

The primary building block in kro is the ResourceGraphDefinition (RG). This represents a set of related k8s resources that can be deployed as a single instance. These objects are defined as structured YAML that can be validated at compile-time rather than runtime. The kro docs best explain everything that goes into a ResourceGraphDefinition:

A ResourceGraphDefinition is a custom resource that lets you create new Kubernetes APIs for deploying multiple resources together. It acts as a blueprint, defining:
What users can configure (schema)
What resources to create (resources)
How resources reference each other (dependencies)
When resources should be included (conditions)
What status to expose (status)
When you create a ResourceGraphDefinition, kro generates a new API (a.k.a Custom Resource Definition) in your cluster that others can use to deploy resources in a consistent, controlled way.

Of particular interest in contrast to Helm is the way the schema has been designed in kro. kro’s schema has simple types and claims to be a more “human-friendly and readable syntax” (it looks better than Helm but not perfect).

The API generated from this ResourceGraphDefinition is then provided to end users in the cluster to enable them to safely create instances of this resource with the configurations they are explicitly permitted to make by the schema. Everything else is handled by the CRD generated from the RG, including the correct ordering of dependencies.

To handle dependencies, a Direct Acyclic Graph (DAG) is created based on the way resources are linked in the ResourceGraphDefinition. The generated CRD will then implement this DAG not just in the instantiation of the resource, but also throughout its lifecycle.

Once invoked, here’s how kro leverages the native k8s API to apply the CRD:

kro is designed to use core Kubernetes primitives to make resource grouping, customization, and dependency management simpler. When a ResourceGraphDefinition is applied to the cluster, the kro controller verifies its specification, then dynamically creates a new CRD and registers it with the API server. kro then deploys a dedicated controller to respond to instance events on the CRD. This microcontroller is responsible for managing the lifecycle of resources defined in the ResourceGraphDefinition for each instance that is created.

Built for Platform x Security x Compliance Collaboration

kro allows Platform, Security, and Compliance teams to all work in the same place to provide developers with a secure and compliant way to consume infra. Less sprawl across multiple tools makes it easier for these teams to move quickly and work together without having to test compatibility across sprawling combinations of versions. For end-users, the simplicity of a single tool reduces mistakes and improves the user experience.

What Stands in the Way of kro’s Success?

It’s promising to see the weight of the Big 3 cloud providers behind kro, and is certainly a strong signal that this project has the potential. But no project is guaranteed success. kro isn’t yet production-ready, so its performance at scale remains to be seen. And, the additional complexity of ResourceGraphDefinitions may leave Helm better suited for simple applications or open-source packages. More complexity can be powerful, but it isn’t necessarily elegant (see Kubernetes).

Development is ongoing, so there are still many areas of the tool that aren’t fully scoped out. There’s not yet a Helm-like CLI where packages can be created, uploaded, and installed. There are also some ongoing architecture discussion around the limitations of compile-time validation for things like for-loops and how to handle security. There’s a community slack channel here if you want to join the conversation.

Despite my attention-seeking title, kro likely doesn’t spell the death of Helm, at least not soon. Helm’s simplicity and broad reach give it tremendous staying power. Even though we all have our frustrations with it, teams know what to expect with it. If I had to guess, we will see Helm remain in place for open-source projects and for small teams with adoption of Kro from enterprise platform teams.

A New Era of Kubernetes Management

As Kubernetes matures from container orchestrator to application platform, kro may provide the missing abstraction layer between infrastructure and business logic that Helm couldn’t quite provide. kro will allow platform teams to take full advantage of the power of CRDs without investing in custom controllers or wrangling Helm hell. While Helm charts won’t disappear overnight, their role may diminish as kro’s Kubernetes-native approach becomes the foundation for enterprise-grade Kubernetes.