Containerisation in the enterprise - Infoblox: Embracing cluster-addon operators

As businesses continue to modernise their server estate and move towards cloud-native architectures, the elephant in the room is the monolithic core business application that cannot easily be rehosted without significant risk and disruption. 

Download this free guide

A Computer Weekly Buyers Guide to IoT

In these uncertain times, making solid predictions for the year ahead looks like a definition of a mug's game. While this has been the fuel for the fire for the boom in applications such as video conferencing as used to support remote working, the same really can be said for the internet of things (IoT). Download this E-Guide to find out what enterprises need to know about IoT.

• Corporate E-mail Address:
• • I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.
• • I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

These days, it is more efficient to deploy an application in a container than use a virtual machine. Computer Weekly now examines the modern trends, dynamics and challenges faced by organisations now migrating to the micro-engineered world of software containerisation.

As all good software architects know, a container is defined as a ‘logical’ computing environment where code is engineered to allow a guest application to run in a state where it is abstracted away from the underlying host system’s hardware and software infrastructure resources. 

So, what do enterprises need to think about when it comes to architecting, developing, deploying and maintaining software containers?

This post is written by Sandeep Rajan in his capacity as software engineer at network management company Infoblox.

Rajan writes as follows and asks: what challenges do cluster-addon operators solve?

A Kubernetes cluster is a set of node machines that run containerised applications. As Kubernetes is maturing, there have been situations where developers want to add additional applications to extend new functionalities to Kubernetes.  Such applications that can extend functionality on top of a basic Kubernetes cluster are called addons. 

Some of the popularly known addons are: Dashboard, Prometheus, network policy addons like Cilium, kube-proxy and CoreDNS. 

Operators are extensions to Kubernetes

Operators are software extensions to Kubernetes that make use of custom resources (extensions of the Kubernetes API) to manage applications and their components. 

The cluster-addons project uses operators to help manage addons on the Kubernetes cluster. By providing addons as operators, it helps users to fully automate cluster-addons in the entire process of installing and updating, handling failures if needed, scaling the application up or down depending on the needs of the application and much more. This makes it easier for users to drive such addons without needing in-depth domain specific knowledge.

Operators also have the ability to ‘self-heal’ to conform to a reconcile to the desired set state upon detecting errors.

Operators also help in preventing privilege escalation, where a malicious user might find a bug or configuration flaw and gain access to resources, potentially causing serious damage.

For developers, once the addon operator is defined, extending new features for the operator is easy. Users can rely on the operator to configure addons instead of manually delving into the inner workings.

In simple terms, we want to achieve the ease of using addons and be able to say: “I want to use X addon, let me install its operator and let it take care of everything for me.”

Pain points solved by CoreDNS operator

There have been many cases where users do not have in-depth knowledge of DNS but want to make sure that they have a working configuration of CoreDNS to ensure a functioning Kubernetes cluster. This may include installing, upgrading, scaling up/down CoreDNS, migrating the Corefile configuration etc. Using the CoreDNS Operator will ensure everything is taken care of automatically. Users just need to specify what they want and the Operator will manage the how.  

There has also been an increasing demand from users to have flexibility around managing the CoreDNS addon. With the help of a CoreDNS Operator, a user can have the freedom of choosing whether to install, uninstall, upgrade, or downgrade CoreDNS without having to rely on deploy tools such as Kops, Kubeadm, etc. where today deploy tools manage the lifecycle of CoreDNS  

This flexibility is a boon for the development side, too, as it helps to decouple the core lifecycle of Kubernetes components with the addon’s lifecycle, making it a better experience for both users and developers. 

Over time, the CoreDNS addon has increased in complexity as we added more capabilities. For example, we added the ability to migrate the CoreDNS configuration (Corefile) during upgrades, so it is easy for users to update their Corefile without having a broken configuration. The CoreDNS operator is also easy to maintain. 

How to deploy a cluster-addon operator 

This project intends to make it easy for users to develop and manage. Here is a walkthrough LINK HERE to help someone build their addon. You can use this installer library LINK HERE to install addons in a Kubernetes cluster.

The latest release of CoreDNS is v1.8.1. Currently, Kubernetes v1.20 ships with CoreDNS v1.7.0.

Some of the latest features in CoreDNS v1.8.1 include the development of the `transfer` plugin, which helps perform (outgoing) zone transfers for other plugins. It also includes the `local` plugin, a simple plugin that responds with a basic reply to a ‘local request’.

The latest release also includes support for dual-stack in Kubernetes as well as support for EndpointSlices.