Break Down Kubernetes Server-Side Apply

Are you already using the SSA? Do you know the difference between CSA and SSA?

from https://unsplash.com/@sevethavi

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 undergocreate/update.

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 update and patch?
• 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.

CSA dry-run and apply

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…