Member-only story
How To Use Server-Side Apply in K8S Operators
Explore the benefits of SSA vs. CSA
“Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components.”
https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
The operator pattern is what we can rely on when there are tasks that native resources like Deployment and Pod fail to fulfill: CRD enables the addition of various fields; webhook performs validation and mutation, making full use of APIserver’s features; the control loop keeps the resources in eventual consistency, which is one of Kubernetes’ best features.
The community has shown strong support for the development of Operators and shared multiple ways to implement operators. If you are using those scaffolding tools like kubebuilder, kube-rsor Kopr but not the declarative methods, such as charm or KUDO in developing operators, you can customize an operator by defining CRD and Controller.
Sounds easy to carry out, right?
A big “no” if you put the performance into consideration. Operators are sometimes not stable after deployment. For example, the frequent reconciles influence the performance of the entire cluster once the number of resources reaches a certain scale, putting the platform’s stability at risk. As is seen from the following operator workqueue monitoring, the tasks piled up due to the slow reconciliation logic and the too-frequent resource update requirements.
Get-Modify-Put Is Not Perfect
Just like kubectl apply, Get/List-Modify-Action is the most common client-side apply(CSA), in which Action can be create, update, and delete. This method, “List the Cronjob then update the resources,” is still the demonstration in the latest kubebuilder manual, though its defects remain unsolved.
- Get/List and Action operations are not atomic, which…
