In Chapter 3, Getting Started with Kubernetes, we discussed the rolling update mechanism of the pods in a deployment. Let's recap what happens after the update process is triggered:

• The deployment creates a new ReplicaSet with 0 pods, according to the updated manifest
• The new ReplicaSet is scaled up gradually while the previous ReplicaSet keeps shrinking
• The process ends after all of the old pods are replaced

This mechanism is implemented automatically by Kubernetes, meaning we don't have to supervise the updating process. To trigger it, all we need to do is inform Kubernetes that the pod specification of a deployment is updated; that is to say, we modify the manifest of a resource in Kubernetes. Suppose we have a deployment, my-app (see ex-deployment.yml under the example directory for this section), we can modify the manifest with the sub–commands of kubectl as follows:

• kubectl patch: This patches a manifest of an object partially according to the input JSON parameter. If we'd like to update the image of my-app from alpine:3.7 to alpine:3.8, it'd be as follows:

$ kubectl patch deployment my-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"alpine:3.8"}]}}}}'

• kubectl set: This makes changes to certain properties of an object. This is a shortcut to change some properties directly. The image of deployment is one of the properties it supports:

$ kubectl set image deployment my-app app=alpine:3.8

• kubectl edit: This opens an editor and dumps the current manifest so that we can edit it interactively. The modified manifest will take effect immediately after being saved. To change the default editor for this command, use the EDITOR environment variable. For example, EDITOR="code --wait" kubectl edit deployments my-app opens Visual Studio Code.

• kubectl replace: This replaces one manifest with another submitted template file. If a resource isn't created yet or contains properties that can't be changed, it yields errors. For instance, there are two resources in our example template, ex-deployment.yml, namely the deployment, my-app, and its Service, my-app-svc. Let's replace them with a new specification file:

$ kubectl replace -f ex-deployment.yml
deployment.apps/my-app replaced
The Service "my-app-svc" is invalid: spec.clusterIP: Invalid value: "": field is immutable
$ echo $?
1

After they're replaced, we see that the error code is 1 as expected, so we are updating deployment rather than Service. This behavior is particularly important when composing automation scripts for the CI/CD flow.

• kubectl apply: This applies the manifest file anyway. In other words, if a resource exists in Kubernetes, it'd be updated; otherwise, it'd be created. When kubectl apply is used to create resources, it is roughly equal to kubectl create --save-config in terms of functionality. The applied specification file would be saved to the annotation field, kubectl.kubernetes.io/last-applied- configuration, accordingly, and we can manipulate it with the sub-commands edit-last-applied, set-last-applied, and view-last-applied. For example, we can view the template we submitted previously with the following:

$ kubectl apply -f ex-deployment.yml view-last-applied

The saved manifest information will be exactly the same as what we've sent, unlike the information we retrieve via kubectl get <resource> -o <yaml or json>, which contains an object's live status, in addition to specifications.

Although in this section we are only focusing on manipulating a deployment, the commands here also work for updating all other Kubernetes resources, such as service and role.

The recommended way to interact with a Kubernetes API server is by using kubectl. If you're in a confined environment or you want to implement your own operator controllers, there are also RESTful APIs for manipulating resources in Kubernetes. For instance, the kubectl patch command we used before would look as follows:

$ curl -X PATCH -H 'Content-Type: application/strategic-merge-patch+json' --data '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"alpine:3.8"}]}}}}' 'https://$KUBEAPI/apis/apps/v1/namespaces/default/deployments/my-app'

Here, the $KUBEAPI variable is the endpoint of the API server. See the API reference material for more information: https://kubernetes.io/docs/reference/kubernetes-api/.