Ingress rollingUpdate trampling record
Many documents on the Internet say that deployment can achieve lossless rolling update by configuring readiness. Is this really the case?
Recently, we found a phenomenon in the production environment that when the number of replicas instances defined by deployment is only 1, there will be holes in the execution of rollingupdate.
According to the official documentation, when deployment executes rollingupdate, it will first pull up the new version of pod and then kill the old version of pod, gradually upgrading all pod to the new version.
However, during the actual test, it is found that when the rollingupdate is executed, one of the pod in the old replicas will be killed immediately, as shown in:
Before rollingupdate:
Root@ubuntu:~ # kubectl get rsNAME DESIRED CURRENT READY AGEwebtest-static-test-com-56678f6856 1 1 1 50m
In rollingupdate:
Root@ubuntu:~ # kubectl get rsNAME DESIRED CURRENT READY AGEwebtest-static-test-com-56678f6856 0 0 0 50mwebtest-static-test-com-7d785c987 1 1 0 25m
When you execute rollingupdate, deployment creates a new rs and kills the pod in the old rs
You can see that the field of both the new and old pod READY is 0 here. There will be a problem here. If the new version of the service starts slowly (for example, tomcat), the service will not be available during this period of time.
After rollingupdate:
Root@ubuntu:~ # kubectl get rsNAME DESIRED CURRENT READY AGEwebtest-static-test-com-56678f6856 1 1 1 50mwebtest-static-test-com-7d785c987 0 0 0 25m
When a curl request is initiated every 1s from another terminal, you can see the interruption of service during the upgrade:
Root@ubuntu: ~ # for i in {0.99}; do curl http://webtest-static.test.com/index.html; echo;sleep 1 is creating this is server01-Version-2This is server01-Version-2503 Service Temporarily Unavailable503 Service Temporarily Unavailablenginx/1.15.8503 Service Temporarily Unavailable503 Service Temporarily Unavailablenginx/1.15.8... ... This is server01-Version-3This is server01-Version-3
When the number of instances (replicas) is more than 1, the service will not be interrupted during rollingupdate.
Attached: deployment yaml
ApiVersion: extensions/v1beta1kind: Deploymentmetadata: name: webtest-static-test-comspec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1 replicas: 1 template: metadata: labels: app: webtest-static-test-com domain: webtest-static.test.com version: v1 spec: imagePullSecrets:-name: registry.cn-hangzhou.aliyuncs.com containers:-name: webtest -static-sysop-duowan-com image: registry.cn-hangzhou.aliyuncs.com/test/webtest_static:2.6 command: ["/ bin/bash" "/ data/scripts/run.sh"]-name: DLC-WEBTEST--WEBTEST1 value: "true" ports:-containerPort: 80 readinessProbe: exec: command:-curl-http://webtest-static.test.com/index.html-- x-"127.0 .0.1 1---apiVersion 80 "initialDelaySeconds: 20 periodSeconds: 5 successThreshold: v1kind: Servicemetadata: name: webtest1-svc labels: app: webtest-static-test-com test: test1spec: ports:-port: 80 targetPort: 80 protocol: TCP name: http selector: app: webtest-static-test-com
