Как minReadySeconds влияет на готовность зонда?

Question

Допустим, у меня есть шаблон развертывания, подобный этому

spec:
  minReadySeconds: 15
  readinessProbe:
    failureThreshold: 3
    httpGet:
      path: /
      port: 80
      scheme: HTTP
    initialDelaySeconds: 20
    periodSeconds: 20
    successThreshold: 1
    timeoutSeconds: 5

Как это повлияет на новые версии моего приложения? Будут ли учитываться значения minReadySeconds и initialDelaySeconds одновременно? Сначала придет initialDelaySeconds, затем minReadySeconds?

Answer 1

Из Kubernetes Документация по развертыванию :

.spec.minReadySeconds - это необязательное поле, которое задает минимальное количество секунд, в течение которых вновь созданный Pod должен быть готов без сбоя любого из его контейнеров, чтобы его можно было считать доступным. По умолчанию это 0 (Pod будет считаться доступным, как только он будет готов). Чтобы узнать больше о том, когда стручок считается готовым, см. Контейнерные зонды

Таким образом, ваш вновь созданный модуль приложения должен быть готов к .spec.minReadySeconds секундам, чтобы считаться доступным.

initialDelaySeconds: количество секунд после запуска контейнера до запуска датчиков живучести или готовности.

Итак, initialDelaySeconds предшествует minReadySeconds.

Допустим, контейнер в капсуле начался с t секунд. Проверка готовности будет инициирована в t+initialDelaySeconds секунд. Предположим, что Pod готов к работе t1 секунд (t1 > t+initialDelaySeconds). Так что этот модуль будет доступен через t1+minReadySeconds секунд.