Getting started with kubernetes to the real-world Stateless controller

1. Learn more about controllers

1.1 Controller Overview

Pod is the basis of all running applications or deploying services in kubernetes. It can be seen as a robot running in k8s. Applications running alone in Pod do not have advanced features, such as Pod cannot migrate automatically when a node fails, Pod multi-replica extends horizontally, RollingUpdate is upgraded horizontally, and so on. Pod is generally not used alone and needs to be implemented by a controller.

Let's first look at a concept ReplicationController replica controller, or RC, which is the basis for high availability of Pod. By defining replicas for replicas, the RC automatically creates a Pod when the number of Pods running is less than replicas, and automatically deletes redundant Pods when the number of Pods is more than replicas, ensuring that the number of replicas defined for Pod and RC currently running is consistent.

Replica controllers include Deployment, ReplicaSet, ReplicationController, StatefulSet, and so on.There are two common types: Deployment and StatefulSet, Deployment for stateless services, StatefulSet for stateless services, ReplicaSet as the Deployment backend replica controller, and ReplicationController as the old replica controller.

To achieve different functions, kubernetes offers a variety of different controllers to meet different business scenarios, which can be divided into four categories:

  • Stateless application s such as Deployment, ReplicaSet, RC, etc.
  • Stateful application s have stateful applications and need to save data states, such as databases, database clusters;
  • Node daemon nodes support daemon and are suitable for running Daemon on all or part of nodes, such as logging, monitoring collection;
  • Batch batch tasks, non-long running services, are divided into one-time running Job and planned running CronJob.

This article focuses on the use of stateless service replica controllers, including Deployment, ReplicaSet, and ReplicationController.

1.2 Deployment

Deployment is a stateless application replica controller that defines the number of replicas of a Pod by declarative declaration. Deployment's replica mechanism is implemented by ReplicaSet. Replicas replicas are managed by adding and deleting Pods in ReplicaSet. RollingUpdate creates a new ReplicaSet and then gradually removes and adds the number of Pods in ReplicaSet to achieve scrolling improvementNew, Deployment scenarios are as follows:

  • RollingUpdate is rolled up and backstage is implemented through ReplicaSet
  • Multiple replicas implementation, increasing replicas (high load) or reducing replicas (low load)
  • Applying rollback Rollout, version updates support rollback

1.2.1 Deployment Definition

  1. We define a Deployment with 3 copies and the Pod is encapsulated in the Deployment as a template Template. In order to combine the previous Pod learning content, we added the definitions of resource and health check, which refer to the previous article.
[root@node-1 happylau]# cat deployment-demo.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:            #Deployment metadata information, including name, label
  name: deployment-nginx-demo
  labels:
    app: nginx
    rc: deployment
  annotations:
    kubernetes.io/replicationcontroller: Deployment
    kubernetes.io/description: "ReplicationController Deployment Demo"
spec:
  replicas: 3          #Number of copies, including 3 Pod copies
  selector:            #Label selector, select to manage pods containing specified labels
    matchLabels:
      app: nginx
      rc: deployment
  template:       #The following is Pod's template definition, no apiVersion, Kind property, metadata definition required
    metadata:          #Pod's metadata information must contain labels
      labels:
        app: nginx
        rc: deployment 
    spec:              #spec Specifies the property information of the container
      containers:
      - name: nginx-deployment
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:          #Container Port Information
        - name: http-80-port
          protocol: TCP
          containerPort: 80
        resources:      #Resource management, requests request resources, limits limit resources
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 200m
            memory: 256Mi
        livenessProbe:  #Health Checker Liveness Probe, Survival Check
          httpGet:
            path: /index.html
            port: 80
            scheme: HTTP
          initialDelaySeconds: 3
          periodSeconds: 5
          timeoutSeconds: 2
        readinessProbe:  #Readiness Probe, Health Checker, Readiness Check
          httpGet:
            path: /index.html
            port: 80
            scheme: HTTP
          initialDelaySeconds: 3
          periodSeconds: 5
          timeoutSeconds: 2

Deployment field description:

  • Deployment basic properties, including apiVersion,Kind,metadata, and spec, where,Deployment.metdataSpecify the name and label content.Deployment.specSpecify the attribute information for the deployment group;
  • The deployment attribute information contains replicas, Selector, and templates, where replicas specify the number of copies, Selector specifies the managed Pod tag, template is the template that defines Pod, and Deployment creates Pod from the template;
  • Deployment.spec.templateThe template defined for Pod, unlike the PD definition, does not contain apiVersion and Kind attributes and requires metadata.Deployment.spec.templateThe.Spec is the attribute information for the container, and the other definitions are consistent with the PD.
  1. Generate Deployment, create with a--record parameter, which is recorded in annotation Deployment.kubernetes.io/revisionEdition
