Бобы не заменяются, если MaxUnavailable установлен в 0 в Kubernetes

Question

Я хочу развертывание отката для моих модулей.Я обновляю свой модуль, используя set Image в среде CI.Когда я устанавливаю maxUnavailable в Deployment / web file равным 1, я получаю время простоя.но когда я установил maxUnavailable на 0, модули не заменяются, и контейнер / приложение не перезапускается.

Также у меня есть один узел в кластере Kubernetes, и вот его информация

    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      CPU Requests  CPU Limits  Memory Requests  Memory Limits
      ------------  ----------  ---------------  -------------
      881m (93%)    396m (42%)  909712Ki (33%)   1524112Ki (56%)
    Events:         <none>

Вот полный файл YAML.У меня есть готовый зонд установлен.

            apiVersion: extensions/v1beta1
            kind: Deployment
            metadata:
              annotations:
                deployment.kubernetes.io/revision: "10"
                kompose.cmd: C:\ProgramData\chocolatey\lib\kubernetes-kompose\tools\kompose.exe
                  convert
                kompose.version: 1.14.0 (fa706f2)
                kubectl.kubernetes.io/last-applied-configuration: |
                  {"apiVersion":"extensions/v1beta1","kind":"Deployment","metadata":{"annotations":{"kompose.cmd":"C:\\ProgramData\\chocolatey\\lib\\kubernetes-kompose\\tools\\kompose.exe convert","kompose.version":"1.14.0 (fa706f2)"},"creationTimestamp":null,"labels":{"io.kompose.service":"dev-web"},"name":"dev-web","namespace":"default"},"spec":{"replicas":1,"strategy":{},"template":{"metadata":{"labels":{"io.kompose.service":"dev-web"}},"spec":{"containers":[{"env":[{"name":"JWT_KEY","value":"ABCD"},{"name":"PORT","value":"2000"},{"name":"GOOGLE_APPLICATION_CREDENTIALS","value":"serviceaccount/quick-pay.json"},{"name":"mongoCon","value":"mongodb://quickpayadmin:quickpay1234@ds121343.mlab.com:21343/quick-pay-db"},{"name":"PGHost","value":"173.255.206.177"},{"name":"PGUser","value":"postgres"},{"name":"PGDatabase","value":"quickpay"},{"name":"PGPassword","value":"z33shan"},{"name":"PGPort","value":"5432"}],"image":"gcr.io/quick-pay-208307/quickpay-dev-node:latest","imagePullPolicy":"Always","name":"dev-web-container","ports":[{"containerPort":2000}],"readinessProbe":{"failureThreshold":3,"httpGet":{"path":"/","port":2000,"scheme":"HTTP"},"initialDelaySeconds":5,"periodSeconds":5,"successThreshold":1,"timeoutSeconds":1},"resources":{"requests":{"cpu":"20m"}}}]}}}}
              creationTimestamp: 2018-12-24T12:13:48Z
              generation: 12
              labels:
                io.kompose.service: dev-web
              name: dev-web
              namespace: default
              resourceVersion: "9631122"
              selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/web
              uid: 5e66f7b3-0775-11e9-9653-42010a80019d
            spec:
              progressDeadlineSeconds: 600
              replicas: 2
              revisionHistoryLimit: 10
              selector:
                matchLabels:
                  io.kompose.service: web
              strategy:
                rollingUpdate:
                  maxSurge: 1
                  maxUnavailable: 0
                type: RollingUpdate
              template:
                metadata:
                  creationTimestamp: null
                  labels:
                    io.kompose.service: web
                spec:
                  containers:
                  - env:
                    - name: PORT
                      value: "2000"

                    image: gcr.io/myimagepath/web-node
                    imagePullPolicy: Always
                    name: web-container
                    ports:
                    - containerPort: 2000
                      protocol: TCP
                    readinessProbe:
                      failureThreshold: 10
                      httpGet:
                        path: /
                        port: 2000
                        scheme: HTTP
                      initialDelaySeconds: 10
                      periodSeconds: 10
                      successThreshold: 1
                      timeoutSeconds: 10
                    resources:
                      requests:
                        cpu: 10m
                    terminationMessagePath: /dev/termination-log
                    terminationMessagePolicy: File
                  dnsPolicy: ClusterFirst
                  restartPolicy: Always
                  schedulerName: default-scheduler
                  securityContext: {}
                  terminationGracePeriodSeconds: 30
            status:
              availableReplicas: 2
              conditions:
              - lastTransitionTime: 2019-01-03T05:49:46Z
                lastUpdateTime: 2019-01-03T05:49:46Z
                message: Deployment has minimum availability.
                reason: MinimumReplicasAvailable
                status: "True"
                type: Available
              - lastTransitionTime: 2018-12-24T12:13:48Z
                lastUpdateTime: 2019-01-03T06:04:24Z
                message: ReplicaSet "dev-web-7bd498fc74" has successfully progressed.
                reason: NewReplicaSetAvailable
                status: "True"
                type: Progressing
              observedGeneration: 12
              readyReplicas: 2
              replicas: 2
              updatedReplicas: 2

Я пробовал с 1 репликой, и она все еще не работает.

Answer 1

В первом сценарии kubernetes удаляет один модуль (maxUnavailable: 1) и запускает модуль с новым изображением и ждет ~ 110 секунд (в зависимости от вашей проверки готовности), чтобы проверить, может ли новый модуль обслуживать запрос. Новый модуль не может обслуживать запрос, но модуль находится в рабочем состоянии и, следовательно, он удаляет второй старый модуль и запускает его с новым образом, а второй модуль ждет завершения проверки готовности. Это причина того, что между контейнерами не готовы обработать запрос, и, следовательно, время простоя.

Во втором сенарио, где у вас есть maxUnavailable:0, kubernetes сначала вызывает модуль с новым изображением, и он не может обработать запрос в течение ~ 110 секунд (в зависимости от вашей проверки готовности), и, следовательно, время ожидания и это удаляет новый модуль с новым изображением. То же самое со вторым стручком. Следовательно, ваш модуль не обновляется

Таким образом, причина в том, что вы не даете своему приложению достаточно времени, чтобы подойти и начать обслуживание запроса. Отсюда и проблема. Пожалуйста, увеличьте значение failureThreshold в вашем датчике готовности и maxUnavailable: 0, оно будет работать.