Multi-YAML workflows in Kubernetes

A Kubernetes cluster is typically shared between different teams. These teams deploy their workloads on the cluster that depend on each other and form the overall enterprise application.

For example, DevOps team deploys Prometheus and Kafka Operators on the cluster and is responsible for creating required instances of Prometheus to enable metrics collection and Kafka to ingest logs from the other applications. Database team deploys MySQL Operator and is responsible for creating Mysql instances to support web applications running on the cluster. Application developers leverage these instances and deploy their web applications. In this example every team is dealing with Kubernetes YAMLs or Helm charts to deploy their workloads. Things get tricky where these various workloads depend on each other towards forming the end to end enterprise application.

To help visualize this, here is a simple example. Database team has created 3 MySQL database instances (using MysqlCluster Custom Resource) — cluster1, cluster2, cluster3. Application team deploying a Moodle application (using Moodle Custom Resource) can claim one of these instances and use it for the Moodle application. To claim cluster1 for the Moodle application,

  • they need to import the name of the MySQL master service of cluster1 in the Moodle’s spec
  • add a label on the same MySQL service with the name of the Moodle instance (moodle1).

Now these dependencies can be statically defined and met by making sure Moodle YAML is deployed only after cluster1 exists. However, if you want to automate and establish such dependencies dynamically on the YAMLs coming from different teams or on the resources that are already deployed in the cluster, you can use KubePlus binding functions. Here is an example of using the binding functions in Moodle YAML to establish above mentioned dependencies.

You can try this example from KubePlus repository.

KubePlus Binding Functions

Multi-YAML dependencies are typically captured in the form of relationships between Kubernetes Resources. These relationships are primarily of 3 types:

(1) Labels and (2) Annotations — Labels or Annotations are key/value pairs that are attached to Kubernetes resources. Resource A from a YAML file can depend on a specific label or annotation to be given on Resource B from another YAML file to take some action.

(3) Spec Properties — Resource A’s Spec property may depend on some value coming from Resource B which is part of a separate YAML file.

Assume that Resource B depends on Resource A. A binding function is defined in Kubernetes YAML manifest that creates Resource B. The binding function allows you to import a value from a running Resource A in the cluster or add a label or annotation that depends on a running Resource A instance. The binding functions discover running instances of the Resource A at run time and perform required actions. Our KubePlus cluster-side add-on intercepts the YAML resources containing binding functions and resolves their runtime dependencies with respect to other resources running in the cluster. Here are the three binding functions:

This function imports a specific value (such as name) of the running instance of a resource A and provide it as a spec property of the resource B being deployed.

This function adds the specified label to the running instance of the resource A specified in the function definition. This function is defined as an annotation in YAML of resource B.

This function adds the specified annotation to the running instance of the resource A specified in the function definition. This function is defined as an annotation in YAML of resource B.

Filter predicates are supported to enable selecting a subset of resources if multiple resources exist of the specified resource / sub-resource type. We have found these binding functions become very useful when you have dependencies that involve sub-resources created by the Custom Resource on which there is no control at the time of YAML deployment.

Conclusion

While Helm charts help package application deployment manifests, in practice there are multiple Helm charts getting deployed on a given cluster coming from different stakeholders. KubePlus binding functions help in establishing connections between these Helm charts. Reach out to us if you are looking to create such multi-YAML workflows. We will help you bring the power of binding functions to your setup.

www.cloudark.io

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store