Kubernetes Operators—When, how and the gotchas to keep in mind
Table of Contents
Kubernetes Operators have now become mainstream. An Operator is essentially a Kubernetes Custom Controller managing one or more Custom Resources. The term Operator has become popular as it succinctly captures end result of what Custom Controller+Custom Resource combination is typically defined for, e.g.—declaratively managing a stateful software on Kubernetes (e.g.: databases, off-the-shelf web applications, ML workloads, etc.).
In technical terms, Custom Controller+Custom Resource combination is called ‘Custom Resource Definition’ (CRD). In the following post we use Operator and CRD interchangeably. Kubecon 2018 in Seattle had great customizing and extendibility track.
Presentations ranged from visionary, such as converting all Kubernetes constructs to CRDs, to examples of custom CRDs written for specific requirements, such as gaming server (Agones), workflow system (Airflow), Databases (Postgres Operator), proprietary SaaS products (Kolide), to Custom controllers without Custom Resources (Airbnb). Still, platform teams looking to build their own Operators face several questions regarding the overall approach, such as—which life-cycle actions of a software to automate using Operators? How to correctly model such actions using declarative primitives of a Custom Resource (the Custom Resource Spec)?
when to use Custom sub-resources? How to evaluate community Operators? Will different Custom Resources interoperate correctly?
As an example, here is a recent email from kubernetes-dev mailing list with such questions.
Source: medium.com
