Common deployment schemes of Kubernetes (XIV)

Posted by Boozi on Sun, 30 Jan 2022 05:02:50 +0100

1, Common deployment schemes

Rolling update

- The service will not stop, but the old and new will coexist in the whole pod.

Recreate

- Stop the old pod first, and then create a new one. The service will be interrupted in this process.

Blue green (no shutdown, low risk)
- The application deploying v1 (the initial state) calls this version for all external request traffic
- The application code of version 2 is different from that of version 1 (new functions, Bug repair, etc.)
- Switch traffic from version 1 to version 2.
- If the test of version 2 is normal, delete the resources (such as instances) being used by version 1 and officially use version 2.
Canary

1.1. Rolling update

maxSurge: the number of pod s started first during rolling upgrade

maxUnavailable: the maximum number of unavailable pod s allowed during rolling upgrade

(1) Create the file rollingupdate yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollingupdate
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: rollingupdate
  replicas: 4
  template:
    metadata:
      labels:
        app: rollingupdate
    spec:
      containers:
      - name: rollingupdate
        image: registry.cn-hangzhou.aliyuncs.com/ghy/test-docker-image:v1.0
        ports:
        - containerPort: 8080  
---
apiVersion: v1
kind: Service
metadata:
  name: rollingupdate
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: rollingupdate
  type: ClusterIP

(2) Execute script

kubectl apply -f rollingupdate.yaml

(3) View pods

kubectl get pods

(4) View svc

kubectl get svc

(5) After the above is successful, you can directly access the services corresponding to the pod through ip

curl cluster-ip/dockerfile

(6) If the previous steps are successful, the next thing to do is to implement the rolling update action. First modify rollingupdate Yaml file, modify the image to v2 0 # then save the file

(7) On w1, keep accessing the observation output

while sleep 0.2;do curl cluster-ip/dockerfile;echo "";done

(8) On w2, monitor the pod

kubectl get pods -w

(7) Execute the apply operation to make the file take effect again and become version 2.0

kubectl apply -f rollingupdate.yaml

(8) Execute the following command to find the replacement process of new and old versions

kubectl get pods

1.2. Recreate

If we don't want new and old versions to coexist, we need to use this method if we want to stop the old version and then install the new version

(1) Write recreate Yaml file

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: recreate
  replicas: 4
  template:
    metadata:
      labels:
        app: recreate
    spec:
      containers:
      - name: recreate
        image: registry.cn-hangzhou.aliyuncs.com/ghy/test-docker-image:v1.0
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 8080

(2) Execute script

kubectl apply -f rollingupdate.yaml

(3) View pods

kubectl get pods

(4) Modify recreate. As before Version number of yaml file

kubectl apply -f recreate.yaml

(5) View pod

kubectl get pods

(6) Execute the apply operation to make the file take effect again and become version 2.0

kubectl apply -f rollingupdate.yaml

(7) Execute the following command to find that the old version stops and then start the new version

kubectl get pods

1.3 blue and green

Blue and green deployment is actually a decoration, marking one blue and one green. Version switching is declared through blue and green;

(1) Create a bluegreen yaml

#deploy
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v1.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ghy/test-docker-image:v1.0
        ports:
        - containerPort: 8080

(2) Execute script

kubectl apply -f bluegreen.yaml

(3) View pods

kubectl get pods

(4) write a service script with the file name bluegreen service yaml

apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: bluegreen
    version: v1.0
  type: ClusterIP

(5) Restart script

kubectl apply -f bluegreen-service.yaml

(6) View svc

kubectl get svc

(7) Keep visiting and observing on w1

while sleep 0.3;do curl cluster-ip/dockerfile;echo "";done

(8) The next step is to upgrade version 1.0 to version 2.0, and modify bluegreen Yaml, I mark the modified content in different colors

#deploy
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v2.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/ghy/test-docker-image:v2.0
        ports:
        - containerPort: 8080

(9) Restart script

kubectl apply -f bluegreen.yaml

(10) View pod

kubectl get pods

(11) At the same time, observe whether the address you just accessed has changed. It can be found that the two versions coexist, and the address you previously accessed has not changed. How to switch the version? There is not a bluegreen service written in the front Yaml file? It's very simple. Modify bluegreen service Yaml file points to the line, the modified bluegreen service Yaml file is as follows

apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  #That is, the traffic is switched to version 2.0
  selector:
    app: bluegreen
    version: v2.0
  type: ClusterIP

(12) Restart bluegreen service Yaml file

kubectl apply -f bluegreen-service.yaml

(13) Review svc

kubectl get svc

(14) At the same time, observe whether the address you just visited has changed. It is found that the traffic has been completely switched to v2 On version of 0

1.4 Canary

After the introduction of the first three, we will talk about a deployment method commonly used in development. In some scenarios, if we want multiple versions to coexist, how to deploy? The method is to be explained next

(1) In fact, it's very simple. Just make some small changes in our blue-green deployment in 1.3. Modify bluegreen service Yaml file, with the following changes

apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: bluegreen
    version: v2.0  #Delete the veersion and select only according to bluegreen
  type: ClusterIP

(2) Restart bluegreen service Yaml file

kubectl apply -f bluegreen-service.yaml

(3) At the same time, observe whether the address you just visited has changed. It is more convenient in istio. At this time, the old and new versions can be accessed at the same time. AB test and fewer instances of new function deployment

Topics: Kubernetes

Programmer Think

Common deployment schemes of Kubernetes (XIV)

1, Common deployment schemes

1.1. Rolling update

1.2. Recreate

1.3 blue and green

1.4 Canary

Hot Topics