First we need to understand that an application running on a K8S cluster is a workload.

In K8S, a POD is used to host the application, so the thing responsible for managing the POD is called Workload Resources.

We can simply interpret it as this:

The k8S built-in workload resources include the following:

  • deployment
  • replicaset
  • statefulset
  • daemonset
  • jobs
  • cronjob
  • TTL Controller for Finished Resources
  • ReplicationController (Gradually Replaced by ReplicaSet)

Let’s start with the most common deployment.

aDeploymentTo provide declarative update capabilities for Pods and ReplicaSets, we started with:

  1. Create Deployment and bring ReplicaSet online. ReplicaSet creates Pods in the background. Check ReplicaSet online status to see if it is successful.
  2. Declare the new status of the Pod by updating the Deployment Pod template (TemplateSpec). A new ReplicaSet is created and Deployment migrates pods from the old ReplicaSet to the new ReplicaSet at a controlled rate. Each new ReplicaSet is updated to a revised version of Deployment.
  3. If the Deployment does not match your expectations, you can roll back to an earlier Deployment version. Each rollback is updated to a new version of the Deployment revision.
  4. Scaling up the application to take on more load through Deployment.
  5. Pause Deployment, make changes to PodTemplateSpec and resume execution to update the POD to the new version.

Deployment to create

Having said all that, it would be better to write a Deployment YML declaration manually (or json if you prefer, essentially the API for converting YML to JSON-formatted requests).

The following replicaset is created in Deployment. This Replicaset will start three nginx pods:

nginx-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-web
        image: nginx:latest
        ports:
        - containerPort: 80
Copy the code

Convert the declaration file into an API and submit it to apiserver via Kubectl Apply

$ kubectl apply -f nginx-deployment.yml 
deployment.apps/nginx-deployment created
Copy the code

Look at the object nginx-Deployment created by the Deployment resource (objects here are synonymous with objects in programming languages)

$ kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           67m
Copy the code

View the replicat object nginx-deployment-767CF44bff created for nginx-deplyment

$kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-767cf44bff   3         3         3       68m
Copy the code

Finally, there are three POD objects created by nginx-deployment-767CF44bFF

$ kubectl get pod 
​
NAMESPACE     NAME                                READY   STATUS    RESTARTS   AGE
default       nginx-deployment-767cf44bff-9fj8q   1/1     Running   0          13m
default       nginx-deployment-767cf44bff-f746l   1/1     Running   0          13m
default       nginx-deployment-767cf44bff-ktbzl   1/1     Running   0          13m
Copy the code

You can also view the Deployment online status through rollout status.

$kubectl rollout status deployment/nginx-deployment
deployment "nginx-deployment" successfully rolled out
Copy the code

This is the deployment resource creation object diagram:

Now let’s focus on the nginx-Deployment declaration that was created.

We split the YML file into two large sections (red) :

  • Properties.

    • apiVersion– The version of the Kubernetes API used to create the object
    • kind– The category of the object you want to create
    • metadata– Some data that helps uniquely identify an object, including onenameString, UID, and optionalnamespace

  • Specifications

    • replicas– Desired number of POD copies
    • selector– pod Indicates the label selector
    • template– pod template

    We match the contain in selectorapp=nginxTag pod, pod template for the newly created PODapp=nginxIn this way, a control loop is formed.

We can check pod labels with show-labels

$ kubectl get pod  --show-labels
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
nginx-deployment-767cf44bff-9fj8q   1/1     Running   0          81m   app=nginx,pod-template-hash=767cf44bff
nginx-deployment-767cf44bff-f746l   1/1     Running   0          81m   app=nginx,pod-template-hash=767cf44bff
nginx-deployment-767cf44bff-ktbzl   1/1     Running   0          81m   app=nginx,pod-template-hash=767cf44bff
Copy the code

Why is there another one in podpod-template-hashTag?

The eployment controller adds the POD-template-hash tag to each ReplicaSet created by Deployment. Let’s look at the selector description for RS:

$ kubectl describe rs
Name:           nginx-deployment-767cf44bff
Namespace:      default
Selector:       app=nginx,pod-template-hash=767cf44bff
Copy the code

The pod-template-hash tag ensures that there are no conflicts in the Deployment child ReplicaSets by hashing ReplicaSet’s PodTemplate. The generated hash value is added to ReplicaSet’s selector, Pod labels template, and any Pod under ReplicaSet. In this way, replicaset in Deployment can only control its own POD. Well, that’s wonderful.

The spec is different for the objects created by different workload resources. For example, in Deployment a spec can contain the following fields, which can be found in the Kubernetes API.

Most fields contain a default value that is difficult to use most of the time unless you have special requirements. You can Google it if you need to. The first use case for the Deployment workload to this point has been completed.

Deployment to update

Deployment online is triggered only when the Deployment Pod template (that is, the.spec.template field) changes, such as when the template’s label or container image is updated.

Other updates, such as scaling down on Deployment, do not trigger the online action.

  1. We can get throughkubectl setCommand to update existing work responsibility resources
$ kubectl set image deployment/nginx-deployment nginx-web=nginx:1.17 --record
deployment.apps/nginx-deployment image updated
Copy the code

