ожидание развертывания kubernetes между модулями при текущем обновлении

#kubernetes

#kubernetes

Вопрос:

Итак, у нас есть развертывание, в котором используются текущие обновления. Нам нужно, чтобы он делал паузу в 180 секунд между каждым запускаемым модулем. Я понимаю, что мне нужно установить MinReadySeconds: 180 и установить RollingUpdateStrategy.MaxUnavailable: 1 и RollingUpdateStrategy.MaxSurge: 1 для ожидания развертывания. С этими настройками он по-прежнему запускает модули так быстро, как только может … Чего мне не хватает.

соответствующая часть моего развертывания

 spec:
    minReadySeconds: 180
    replicas: 9
    revisionHistoryLimit: 20
    selector:
      matchLabels:
        deployment: standard
        name: standard-pod
    strategy:
      rollingUpdate:
        maxSurge: 1
        maxUnavailable: 1
      type: RollingUpdate
 

Комментарии:

1. Я понял документы и эту закрытую проблему. github.com/kubernetes/kubernetes/issues/27967

2. Не могли бы вы использовать проверку готовности с задержкой запуска на 180?

3. Я попробую это и посмотрю, работает ли это.

4. Решения представлены в приведенном ниже разделе. Не редактируйте вопрос!

Ответ №1:

Предположение, что модуль готов после определенной задержки, не очень подходит для оркестратора, такого как Kubernetes, поскольку может быть что-то, что мешает успешному запуску модуля или, возможно, задерживает запуск еще на несколько секунд.

Вместо этого вы можете использовать тесты живости и готовности, чтобы убедиться, что модуль существует и готов обслуживать трафик, прежде чем удалять старый модуль

Комментарии:

1. причина, по которой нам нужно выделить модули, заключается в том, что он должен зарегистрироваться во внешней службе (я полагаю, zookeeper). Эта внешняя служба не может обрабатывать модули, поступающие одновременно.

2. Ответ по-прежнему остается тем же. Проверка готовности должна гарантировать, что модуль готов обслуживать трафик, что включает проверку зависимостей, если они требуются. Вместо того, чтобы использовать недетерминированный ввод (т. Е. Временную задержку) для вывода о том, что мы готовы запустить новый модуль, проверка готовности должна проверить, что мы успешно зарегистрировались во внешней службе, прежде чем мы пометим себя как готовые. Это гарантирует, что даже при задержке обработки во внешней службе модуль будет зарегистрирован перед запуском нового.

Ответ №2:

Мы обновили наш кластер до более новой версии Kubernetes, и он начал работать.

Опубликовано от имени задавшего вопрос.