Skip to main content

What is Krateo Composable Operations (KCO)?

๐Ÿ’ก KCO uses Kubernetes as the orchestration layer of the entire data center and the related processes that exploit the available services.

๐Ÿ“š The use cases are diverse, from infrastructure provisioning (legacy and cloud-native, from mainframe to lambda) to scaffolding the CI/CD toolchain to prepare for onboarding a new application.

๐Ÿค The context is not only that of the green field, but KCO also adapts perfectly to a brownfield context, where the processes already exist and are distributed and implemented within different technologies that do not allow end-to-end automation of an entire blueprint.

๐ŸŽฏ Through its Operators, Kubernetes can represent the abstraction layer and standardization of the heterogeneity of systems, processes, and technologies within your organization.

๐Ÿ’ฏ There are already several operators implemented; search within, within the Upbound marketplace (, or point directly to the operators released by cloud providers such as Azure ( or AWS ( There are SDKs for writing an Operator, such as OperatorSDK ( It is also possible to interact directly with tools such as KubeBuilder (

KCO consists of the following features:

  • core-provider
  • composition-dynamic-controller
  • provider-runtime
  • patch-provider
  • event-router
  • condition-watcher (planned)

KCO Architecture


The ๐˜ค๐˜ฐ๐˜ณ๐˜ฆ-๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ ( is the first function of Krateo Composable Operations (KCO) and is vital in the Krateo PlatformOps product.

๐Ÿ“Œ The product assumes that Kubernetes is the standard for IT process orchestration, bringing together business application developers and infrastructure automation developers.

๐Ÿ“ˆ Helm is the most widely used tool for composing multiple Kubernetes manifests.

โ˜ However, it's important to note that Helm is not a resource natively recognized by Kubernetes. To install a Helm chart, you need to use the relevant CLI or tools configured to acknowledge Helm charts and install them on the cluster. For example, ArgoCD or FluxCD are two well-known options, but many others are available.

โšก๏ธ The ๐˜ค๐˜ฐ๐˜ณ๐˜ฆ-๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ is a Kubernetes operator that downloads a Helm chart using one of three possible methods (via tgz, Helm repo, or OCI image). It checks for the existence of values.schema.json for linting the Helm chart and uses it to generate a Custom Resource Definition in Kubernetes. This definition accurately represents the possible values that can be expressed for the installation of the chart.

๐Ÿ’ฏ We chose to write the ๐˜ค๐˜ฐ๐˜ณ๐˜ฆ-๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ instead of using an existing tool because no existing tool provides input validation. Some tools accept incorrect inputs and only generate error messages after receiving them.

โ—However, Kubernetes is designed to validate resource inputs before applying them to the cluster, and we adhere to this hard requirement throughout Krateo development.

โœŒ That's why we created the ๐˜ค๐˜ฐ๐˜ณ๐˜ฆ-๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ, which provides input validation and ensures that incorrect inputs are not even accepted in the first place.


The second component of Krateo Composable Operations (KCO) in Krateo PlatformOps is the ๐˜ค๐˜ฐ๐˜ฎ๐˜ฑ๐˜ฐ๐˜ด๐˜ช๐˜ต๐˜ช๐˜ฐ๐˜ฏ-๐˜ฅ๐˜บ๐˜ฏ๐˜ข๐˜ฎ๐˜ช๐˜ค-๐˜ค๐˜ฐ๐˜ฏ๐˜ต๐˜ณ๐˜ฐ๐˜ญ๐˜ญ๐˜ฆ๐˜ณ, which is an operator that is instantiated by the ๐˜ค๐˜ฐ๐˜ณ๐˜ฆ-๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ to manage the Custom Resources whose Custom Resource Definition is generated by the core provider.

๐ŸŽฎ There is nothing better than trying our free and self-service laboratory to understand in detail what the core provider and the composition-dynamic controller allow you to do together!

Get your hands dirty ๐Ÿ‘‰


The third component of Krateo Composable Operations (KCO) in Krateo PlatformOps is the ๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ-๐˜ณ๐˜ถ๐˜ฏ๐˜ต๐˜ช๐˜ฎ๐˜ฆ (, our production-grade version of the controller-runtime ( Both runtimes can be used to implement Kubernetes operators.

๐Ÿ†š What more have we added to the provider-runtime compared to the controller-runtime? Three features:

  • ๐˜ฑ๐˜ข๐˜ถ๐˜ด๐˜ช๐˜ฏ๐˜จ ๐˜ต๐˜ฉ๐˜ฆ ๐˜ณ๐˜ฆ๐˜ค๐˜ฐ๐˜ฏ๐˜ค๐˜ช๐˜ญ๐˜ช๐˜ข๐˜ต๐˜ช๐˜ฐ๐˜ฏ ๐˜ฐ๐˜ง ๐˜ต๐˜ฉ๐˜ฆ ๐˜Š๐˜ถ๐˜ด๐˜ต๐˜ฐ๐˜ฎ ๐˜™๐˜ฆ๐˜ด๐˜ฐ๐˜ถ๐˜ณ๐˜ค๐˜ฆ: the use case is in which the infrastructure that exposes the API to the Operator has anomalies that lead to maintenance (planned or extraordinary), and you want to prevent the Operator from bombarding the API with unnecessary calls.

  • ๐˜ช๐˜ฏ๐˜ฉ๐˜ช๐˜ฃ๐˜ช๐˜ต๐˜ช๐˜ฏ๐˜จ ๐˜ฐ๐˜ฏ๐˜ฆ ๐˜ฐ๐˜ณ ๐˜ฎ๐˜ฐ๐˜ณ๐˜ฆ ๐˜ฃ๐˜ฆ๐˜ฉ๐˜ข๐˜ท๐˜ช๐˜ฐ๐˜ณ๐˜ด ๐˜ฐ๐˜ง ๐˜ต๐˜ฉ๐˜ฆ ๐˜Š๐˜ถ๐˜ด๐˜ต๐˜ฐ๐˜ฎ ๐˜™๐˜ฆ๐˜ด๐˜ฐ๐˜ถ๐˜ณ๐˜ค๐˜ฆ: the example is when I want to prevent the deletion (deliberate or by mistake) of the Custom Resource in the production environment from also deleting the physical resource managed by the Operator. Another example is when I want to import a resource created before using an operator into Kubernetes.

  • ๐˜ง๐˜ฐ๐˜ณ๐˜ค๐˜ช๐˜ฏ๐˜จ ๐˜ต๐˜ฉ๐˜ฆ ๐˜ธ๐˜ณ๐˜ช๐˜ต๐˜ช๐˜ฏ๐˜จ ๐˜ฐ๐˜ง ๐˜ข ๐˜’๐˜ถ๐˜ฃ๐˜ฆ๐˜ณ๐˜ฏ๐˜ฆ๐˜ต๐˜ฆ๐˜ด ๐˜ฆ๐˜ท๐˜ฆ๐˜ฏ๐˜ต ๐˜ข๐˜ต ๐˜ฆ๐˜ข๐˜ค๐˜ฉ ๐˜ค๐˜ฉ๐˜ข๐˜ฏ๐˜จ๐˜ฆ ๐˜ฐ๐˜ง ๐˜ค๐˜ฐ๐˜ฏ๐˜ฅ๐˜ช๐˜ต๐˜ช๐˜ฐ๐˜ฏ. A Kubernetes event contains valuable information that lets you understand what happened, when, and who detected a change of condition in the managed resource ( Although extremely useful, an Operator does not necessarily write a Kubernetes event at every change of condition. Our provider runtime instead forces us to write an event.

An example of an Operator written with our provider runtime is the github-provider; look at it ๐Ÿ‘‰


The ๐˜ฑ๐˜ข๐˜ต๐˜ค๐˜ฉ-๐˜ฑ๐˜ณ๐˜ฐ๐˜ท๐˜ช๐˜ฅ๐˜ฆ๐˜ณ is the fourth component of Krateo Composable Operations (KCO) of Krateo PlatformOps.

๐ŸŽฏ Its primary purpose is to modify a Kubernetes resource's values by taking another resource's value as a source and possibly applying transformations.

โ†ช The need to implement the patch-provider arose from the need to establish dependencies between the outputs of one resource (for example, a field in its status) and the inputs of another.

๐Ÿ‘‡ Attached is an example of a Patch that takes the 'data.value1' field from the 'foo' ConfigMap and encodes it in base64 by adding the 'prefix-' prefix and saving the result in the 'data.value2' field of the ConfigMap 'bar'.

kind: Patch
name: sample1
apiVersion: v1
kind: ConfigMap
name: foo
fieldPath: data
apiVersion: v1
kind: ConfigMap
name: bar
fieldPath: data.value2
- b64enc .value1
- printf "prefix-%s"


The fifth component of Krateo Composable Operation (KCO) in Krateo PlatformOps is the ๐˜ฆ๐˜ท๐˜ฆ๐˜ฏ๐˜ต๐˜ณ๐˜ฐ๐˜ถ๐˜ต๐˜ฆ๐˜ณ - a cutting-edge Kubernetes Event aggregation and dispatching solution.

The ๐˜ฆ๐˜ท๐˜ฆ๐˜ฏ๐˜ต๐˜ณ๐˜ฐ๐˜ถ๐˜ต๐˜ฆ๐˜ณ is a pivotal solution for enterprises and DevOps teams seeking to enhance their monitoring and observability strategies. Efficiently routing Kubernetes cluster events to various sinks provides a consolidated view of the operational health and performance of applications running on Kubernetes.

Key Features:

  • ๐—˜๐˜ƒ๐—ฒ๐—ป๐˜ ๐—”๐—ด๐—ด๐—ฟ๐—ฒ๐—ด๐—ฎ๐˜๐—ถ๐—ผ๐—ป: Collects events from all corners of a Kubernetes cluster, offering a unified stream of insights into your infrastructure's state.
  • ๐—™๐—น๐—ฒ๐˜…๐—ถ๐—ฏ๐—น๐—ฒ ๐——๐—ถ๐˜€๐—ฝ๐—ฎ๐˜๐—ฐ๐—ต๐—ถ๐—ป๐—ด: Supports multiple sinks, enabling customized event processing and integration with monitoring tools of your choice.
  • ๐—ข๐—ฝ๐—ฒ๐—ป ๐—ฆ๐—ผ๐˜‚๐—ฟ๐—ฐ๐—ฒ: As part of our commitment to community-driven development, ๐˜ฆ๐˜ท๐˜ฆ๐˜ฏ๐˜ต๐˜ณ๐˜ฐ๐˜ถ๐˜ต๐˜ฆ๐˜ณ is fully open source, inviting worldwide contributions and developer feedback.

For more details and to get started, visit our GitHub repository:

condition-watcher (planned)โ€‹