What’s in Store for Kubernetes Operators in 2020?

It is no secret that one of the most exciting things in Kubernetes world is the emergence of the Kubernetes Operator pattern. A Kubernetes Operator extends Kubernetes control plane to perform domain-specific workflow actions using declarative resource definitions. Since the concept of Operator was announced in Kubecon Copenhagen in 2018, lot of work has happened in the community around Operators in the short span of a year and a half. What’s in store for Operators in 2020? Read on to understand where we think Operators are headed in the coming year.

Kubernetes Operators in 2019

Before looking into the future of Operators, here is a quick summary of where does the Operator movement stands today.

1. Evolution of Official Operator Definition: This year broader CNCF community started taking steps toward evolving a common definition for the term Kubernetes Operator. Consensus seems to be evolving towards a definition that identifies the following key aspects of a Kubernetes Operator — that it is a Kubernetes API extension, that it encodes domain-specific workflow automation actions, and that it uses a declarative model in the form of Custom Resources for state inputs. You can follow the ongoing discussion about Operator definition on this cncf-sig-app-delivery mailing list thread .

2. Operator Tools and Operator Repositories: Operator development tools and SDKs have continued to make progress. Operator developers now have the following tools to choose from when it comes to Operator development: client-go, sample-controller, Operator SDK, Kubebuilder, Kudo, etc. In parallel, you can find pre-packaged Operators in various repositories like Operator hub, GCP marketplace, Kubedex. Such repositories continue to get more and more populated.

3. Operator enterprise readiness: As Operators are getting developed for a variety of software, it is important to have calibration model for their enterprise readiness. For this, Operator hub has developed a model to evaluate individual Operators for their capabilities like install, upgrade, lifecycle etc. In addition, CloudARK has come up with Operator Maturity Model that enables evaluation of an Operator in multi-Operator environments.

Predictions for 2020

This year we have had the opportunity of working with both teams developing Operators and teams on-boarding their complex workloads on Kubernetes that have required them to use Operators. Based on this experience, here is what we think is in store for Operators in 2020.

1. Multi Operator stacks for day-2 Operations of enterprise workloads: Some of the example workloads that we have been helping to onboard on Kubernetes include, edge networking stack, SaaS application stack, NoSQL database workload. While on-boarding these workloads on Kubernetes, it has been a natural choice to pick more than one Operators from the community to enable the end-to-end workflow requirements. The workflow actions in these workloads have included typical day-2 operations such as taking database backups, rotating SSL certificates, tearing down/starting up new network interfaces for Pods, rebalancing Cassandra cluster data upon k8s worker node restart, etc. In 2020, we expect this trend to continue with more complex and diverse enterprise workloads getting deployed on Kubernetes and multi Operator stacks being used to enable end-to-end workflow requirements.

2. Declarative Application Management and Custom Resources: Declarative Application Management (DAM) on Kubernetes encompasses tools and techniques to deploy, run and manage workloads declaratively on Kubernetes. Kubernetes at its core offers a set of declarative APIs. Kubernetes Operators increases this API surface area with Custom APIs. The challenge with these Custom APIs / Resources is to first discover which Custom Resources are available on a given cluster and then how to use them to create application workflows. In 2020, we expect Operator tooling to increase focus around Operator consumability by users of Custom APIs/Resources. At CloudARK, we have been developing KubePlus API add-on that enables declarative application management with Custom Resources. It enables creating platform workflows as-code using Kubernetes Custom and built-in resources.

3. Custom Resource insights: Given that Operators are getting adopted widely, one of the big things next year is going to be enabling DevOps teams to debug Operator Operations. In our view Kubernetes Audit logs will be the key to build tools that will enable Operator debugging. Kubernetes Audit logs are created by Kubernetes API Server and include tracking of every incoming API request. We have been building Kubeprovenance , a cluster add-on that leverages audit logs to build history of Custom Resource operations that have happened in the cluster. It provides a provenance query language to retrieve historical information about Custom Resources in a cluster. In 2020, we expect steps towards integrating such audit log information/higher-level provenance information with monitoring tools like Prometheus to provide comprehensive monitoring and debugging capabilities for Operator Operations.

Conclusion

Kubernetes Operators are ushering in a new era in platform customization. Bespoke platform layers consisting of Kubernetes Operators is becoming a reality, replacing pre-built PaaSes. Next year promises to be the one of Kubernetes Operators and their relevance increasing in enterprises’ cloud native strategies. We are looking forward to it.

Happy holidays.

www.cloudark.io