[root@node-1 happylau]# kubectl apply -f deployment-demo.yaml --record
deployment.apps/deployment-nginx-demo created
  1. View the Deployment list and download the mirror automatically at runtime, as follows three copies have been run
[root@node-1 happylau]# kubectl get deployments deployment-nginx-demo 
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx-demo   3/3     3            3           2m37s

NAME Representation Name,metadata.name Field Definition
READY representative Pod Health status, preceding values are readiness´╝îFollowed by liveness
UP-TO-DATE Represents an update for rolling upgrade
AVAILABLE Represents available
AGE How long it has been since it was created
  1. Looking at Deployment details, you can see that Deployment controls the number of copies of Pod through a deployment-nginx-demo-866bb6cf78 replicaset replica controller

  1. View the details of the replicaset and see from Events that deployment-nginx-demo-866bb6cf78 created three Pod s

  1. View Pod details and eventually create container s, resource definitions, health checks, etc. from a Pod-defined template

From the above practice exercise, we can know that the replica control function of Deployment is implemented by replicaset, which generates the number of replicas defined in Deployment, i.e. creates multiple replicas, as shown in the following figure:

1.2.2 Deployment Expansion

When the business is busy, you can increase the number of replicas by increasing the number of replicas, which is controlled by replicas in the yaml file. When replias is set, the Deployment controller automatically creates the required number of Pods based on the current number of replicas, which are automatically added to the service to achieve load balancing. Conversely, by reducing the number of replicas, these pods are automatically removed from the service.

  1. Extend the number of copies of deployment to four by modifying the number of replicas in the yaml file or by using the scale command.
[root@node-1 ~]# kubectl scale --replicas=4 deployment deployment-nginx-demo 
deployment.extensions/deployment-nginx-demo scaled
  1. View the number of Deployment copies, increased to four
[root@node-1 ~]# kubectl get deployments
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx-demo   4/4     4            4           77m
  1. How do replica extensions work?Looking at the details of the replicaset, we see that increasing the number of copies is expanded by replicaset, and new Pod s are copied by template

  1. Replica Compression
[root@node-1 ~]# kubectl scale --replicas=2 deployment deployment-nginx-demo 
deployment.extensions/deployment-nginx-demo scaled

[root@node-1 ~]# kubectl get deployments deployment-nginx-demo 
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx-demo   2/2     2            2           7h41m

From the above walkthrough, we can see that Deployment extensions are implemented by creating or deleting Pods from ReplicaSet's templates, scales are mechanisms for manually extending replicas, and kubernetes provides horizontalpodautoscalers(Horizontal Pod Autoscaling), another replica autoscaling mechanism.That is, to achieve automatic horizontal scaling by defining CPU utilization, which depends on the monitoring component, we will introduce later.

1.2.3 Rolling Update

Deployment supports rolling updates. By default, creating Deployment increases the rolling updates policy. Update service-free interruptions (which need to be combined with services) are achieved by gradually replacing pods in replicas, as shown in the following figure: Apply updates with 3 deployment copies, updating 10.0.0.6 firstPod, update the pod application, replace the new ip, then join the service, and so on, continue to update other pods to achieve rolling updates without affecting the upgrade of the service.

By type: RollingUpdate, the maximum number of maxSurge s per update is 25% of the total number of replicas, and the maximum number of maxUnavailable s that are not available is 25%. See the rolling Update-Related policies below through kubectl get deployments deployment-nginx-demo-o yaml.

spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
      rc: deployment
  strategy:  #strategy defines an upgraded policy of type RollingUpdate
    rollingUpdate: 
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  1. Scrolling updates arePod.templateThe associated property changes defined in, such as updating the mirror to 1.9.1 below, record the action command through --record
[root@node-1 ~]# kubectl set image deployments deployment-nginx-demo nginx-deployment=nginx:1.9.1 --record
deployment.extensions/deployment-nginx-demo image updated
  1. View the status of the rolling upgrade (due to the first nginx mirror being written incorrectly, the container download mirror failed to write as nignx, resulting in two record s after modification)
[root@node-1 happylau]# kubectl rollout status deployment deployment-nginx-demo 
deployment "deployment-nginx-demo" successfully rolled out

//View the rolling upgrade version, REVSISION stands for version number:
[root@node-1 happylau]# kubectl rollout history deployment deployment-nginx-demo 
deployment.extensions/deployment-nginx-demo 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deployments deployment-nginx-demo nginx-deployment=nignx:1.9.1 --record=true
3         kubectl set image deployments deployment-nginx-demo nginx-deployment=nignx:1.9.1 --record=true
  1. Watch the Deployment upgrade process, create a new RS deployment-nginx-demo-65c8c98c7b, and gradually replace the pod in the old RS until the number of copies on the old RS deployment-nginx-demo-866bb6cf78 is 0.

  1. Looking at the list of RS, you can see that the number of copies of the new RS is 2 and the number of copies of the other RS is 0.
