Cloud Adoption Is Soaring, and So Is Demand for Kubernetes-Based Services

… the CR and reconcile with the CoreDNS resources to reflect the changes.

To learn how to install the CoreDNS Operator on your cluster, you can follow the instructions here.

Extending the Functionality of Kubernetes

Since the use of Operators is now generally accepted, the cluster-add-ons project was created to enable integrators and software developers to manage add-ons better with the help of Operators.

Add-ons extend the functionality of Kubernetes. Like CoreDNS and kube-proxy, some add-ons are considered essential to the functionality of a Kubernetes cluster and are shipped along with cluster management tools like Kubeadm and Kops. Other add-ons, such as Calico, Kubernetes Dashboard and NodelocalDNS, help users manage their clusters.

Each Operator is defined by a CustomResourceDefinition (CRD), which also helps manage the add-ons (e.g., installing, upgrading and choosing the version) by modifying the CRD without being dependent on the cluster management tools.

The Need for Cluster-Add-on Operators

Today, cluster management tools like Kubeadm, Kops and Cluster API are bundled with essential add-ons like CoreDNS and kube-proxy.

Some of the challenges faced are:

• Users want more flexibility with managing the add-ons installed in their clusters. Currently, add-ons get automatically managed alongside the life cycle of the cluster. For example, if a user upgrades or downgrades their version of Kubernetes, the add-on(s) version gets upgraded or downgraded along with it.

It’s becoming challenging to manage cluster management tools due to the add-ons becoming increasingly complex.

In the past, there was an attempt to solve these problems via the bash version of add-on-manager. However, this was unsuccessful and hasn’t been widely adopted.

• Operators allow users to decouple the life cycle of the add-ons from the life cycle of the cluster.

Software developers and integrators can tailor the add-on in a limited way (e.g., installing, upgrading) through the CRD. Each Operator has its own Controller, a control loop that watches the state of add-on resources and makes or requests changes where needed. The Controller tries to move the current state of the add-on resources closer to the desired state.

• Creating an Operator: The cluster-add-on Operators are created with the help of Kubebuilder, a framework for creating Kubernetes APIs using CRDs. If you’re interested in creating an Operator, please check out these step-by-step instructions on creating and deploying your Operator.

Project Status

Today, the cluster-add-on repository contains many Operators — such as CoreDNS, NodelocalDNS and kube-proxy, which can be installed and enable users to manage these add-ons on their Kubernetes clusters.

The cluster-add-on project also contains the add-on-installer library, which functions as a small implementation for applying add-on operators to the Kubernetes cluster using kubectl and Kustomize.

• Future work: We are working toward integrating the Operators into cluster management tools such as Kubeadm, Kops and Cluster API.
• Reaching out: If you’re interested in the cluster-add-ons project, want to discuss Operators, add-ons or new features, or if you need help, contact us at #cluster-addons Slack or via the SIG Cluster Lifecycle group.

Sandeep Rajan is a software engineer at Infoblox focusing on open source contributions to the Cloud Native Computing Foundation (CNCF) projects CoreDNS and Kubernetes. He earned his master’s in telecommunications engineering from the University of Maryland College Park. Follow him on LinkedIn or @Infoblox on Twitter.