Почему Openshift масштабирует старое развертывание перед последовательным развертыванием

Question

В моей команде мы иногда уменьшаем масштаб до одного модуля в Openshift, чтобы упростить тестирование. Если затем мы выполним последовательное обновление с желаемым количеством реплик, равным 2, Openshift масштабируется до двух модулей перед выполнением последовательного развертывания. Это неприятно, потому что новый «старый» модуль может запускать вещи, которые, как мы не ожидаем, начнутся до начала нового развертывания, и поэтому мы должны не забыть удалить один модуль перед новым развертыванием.

Есть ли способ остановить масштабирование старого развертывания до желаемого количества реплик, в то время как новое развертывание масштабируется до желаемого количества реплик? Кроме того, почему это работает именно так?

• OpenShift Master: v3.11.200
• Kubernetes Master: v1.11.0 + d4cacc0
• OpenShift Web Console: 3.11. 200-1-8a53b1d

Из нашего шаблона Openshift:

- apiVersion: v1
  kind: DeploymentConfig
  spec:
    replicas: 2
    strategy:
      type: Rolling

Answer 1

Это ожидаемое поведение при использовании стратегии RollingUpdate. Он удаляет старые модули один за другим, одновременно добавляя новые, сохраняя доступность приложения на протяжении всего процесса и гарантируя, что его способность обрабатывать запросы не упадет. Поскольку у вас только один модуль, Kubernetes масштабирует развертывание, чтобы сохранить стратегию и zero-downtime в соответствии с запросом в манифесте.

Он масштабируется до 2, потому что, если не указано иное, maxSurge по умолчанию составляет 25%. Это означает, что во время обновления может быть не более 25% экземпляров подов, чем желаемое количество.

Если вы хотите гарантировать, что это не будет масштабироваться, вы можете изменить стратегию на Recreate. Это приведет к удалению всех старых модулей до создания новых. Используйте эту стратегию, если ваше приложение не поддерживает параллельное выполнение нескольких версий и требует полной остановки старой версии перед запуском новой. Однако учтите, что эта стратегия действительно предполагает короткий период времени, когда ваше приложение становится полностью недоступным.

Вот хороший документ , который описывает стратегию последовательного обновления. Также стоит проверить официальную документацию kubernetes о развертываниях.