Taking Deployment update into consideration is a good step towards building a CI/CD (continuous integration and continuous delivery) pipeline. For a more common usage, developers don't exploit command lines to update the Deployment. They may prefer to fire some API calls from CI/CD platform, or update from a previous configuration file. Here comes an example working with the subcommand apply:

// A simple nginx Kubernetes configuration file
$ cat my-update-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-update-nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      run: simple-nginx
  template:
    metadata:
      labels:
        run: simple-nginx
    spec:
      containers:
      - name: simple-nginx
        image: nginx
        ports:
        - containerPort: 80

// create the Deployment by file and recording the command in the revision tag
$ kubectl create -f my-update-nginx.yaml --record
deployment.apps "my-update-nginx" created

As a demonstration, modifying the container image from nginx to nginx:stable (you may check the code bundle my-update-nginx-updated.yaml for the modification). Then, we can use the changed file to update with the subcommand apply:

$ kubectl apply -f my-update-nginx-updated.yaml --record
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
deployment.apps "my-update-nginx" configured
// check the update revisions and status
$ kubectl rollout history deployment my-update-nginx
deployments "my-update-nginx"
REVISION  CHANGE-CAUSE
1         kubectl create --filename=my-update-nginx.yaml --record=true
2         kubectl apply --filename=my-update-nginx-updated.yaml --record=true
$ kubectl rollout status deployment my-update-nginx
deployment "my-update-nginx" successfully rolled out

Now, you can learn another way to update your Deployment.

Digging deeper into rolling-update on Deployment, there are some parameters we may leverage when doing updates:

• minReadySeconds: After a Pod is considered to be ready, the system still waits for a period of time for going on to the next step. This time slot is the minimum ready seconds, which will be helpful when waiting for the application to complete post-configuration.
• maxUnavailable: The maximum number of Pods that can be unavailable during updating. The value could be a percentage (the default is 25%) or an integer. If the value of maxSurge is 0, which means no tolerance of the number of Pods over the desired number, the value of maxUnavailable cannot be 0.
• maxSurge: The maximum number of Pods that can be created over the desired number of ReplicaSet during updating. The value could be a percentage (the default is 25%) or an integer. If the value of maxUnavailable is 0, which means the number of serving Pods should always meet the desired number, the value of maxSurge cannot be 0.

Based on the configuration file my-update-nginx-advanced.yaml in the code bundle, try playing with these parameters by yourself and see if you can feel the ideas at work.