Our great sponsors
-
operator-sdk
SDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
databricks-kube-operator
A Kubernetes operator to enable GitOps style deploys for Databricks resources
-
spicedb
Open Source, Google Zanzibar-inspired permissions database to enable fine-grained access control for customer applications
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
prometheus-operator
Prometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes
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
I've found operator-sdk [1] (which uses kubebuilder under the hood) to be a better starting point for operator development.
[1] https://github.com/operator-framework/operator-sdk
Here's another example of a custom rust operator, https://github.com/mach-kernel/databricks-kube-operator
Written by a co-worker to help manage our databricks projects across clusters. Works wonderfully!!
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
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
A better way to write an operator these days is to use kubebuilder [1].
My complaint is that I have seen orgs write operators for random stuff, often reinventing the wheel. Lot of operators in orgs are result of resume driven development. Having said that it often comes handy for complex orchestration.
[1]https://github.com/kubernetes-sigs/kubebuilder
I get the sentiment. We held off on building an operator until we felt there was actually value in doing so (for the most part, Deployments cover the operational needs pretty well).
Migrations can be run in containers (and they are, even with the operator), but it's actually a lot of work to run them at the right time, only once, with the right flags, in the right order, waiting for SpiceDB to reach a specific spot in a phased migrations, etc.
Moving from v1.13.0 to v1.14.0 of SpiceDB requires a multi-phase migration to avoid downtime[0], as could any phased migration for any stateful workload. The operator will walk you through them correctly, without intervention. Users who aren't running on Kubernetes or aren't using the operator often have problems running these steps correctly.
The value is in this automation, but also in the API interface itself. RDS is just some automation and an API on top of EC2, and I think RDS has value over running postgres on EC2 myself directly.
As for helm charts, this is just my opinion, but I don't think they're a good way to distribute software to end users. The interface for a helm chart becomes polluted over time in the same way that most operator APIs become polluted over time, as more and more configuration is pulled up to the top. I think helm is better suited to managing configuration you write yourself to deploy on your own clusters (I realize I'm in the minority here).
[0]: https://github.com/authzed/spicedb/releases/tag/v1.14.0
We have an FAQ about Operators here: https://github.com/cloud-ark/kubeplus/blob/master/Operator-F...
It should be helpful if you are new to the Operator concept.
Operators are generally useful for handling domain-specific actions - for example, performing database backups, installing plugins on Moodle/Wordpress, etc. If you are looking for application deployment then a Helm chart should be sufficient.
It’s a common pattern [1] how else can users override the child objects you’re controller creates?
1 https://github.com/prometheus-operator/prometheus-operator/b...