[root@node-1 ~]# kubectl get replicasets 
NAME                               DESIRED   CURRENT   READY   AGE
deployment-nginx-demo-65c8c98c7b   2         2         2       21m  #New RS, REVSION 3
deployment-nginx-demo-6cb65f58c6   0         0         0       22m  #Mirror Write Error RS, REVISON 2
deployment-nginx-demo-866bb6cf78   0         0         0       40m  #Old RS, corresponding to REVSION 1
  1. Test version upgrade success
[root@node-1 ~]# kubectl get pods -o wide 
NAME                                     READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
deployment-nginx-demo-65c8c98c7b-bzql9   1/1     Running   0          25m   10.244.1.58   node-2   <none>           <none>
deployment-nginx-demo-65c8c98c7b-vrjhp   1/1     Running   0          25m   10.244.2.72   node-3   <none>           <none>
[root@node-1 ~]# curl -I http://10.244.2.72 
HTTP/1.1 200 OK
Server: nginx/1.9.1 #Mirror version successfully updated
Date: Mon, 28 Oct 2019 15:28:49 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 26 May 2015 15:02:09 GMT
Connection: keep-alive
ETag: "55648af1-264"
Accept-Ranges: bytes

Version 1.2.4 fallback

If the version does not match expectations, kubernetes provides fallback functionality, which, like rolling updates, replaces Deployment with the original RS, progressively replacing a copy of Pod with the old RS.

  1. Perform rollback to REVISON version 1
[root@node-1 ~]# kubectl rollout undo deployment deployment-nginx-demo --to-revision=1
deployment.extensions/deployment-nginx-demo rolled back
  1. View Deployment's fallback status and historical version
[root@node-1 ~]# kubectl rollout status deployment deployment-nginx-demo 
deployment "deployment-nginx-demo" successfully rolled out

[root@node-1 ~]# kubectl rollout history deployment deployment-nginx-demo 
deployment.extensions/deployment-nginx-demo 
REVISION  CHANGE-CAUSE
2         kubectl set image deployments deployment-nginx-demo nginx-deployment=nignx:1.9.1 --record=true
3         kubectl set image deployments deployment-nginx-demo nginx-deployment=nignx:1.9.1 --record=true
4         <none>
  1. Looking at Deployment details, you can see that the RS has returned to the original RS

  1. Testing the version of nginx
[root@node-1 ~]# kubectl get pods -o wide 
NAME                                     READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
deployment-nginx-demo-866bb6cf78-9thtn   1/1     Running   0          3m42s   10.244.1.59   node-2   <none>           <none>
deployment-nginx-demo-866bb6cf78-ws2hx   1/1     Running   0          3m48s   10.244.2.73   node-3   <none>           <none>

#Beta version
[root@node-1 ~]# curl -I http://10.244.1.59 
HTTP/1.1 200 OK
Server: nginx/1.7.9 #Back to version 1.7.9
Date: Mon, 28 Oct 2019 15:36:07 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Dec 2014 16:25:09 GMT
Connection: keep-alive
ETag: "54999765-264"
Accept-Ranges: bytes

Summary: Deployment manages the number of copies of a Pod through ReplicaSet (expanding or reducing the number of copies), roll-over updates progressively update a Pod from an old RS to a new RS by creating a new RS, and, conversely, rollback versions are rolled back to a specified version of the ReplicaSet.

1.3 ReplicaSet

ReplicaSet replica set, referred to as RS, is used to control the number of replicas. From the above learning, we can know that Deployment actually calls ReplicaSet to control the replicas. RS does not have the characteristics of rolling upgrade and rollback. Deployment is generally recommended. The definition of ReplicaSet is similar to Deployment, as follows:

  1. Define ReplicaSet
[root@node-1 happylau]# cat replicaset-demo.yaml 
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: replicaset-demo
  labels:
    controller: replicaset
  annotations:
    kubernetes.io/description: "Kubernetes Replication Controller Replication"
spec:
  replicas: 3    #Number of copies
  selector:      #Pod Label Selector
    matchLabels:  
      controller: replicaset
  template:      #Create a template for Pod
    metadata:
      labels:
        controller: replicaset
    spec:        #Container information
      containers:
      - name: nginx-replicaset-demo
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:
        - name: http-80-port
          protocol: TCP
          containerPort: 80
  1. Create an RS and view an RS list
[root@node-1 happylau]# kubectl apply -f replicaset-demo.yaml 
replicaset.extensions/replicaset-demo created

