Google Cloud, AWS, and Microsoft Azure have jointly announced a new open-source project called Kube Resource Orchestrator (kro, pronounced “crow”). The project is an attempt to standardise how Kubernetes resources are grouped together and deployed, and it aims to make it easier for platform teams to deploy workloads.
The announcement explains that Kubernetes lacks a native method for platform teams to create custom groups of resources that can be used by development teams, with many organisations using client-side templating tools like Helm or Kustomize, or building their own custom Kubernetes controllers. These approaches often proved costly to maintain and difficult for non-specialists to use effectively.
With kro, you can group your applications and their dependencies as a single resource that can be easily consumed by end users
– Abdelfettah Sghiouar and Nic Slattery
The core innovation of kro is the introduction of the ResourceGraphDefinition custom resource. kro encapsulates a Kubernetes deployment and its dependencies into a single API, enabling custom end-user interfaces that expose only the parameters applicable to a non-platform engineer. This masking hides the complexity of API endpoints for Kubernetes and cloud providers that are not useful in a deployment context.
The post outlines two practical examples of kro’s application. In the first scenario, a platform engineer uses kro to give organisation members self-service access to create Google Kubernetes Engine (GKE) clusters with pre-configured administrative workloads, policies, and security settings. The second example demonstrates how DevOps engineers can create reusable definitions for web applications, encapsulating all necessary resources from deployments and services to monitoring agents and cloud storage.
Kro works seamlessly with the existing cloud provider Kubernetes extensions that are available to manage cloud resources from Kubernetes. These are AWS Controllers for Kubernetes (ACK), Google’s Config Connector (KCC), and Azure Service Operator (ASO).
kro enables standardised, reusable service templates that promote consistency across different projects and environments, with the benefit of being entirely Kubernetes-native. It is still in the early stages of development. “As an early-stage project, kro is not yet ready for production use, but we still encourage you to test it out in your own Kubernetes development environments,” the post states.
In a post on the AKS Engineering Blog, Bridget Kromhout and Matthew Christopher offer a brief overview of the kro project from Microsoft’s perspective. That post emphasises Microsoft Azure’s collaboration with AWS and Google Cloud on this Kubernetes-native tool designed to simplify resource management. This post also offers Azure-specific implementation examples and highlights opportunities for community involvement.
We’re centering the needs of customers and the cloud native community to offer tooling that works seamlessly no matter where you run your K8s clusters
– Matthew Christopher and Bridget Kromhout
A walkthrough on the kro website goes under the hood to explain how kro works, explaining how kro creates a ResourceGraphDefinition by first generating a Directed Acyclic Graph (DAG) to understand the dependencies of a definition, validating them and establishing the correct deployment order. It then creates a new CustomResourceDefinition (CRD) in the Kubernetes cluster for the resources.
Some community commentary has pondered kro’s ability to augment or replace other well-established tools, such as Crossplane – an open-source CNCF project that lets users orchestrate cloud resources with Kubernetes, and Helm, the package manager for defining, installing and upgrading Kubernetes applications.
In a YouTube video on the DevOps Toolkit channel, Viktor Farcic discusses kro’s launch. He also considers its impact on Crossplane. Farcic was initially excited by kro’s potential to simplify composing cloud resources, and he successfully created a simple application definition that generated correct Kubernetes resources. However, Farcic found that more complex scenarios involving conditional resource creation and database integration caused numerous issues, such as missing default values and owner references and changes from ResourceGroups not propagating properly to existing resources.
He also notes that using YAML for imperative constructs isn’t ideal, and that adding more logic to a format not designed for it could lead to “abominations”. Most significantly for the Crossplane community, Farcic questioned kro’s purpose given its functional overlap with existing tools. “kro is serving more or less the same function as other tools created a while ago without any compelling improvement,” he observed. While kro appeared to offer a simpler syntax with less boilerplate, he says it currently provides only a fraction of Crossplane’s features and is not yet a viable replacement, especially as Crossplane supports multiple languages.
In a blog post pondering “Is the Helm Killer Finally Here?”, Wilson Spearman of Parity suggests that Helm’s architecture has fundamental constraints in managing dependencies, handling CRD upgrades and in properly managing lifecycles, and kro succeeds in having a more human-friendly and readable syntax. Spearman concludes with a prediction that Helm will continue for open-source and smaller organisations, with kro taking mindshare in the enterprise.
The kro project is available on GitHub under joint ownership by teams from Google, AWS, and Microsoft, with the community invited to contribute to its development. Comprehensive documentation and example use cases are available on the project’s website.
