Introduction to KUDO: Automate Day-2 Operations (I)

In this article

Introduction to KUDO: Automate Day-2 Operations (I)

Operators are one of the most powerful tools when you are working with Kubernetes, especially when you are in a scenario where Stateful conditions are required like ordered and automated rolling updates, or graceful deployment/deletion and scaling/termination. The problem, however, is writing and building Operators require deep knowledge of Kubernetes internal and a lot lines of code.

Using Kubebuilder requires writing thousands lines of controller code in GO and existing implementations often don’t cover the entire lifecycle. You can also go for Operator Framework in order to use Ansible or Helm charts but both have some limitations.

KUDO The Kubernetes Universal Declarative Operator

KUDO (Kubernetes Universal Declarative Operator) is an open-source toolkit that makes it easy to build Operators using YAML. Additionally, it provides a set of pre-built Operators, that you can use out-of-the-box or easily customize to help you standardizing operations.

Some of the reasons to try KUDO are:

  • Provides abstractions for sequencing lifecycle operations using Kubernetes objects and plans (a kind of runbook).
  • You can reuse and extend previous base Operators for custom Operators.
  • Provides a kubectl plugin, so you can use ‘kubectl kudo’ to manage, deploy and debug all your workloads.
  • Workloads are managed as CRDs which helps to keep everything in your repository with versioning.
  • Existing Operators can be managed by KUDO.

How KUDO works?

KUDO uses different objects to handle workloads: Operator, OperatorVersion and Instance.

  • Operator is being represented by a CRD object and is the high level description of a deployable service.
  • OperatorVersion represents implementation of an Operator’s specific version of a deployable application. It contains objects, plans and parameters.
  • Instance is an application instantiation to an OperatorVersion. Once created, it renders all parameters in templates such as services, pods or StatefulSets. You can create multiple instances of an OperatorVersion on your Kubernetes cluster.
Operator OperatorVersions and Instances

How Kudo orchestrates ordered tasks?

Kudo uses plans to orchestrate tasks through phases and steps using a structured runbook. Phases and steps can be run serial or parallel depending on the needs of your application. Some usual plans would be deploy, backup, restore or upgrade.

KUDO plan components

Let us take an example of a couple of plans from a MySQL Operator. Here is an extract of the YAML definition file:

plans:
  deploy:
    strategy: serial
    phases:
      - name: deploy
        strategy: serial
        steps:
          - name: deploy
            tasks:
              - deploy
          - name: init
            tasks:
              - init
          - name: cleanup
            tasks:
              - cleanup
  backup:
    strategy: serial
    phases:
      - name: backup
        strategy: serial
        steps:
          - name: pv
            tasks:
              - pv
          - name: backup
            tasks:
              - backup
          - name: cleanup
            tasks:
              - backup-cleanup

As you can see above two different plans are defined: deploy and backup. Both are using a serial strategy and they are executing tasks for any specific step. For the plan named ‘backup’ we are going to create a PVC for backup purposes, then run the backup job and finally doing a cleanup task.

KUDO Repositories

One of the main advantages of using KUDO is deploying prebuilt Operators by official maintainers. You can find those on Github like these:

  • Apache Cassandra
  • Kafka
  • MySQL
  • Elastic
  • Redis
  • Apache Zookeeper
  • Apache Spark

Overview of the Architecture

The architecture diagram below helps to understand concepts explained above. We have a CLI to get Operators based on YAML from a repository, and also to manage our workload on the Kubernetes cluster. Kudo Controller takes care of all KUDO CRDs which are tied to objects. Also, we can see the relationship and inheritance between Operators, OperatorVersions and Instances.

KUDO Architecture

Source: D2iQ

There are some cool features in the roadmap like Dynamic CRDs, Operator Dependencies and Pipe Tasks which will turn out to be a more powerful and useful tool for our Operator workloads.

Just keep tuned as we are going to explain you how to install KUDO, deploy and manage KUDO workloads in a future hands-on article.

Subscribe and discover the newest
updates, news, and features

We value your inbox and are committed to preventing spam