[root@node-1 happylau]# kubectl get replicasets replicaset-demo 
NAME              DESIRED   CURRENT   READY   AGE
replicaset-demo   3         3         3       15s
  1. Extend number of copies to 4
[root@node-1 happylau]# kubectl scale --replicas=4 replicaset replicaset-demo 
replicaset.extensions/replicaset-demo scaled
[root@node-1 happylau]# kubectl get replicasets replicaset-demo 
NAME              DESIRED   CURRENT   READY   AGE
replicaset-demo   4         4         4       76s
  1. Reduce number of copies to 2
[root@node-1 happylau]# kubectl scale --replicas=2 replicaset replicaset-demo 
replicaset.extensions/replicaset-demo scaled
[root@node-1 happylau]# kubectl get replicasets replicaset-demo 
NAME              DESIRED   CURRENT   READY   AGE
replicaset-demo   2         2         2       114s
  1. Mirror version upgrade, verify that you do not have the ability to upgrade
[root@node-1 happylau]# kubectl set image replicasets replicaset-demo nginx-replicaset-demo=nginx:1.9.1
replicaset.extensions/replicaset-demo image updated  #Command executed successfully

ReplicaSet Summary: As you can see from the above demonstration, the RS definition is similar to Deployment, which can control, expand and reduce replicas. Deployment is a higher level replica controller. ReplicaSet is mainly a replica controller and a rolling update mechanism for Deployment. ReplicaSet itself cannot provide the ability to roll update.

1.4 ReplicationController

ReplicationController Replica Controller, referred to as RC, is the earliest replica controller in kubernetes. RC is a version prior to ReplicaSet. ReplicationController provides replica control capabilities, which are defined in a manner similar to Deployment and ReplicaSet, as follows:

  1. Define ReplicationController
[root@node-1 happylau]# cat rc-demo.yaml 
apiVersion: v1 
kind: ReplicationController 
metadata:
  name: rc-demo 
  labels:
    controller: replicationcontroller 
  annotations:
    kubernetes.io/description: "Kubernetes Replication Controller Replication"
spec:
  replicas: 3
  selector:     #Cannot use matchLables character set mode
    controller: replicationcontroller 
  template:
    metadata:
      labels:
        controller: replicationcontroller   
    spec:
      containers:
      - name: nginx-rc-demo 
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:
        - name: http-80-port
          protocol: TCP
          containerPort: 80
  1. Generate RC and view list
[root@node-1 happylau]# kubectl apply -f rc-demo.yaml 
replicationcontroller/rc-demo created

[root@node-1 happylau]# kubectl get replicationcontrollers 
NAME      DESIRED   CURRENT   READY   AGE
rc-demo   3         3         3       103s

#View details
[root@node-1 happylau]# kubectl describe replicationcontrollers rc-demo 
Name:         rc-demo
Namespace:    default
Selector:     controller=replicationcontroller
Labels:       controller=replicationcontroller
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"v1","kind":"ReplicationController","metadata":{"annotations":{"kubernetes.io/description":"Kubernetes Replication Controlle...
              kubernetes.io/description: Kubernetes Replication Controller Replication
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  controller=replicationcontroller
  Containers:
   nginx-rc-demo:
    Image:        nginx:1.7.9
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  113s  replication-controller  Created pod: rc-demo-hm8s9
  Normal  SuccessfulCreate  113s  replication-controller  Created pod: rc-demo-xnfht
  Normal  SuccessfulCreate  113s  replication-controller  Created pod: rc-demo-lfhc9

3. Replica expansion to 4

[root@node-1 happylau]# kubectl scale --replicas=4 replicationcontroller rc-demo 
replicationcontroller/rc-demo scaled
[root@node-1 happylau]# kubectl get replicationcontrollers 
NAME      DESIRED   CURRENT   READY   AGE
rc-demo   4         4         4       3m23s 
  1. Shrink copies to 2
[root@node-1 happylau]# kubectl scale --replicas=2 replicationcontroller rc-demo 
replicationcontroller/rc-demo scaled
[root@node-1 happylau]# kubectl get replicationcontrollers 
NAME      DESIRED   CURRENT   READY   AGE
rc-demo   2         2         2       3m51s

Write at the end

This paper introduces three replica controllers in kubernetes: Deployment, ReplicaSet and ReplicationController. Deployment is currently the most widely used. ReplicaSet provides a rolling update mechanism for Deployment. RC is currently an old version of the replica controller and is currently obsolete. It is recommended to use the Deployment controller, with replica controller, extended replica, reduced replica, and rolling upgrade.Advanced capabilities such as rollback.

Reference

Deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

ReplicaSet: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

ReplicationController: https://kubernetes.io/docs/concepts/workloads/controllers/

Tags: Linux Nginx Kubernetes Nignx Attribute

Posted on Sat, 13 Jun 2020 15:12:42 -0400 by hannnndy