Как автоматически остановить непрерывное обновление при CrashLoopBackOff?

Question

Я использую Google Kubernetes Engine и намеренно добавил ошибку в код. Я надеялся, что обновление будет остановлено, когда будет обнаружено состояние CrashLoopBackOff, но это не так.

На этой странице они говорят ..

Контроллер развертывания автоматически остановит неудачное развертывание, и остановит масштабирование нового ReplicaSet. Это зависит от Параметры rollUpdate (maxUnavailable конкретно), которые у вас есть указано.

Но этого не происходит, разве только если статус ImagePullBackOff?

Ниже моя конфигурация.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: volume-service
  labels:
    group: volume
    tier: service
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 2
  template:
    metadata:
      labels:
        group: volume
        tier: service
    spec:
      containers:
      - name: volume-service
        image: gcr.io/example/volume-service:latest

P.S. Я уже читал тесты живучести / готовности, но я не думаю, что это может остановить обновление? или это?

Answer 1

Оказывается, мне просто нужно установить minReadySeconds, и оно останавливает непрерывное обновление, когда новый набор реплик имеет статус CrashLoopBackOff или что-то вроде Exited with status code 1. Так что теперь старый набор реплик все еще доступен и не обновлен.

Вот новый конфиг.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: volume-service
  labels:
    group: volume
    tier: service
spec:
  replicas: 4
  minReadySeconds: 60
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 2
  template:
    metadata:
      labels:
        group: volume
        tier: service
    spec:
      containers:
      - name: volume-service
        image: gcr.io/example/volume-service:latest

Спасибо за помощь всем!

Answer 2

Приведенное вами объяснение является правильным, и это означает, что новый набор replicaSet (тот, который содержит ошибку) не будет продолжен до завершения, но будет остановлен в своем прогрессии до значения maxSurge + maxUnavailable. И старый набор реплик будет также присутствовать.

Вот пример, который я пробовал:

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

А вот и результаты:

NAME                                  READY     STATUS             RESTARTS   AGE
pod/volume-service-6bb8dd677f-2xpwn   0/1       ImagePullBackOff   0          42s
pod/volume-service-6bb8dd677f-gcwj6   0/1       ImagePullBackOff   0          42s
pod/volume-service-c98fd8d-kfff2      1/1       Running            0          59s
pod/volume-service-c98fd8d-wcjkz      1/1       Running            0          28m
pod/volume-service-c98fd8d-xvhbm      1/1       Running            0          28m

NAME                                              DESIRED   CURRENT   READY     AGE
replicaset.extensions/volume-service-6bb8dd677f   2         2         0         26m
replicaset.extensions/volume-service-c98fd8d      3         3         3         28m

Мой новый набор реплик будет запускать только 2 новых модуля (1 слот из maxUnavailable и 1 слот из maxSurge).

Старый набор реплик будет продолжать работать с 3 пакетами (4 - 1 unAvailable).

Два параметра, которые вы задаете в разделе rollingUpdate, являются ключевыми, но вы также можете играть с другими факторами, такими как readinessProbe, livenessProbe, minReadySeconds, progressDeadlineSeconds.

Для них здесь ссылка.