— Record Is used to record kubectl operations on resources. It can be rolled back if needed later. We’ll talk about that.

Kubectl set -h query set support update content.

Available Commands:

  • env Update environment variables on a pod template
  • image Update image of a pod template resources Update resource requests/limits on objects with pod templates
  • selector Set the selector on a resource
  • serviceaccount Update ServiceAccount of a resource
  • subject Update User, Group or ServiceAccount in a RoleBinding/ClusterRoleBinding
  1. usekubectl editUpdates automatically when you edit deployment
$ kubectl edit deployment/nginx-deployment --record
deployment.apps/nginx-deployment edited
Copy the code
  1. Update the Deployment YML file directly

Personally, the best way to do this is to update the YML declaration file via kubectl Apply, so you can just manage your nginx-deployment.yml

When we look at the RS status after the update, deployment creates a new Nginx-Deployment Replicaset and puts it into use.

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-64f9765d86   4         4         4       4h11m
nginx-deployment-6cf9cc9c9d   0         0         0       5h6m
Copy the code

Take a look at the POD rolling update strategy in Deployment

We can look at the RollingUpdateStrategy field through Kubectl Describe Deployment, where the maximum number of pods unavailable for a rolling update is 1/4 and the maximum number of pods available is 1.25 times the expected number of copies (25% more).

RollingUpdateStrategy: 25% max unavailable, 25% max surge

Suppose we update 4 copies (PODS) of deployment_A to deployment_B (also 4 copies), one of the data pods has the following status

$ kubectl get pod 
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-64f9765d86-c9rlj   0/1     ContainerCreating   0          2s
nginx-deployment-64f9765d86-wngmx   0/1     ContainerCreating   0          2s
nginx-deployment-7fcdcb4b75-lmsmm   1/1     Running             0          4h6m
nginx-deployment-7fcdcb4b75-m99tx   1/1     Terminating         0          4h5m
nginx-deployment-7fcdcb4b75-tghb2   1/1     Running             0          4h5m
nginx-deployment-7fcdcb4b75-xfs2m   1/1     Running             0          4h6m
​
Copy the code

That is, only 1 is stopping, 2 new pods are being created (5 will be available soon), and the full scrolling process can be viewed through Events in Kubectl Descibe Deployment.

Try not to update labels in the template, it will cause POD isolation. This is already banned in some VERSIONS of the API.

Deployment rollback

Deployment rollback As with updates, the Pod template part is rolled back.

We use rollout History to view the historical version of a deployment. That was previously recorded through — Record.

$ kubectl  rollout history   deployment/nginx-deployment 
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         kubectl apply --filename=nginx-deployment.yml --record=true
4         kubectl apply --filename=nginx-deployment.yml --record=true
5         kubectl set image deployment/nginx-deployment nginx-web=nginx:1.17 --record=true
9         kubectl edit deployment/nginx-deployment --record=true
10        kubectl edit deployment/nginx-deployment --record=true
Copy the code

Roll back to version 5.

$ kubectl rollout undo deployment/nginx-deployment --to-revision=5
deployment.apps/nginx-deployment rolled back
Copy the code

Or simply roll back to the previous version.

$ kubectl rollout undo deployment/nginx-deployment
Copy the code

As mentioned earlier, rollback is just a more engineering term, but rollback is also an update, and the YML declaration is still the core. Therefore, we should focus more on versioning the YML files in Deployment.

Deployment zoom

Scaling is controlled by.spec.replicas, which can also be done with the scale command.

$ kubectl scale deployment/nginx-deployment --replicas=6
deployment.apps/nginx-deployment scaled
Copy the code

Automatic horizontal scaling is not covered at this time, and will be discussed in detail in the following article. Check out: Horizontal Pod Autoscaler

Deployment pause and resume

We can pause Deployment before triggering the update and then resume it after making multiple changes to bring it online once.

It’s still our previous Deployment

$ kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           30m
​
$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-64f9765d86   4         4         4       30m
​
Copy the code

Suspension of deployment

$ kubectl rollout pause deployment/nginx-deployment
error: deployments.apps "nginx-deployment" is already paused
Copy the code

Make some updates to nginx-Deployment

  1. Modify the yML file directly, update the image to nginx:1.17, and apply the changes through Kubectl apply.
  2. Use set to limit resources.
$ kubectl set resources deployment/nginx-deployment -c=nginx-web --limits=cpu=50m,memory=100Mi
deployment.apps/nginx-deployment resource requirements updated
Copy the code

At this point we look at the RS copy status and look at the Deployment version information

$ kubectl get rs 
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-64f9765d86   4         4         4       40m
​
$ kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
Copy the code

As you can see, the previous RS, deployment does not apply our changes to the object.

Now we Resume the Deployment

$ kubectl rollout resume deployment/nginx-deployment
deployment.apps/nginx-deployment resumed
Copy the code

Viewing RS Status

$ kubectl get rs 
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-64f9765d86   3         3         3       41m
nginx-deployment-7f4447656b   2         2         0       4s
Copy the code

This deployment has recovered and the update to the resource object has been applied.

Reference:

K8s official documentation Deployment