kubectl-operator VS kustomize

Kubernetes Operators simplify the management of complex applications on Kubernetes. In this guide, we'll walk through creating a simple Kubernetes Operator using the Operator Framework. We'll also cover setting up a local Kubernetes cluster with KIND (Kubernetes in Docker) and deploying the Operator to the KIND cluster.

There's a kubectl extension for it too. https://github.com/operator-framework/kubectl-operator

Since Go got generics, working with the Kubernetes API could become far more ergonomic. It's been pulling teeth until now. I'm eager to see how the upstream APIs change over time.

In the mean time, one of the creators of the Operator Framework[0] built a bunch of useful patterns using generics that we used to build the SpiceDB Operator[1] called controller-idioms[2].

Does anyone know of other efforts to improve the status quo?

[0]: https://operatorframework.io

[1]: https://github.com/authzed/spicedb-operator

[2]: https://github.com/authzed/controller-idioms

There are many frameworks, like the Operator Framework (https://operatorframework.io/) to the MetaController (https://github.com/metacontroller/metacontroller) to KubeBuilder(https://github.com/kubernetes-sigs/kubebuilder) to the Kubernetes Operator Framework (kopf, https://kopf.readthedocs.io/en/stable/), among others.

Operator lifecycle manager (OLM) is a Kubernetes feature & is part of Operator framework which provides tools that helps in the development and management of operators. OpenShift 4.x is build using different operators that manages cluster components like api-server, etcd, authentication, OAuth, ingress, etc. OpenShift makes use of OLM to install these operators as part of cluster build & OLM comes by default with OpenShift. OLM is an operator itself and understanding how it manages the operator lifecycle using different CRD’s & its flow is important, which I have explained in my article.

The documentation gives you all available options, but many of them are optional. If you know the package name of the operator (which you can get either via oc get packagemanifests or kubectl operator list-available from the kubectl plugin all you really need is:

kustomize: brew install kustomize

It's a built in feature of kustomize https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/helmchartargs.go

I think the combination of Kustomize and helm works in my experience. For advanced use cases, you can also see KRM functions in Kustomize.

See for instance a related issue: https://github.com/kubernetes-sigs/kustomize/issues/3866

Using a strategic merge is the safest way so you avoid the index fragility.

Rendering out the manifests is something I have been pushing for. Not having to understand how every templating tool works and what actually is being changed is key. Though, it gets complicated when you use helm (or any templating/patching tool) that produces many variants. You also lose any release/deployment time hooks that are provided (helm hooks or recently "patched" kustomize env variables).

https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md (edit: oh I see the other commenter also included this link, oops)

Kustomize is an open-source project that “lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.” It’s now the most popular tool for customizing Kubernetes manifests reasonably, and it’s even built directly into the Kubernetes CLI since K8s v1.14.