Wondered what happens when controller manager starts in your operator?
You can see that caches are sync’ed in both leader and non-leader operator pods which makes transition quick if leader pod exits and another operator pod becomes leader (if you run multiple pods of your operator for HA)
Why we don’t need to scale up controller of a CRD (add multiple instances of the operator)?
All core controllers in Kubernetes run single instance. If Kubernetes can do it, our operator can do too as long as we write our code carefully. Anything that is going to overload a well-written controller is also very likely to overload etcd itself. Controllers should never be doing heavy work themselves, they just orchestrate and control. Control part is usually quite fast, complicated but not CPU intensive itself. The operator control things but the actual heavy lifting (for example, DB migration by operator) should happen elsewhere in a Job or similar. Some heavy lifting can also be divided up like for example “call a create API and then wait for it to finish”, then return immediately after calling the API with RequeueAfter a delay. So it is not sitting there blocking on something slow.
Credit: @coderanger in kubebuilder slack channel
Reconciliation is level-based, meaning action isn’t driven off changes in individual Events, but instead is driven by actual cluster state read from the apiserver or a local cache. For example if responding to a Pod Delete Event, the Request won’t contain that a Pod was deleted, instead the reconcile function observes this when reading the cluster state and seeing the Pod as missing.
More on what level-based means from external slack (best explanation that I have seen so far)
coderanger:
It's a bit of jargon from electronics that got carried over into computer stuff 🙂
If you want to make a reactive system there's two main approaches, you can watch for changes and then do something in response to those changes. For example when you click a button, the app does something. That is called "edge based" because in electronics you would see a rising or falling voltage change as the thing you are paying attention to
Kubebuilder Book: https://book.kubebuilder.io/
Operator Whitepaper: https://github.com/cncf/tag-app-delivery/blob/main/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md
Controller internals; https://engineering.bitnami.com/articles/a-deep-dive-into-kubernetes-controllers.html
Best practices: https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps
Operator Ebook: https://developers.redhat.com/books/kubernetes-operators
IBM DataPower Operator: https://ibm.github.io/datapower-operator-doc/
Watch API in kubernetes: https://www.youtube.com/watch?v=PLSDvFjR9HY
Making the case for Kubernetes operators: https://practicalkubernetes.blogspot.com/2022/01/making-case-for-kubernetes-operators.html
oc get no -o custom-columns=NAME:.metadata.name,CONTAINER-RUNTIME:.status.nodeInfo.containerRuntimeVersion
OR
oc get no -o wide
Ever needed an option to run oc or kubectl command from within a pod in the cluster with proper permissions and without hard coding your (short-lived) token? With right RBAC, you can do the authn for oc/kubectl using your service account token. This token will be automatically mounted on the pod together with CA cert and you can login to oc/kubectl like this:
oc login --token="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
--server='https://kubernetes.default' \
--certificate-authority='/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
Another option:
You can configure operator deployed by OLM using Subscription Config. This will be handy for cluster administrators if there is a need to tweak the operator deployment based on cluster state. For example, you can update resource requests/limits of an OOMKilled operator pod, add a nodeSelector for operator, etc.
More details are here: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/subscription-config.md