kubectl create/replace vs. kubectl apply – which one to use?

Both are valid methods of managing Kubernetes objects, but there is a difference in the way they behave when objects are modified by multiple writers. It is the desired behavior, in such scenarios, that should drive the choice between the two.

There are three different ways to manage objects in Kubernetes. The diagram below describes these three methods briefly.

Now let us see how the Imperative and the Declarative object configuration methods work in reality, through a simple example.

In this example, we will create two Deployment objects (one using the Imperative method and the other using the Declarative method) and compare their live object configs at different stages.

“last-applied-configuration” section (shown with the blue arrow above) is not there in the live object config for the Deployment created by the Imperative method. “last-applied-configuration” section has a record of all the key/values which were explicitly defined in the YAML config file. It is important to note that the fields which are not explicitly defined in the YAML config files, will have default values set in the object live config.  For example: the “replicas” field value is set to 1 (default value) since the config files have no mention of “replicas” .

Now we will run the imperative command : kubctl scale -–replicas=3 ……”   on both the Deployment objects created in the previous step and note the changes to the object live configs.

The object live configs reflect the change  in the number of replicas to 3 for both the Deployment objects. “last-applied-configuration” section for the declarative Deployment object records no change due to “kubectl scale” command execution.

Now we will run the “kubectl replace …” and the “kubectl apply…” commands on the imperative object and the declarative object respectively. We will use a new version of the config files for this purpose. Let us take a closer look at the config files.

Merging changes to the object live config (key/value) based on rules in the scenarios like above, where another writer (“kubectl scale..” in this case) is involved, is a unique characteristic of the Declarative object management method. Imperative object management method does not use merging/patching techniques.

Rules for merging changes to complex field types e.g. map/list are far more complex. Please refer to https://kubernetes.io/docs/home/ for more information on Imperative and Declarative object management.

It is important to note that the use of Imperative and Declarative methods together to manage a set of Kubernetes objects may result in unpredictable object config (including errors) in some cases and it should be avoided as much as possible.

Leave a comment

Your email address will not be published. Required fields are marked *