Break Down Kubernetes Server-Side Apply
Are you already using the SSA? Do you know the difference between CSA and SSA?
Kubernetes server-side apply(SSA) is a new Kubernetes weapon, which was released in 1.14, through 1.16 the beta version, and to the latest version 1.18 beta2. Have you tried it or intended to try it? Before that, ask yourself the following questions.
- What is Server-Side Apply(SSA)?
- What is the difference between SSA and client-side apply(CSA)?
- What are the pros and cons of SSA?
What is Server-Side Apply(SSA)?
Before understanding server-side apply, it is necessary to understand the way Kubernetes objects undergo
Usually, we use CLI commands encapsulated by kubectl to execute
apply/edit/patch and other commands to achieve objects’ declarative creating and updating. Here we can extend to more questions.
- What is the difference between the 2-way merge operation
- What happens if the object already exists before apply?
- What happens if two users apply/update the same object at the same time?
The two concepts,
last-applied-configuration annotation, and
metadata.resourceVersion field are very critical.
In the lifecycle of the entire object, APIServer accepts any object’s
create/update/patch request through the REST API (kubectl encapsulated) and then completes related actions with the following process.
Essentially, concurrency control is achieved by version control, ensuring the object data integrity.
- last-applied-configuration. After executing
kubectl apply,this annotation will be added to the object, including the object’s fields. And kubectl will modify the content of the annotation correspondingly each time you update or delete the content.
- resourceVersion. APIServer determines whether the update is legal with it and saves it in etcd. It increases globally and…