+1. Custom controllers and custom resource definitions seem to be the coolest part of k8s. Being able to extend the functionality of a k8s cluster while minimizing new things the developer/operator needs to learn is cool. All of the custom extensions "just work" with kubectl. I think this is going to take off in many directions.
Can someone explain operators to me? I've tried to get it working, I really did. But:
- The Kubernetes API was not very well documented (this could have been my fault, I'm new to Golang, maybe I just didn't know how to read the docs well)
- There were no substantial tutorials/walkthroughs. There was one large tutorial by Red Hat, and that's about it. The tutorial itself wasn't very good. It was more like "copy-paste this 300-line Go code and there you go".
- There are no in-depth articles about the way it's supposed to work. For example, if I want to upgrade a database using operators, how do I go about it? This is particularly baffling since operators, I thought, were supposed to be for complex, stateful apps, such as DBs.
- It seems like way too much work compared to helm charts. If I want a 3-container app, that is FE <-> BE <-> DB, that'll be in hundreds of lines of Go code.
I just don't seem the benefits. Again, all of the above may be my fault. But, I'd love to get some great articles/courses on Kubernetes operators. At this point, I would definitely not recommend operators to anyone.
https://operatorhub.io/ and "operator framework" (can't find the link to a readme) are the only things that really make sense here. Don't write them from scratch.
Basic idea is that you write a process that monitors your deployment, that reacts to config changes and events. You might end up thinking "Isn't that what kubernetes should be doing already" if you are not addicted to jumping on year-old hype trains. But if you want to do k8s that's the only way to really go. Forget all the other stuff of managing deployments if it doesn't integrate with your operator strategy.
The basic operator idea comes from the SRE trenches. The idea is that any time a human touches a system (besides a crisis) , then it is a bug in the system design.
So an operator is a robot that performs the normal system duties. Currently, those can be backup, auto-scaling, etc. The "instructions" to this robot are declarative. I.e. the user specifies the desired state of the world (for example, in a yaml file) , and the robot makes the actual state equal to the desired state.
The best way to learn how to create operators is to look at existing operator code.
Kubernetes is an engine with some built-in data types and controllers for some common container use cases (N replicas, 1 replica per node, etc). These are released along with the project on a quarterly cadence.
You can also add your own data types and controllers. The combination of these things is sometimes branded an "operator" if it controls a certain piece of software. You can release and manage these yourself on your own timeline, decoupled from Kubernetes releases.
9 comments
[ 2.7 ms ] story [ 21.7 ms ] threadI hope to see the operator ecosystem grow to support more than just the management of existing open-source tools.
- The Kubernetes API was not very well documented (this could have been my fault, I'm new to Golang, maybe I just didn't know how to read the docs well)
- There were no substantial tutorials/walkthroughs. There was one large tutorial by Red Hat, and that's about it. The tutorial itself wasn't very good. It was more like "copy-paste this 300-line Go code and there you go".
- There are no in-depth articles about the way it's supposed to work. For example, if I want to upgrade a database using operators, how do I go about it? This is particularly baffling since operators, I thought, were supposed to be for complex, stateful apps, such as DBs.
- It seems like way too much work compared to helm charts. If I want a 3-container app, that is FE <-> BE <-> DB, that'll be in hundreds of lines of Go code.
I just don't seem the benefits. Again, all of the above may be my fault. But, I'd love to get some great articles/courses on Kubernetes operators. At this point, I would definitely not recommend operators to anyone.
Kubebuilder itself is a pretty decent framework to get started.
[0] https://book.kubebuilder.io/
Basic idea is that you write a process that monitors your deployment, that reacts to config changes and events. You might end up thinking "Isn't that what kubernetes should be doing already" if you are not addicted to jumping on year-old hype trains. But if you want to do k8s that's the only way to really go. Forget all the other stuff of managing deployments if it doesn't integrate with your operator strategy.
The basic operator idea comes from the SRE trenches. The idea is that any time a human touches a system (besides a crisis) , then it is a bug in the system design.
So an operator is a robot that performs the normal system duties. Currently, those can be backup, auto-scaling, etc. The "instructions" to this robot are declarative. I.e. the user specifies the desired state of the world (for example, in a yaml file) , and the robot makes the actual state equal to the desired state.
The best way to learn how to create operators is to look at existing operator code.
My preference are knative (https://knative.dev/) and Agones (https://agones.dev/site/)
For a book I would recommend:
https://learning.oreilly.com/library/view/programming-kubern...
Later this month, I hope to release a new AutoML platform which has those robots for all stages of the ML pipeline.
Kubernetes is an engine with some built-in data types and controllers for some common container use cases (N replicas, 1 replica per node, etc). These are released along with the project on a quarterly cadence.
You can also add your own data types and controllers. The combination of these things is sometimes branded an "operator" if it controls a certain piece of software. You can release and manage these yourself on your own timeline, decoupled from Kubernetes releases.