Политика развертывания группы узлов в Managed Service for Kubernetes

При изменении группы узлов (в том числе при обновлении версии Kubernetes) может потребоваться остановить, перезагрузить или удалить узлы в группе. При этом группа перейдет в статус Reconciling, а узлы станут недоступны.

С помощью политики развертывания (deploy policy) вы можете контролировать количество доступных узлов в группе во время выполнения таких операций. Политика задается с помощью пары параметров max_expansion и max_unavailable, которые можно настроить при создании или изменении группы узлов.

Параметры max_expansion и max_unavailable взаимосвязаны, и хотя бы один из них должен иметь ненулевое значение.

При изменении или обновлении группы узлов кластер действует в соответствии с заданной политикой развертывания. Поведение кластера будет отличаться в зависимости от значений параметров политики:

• Политика с параметрами max_unavailable > 0 и max_expansion = 0.

  Эта политика запрещает расширять группу узлов в процессе выполнения операции (max_expansion = 0).

  Изменение или обновление группы узлов будет выполняться путем последовательного выполнения операции для max_unavailable узлов за раз, пока операция не будет выполнена для всех узлов в группе. Так как в ходе операции выбранные узлы станут недоступны, то перед ее выполнением кластер попытается перенести рабочую нагрузку с этих узлов на оставшиеся узлы в группе.

  Важно

  Если не удастся перенести рабочую нагрузку на оставшиеся узлы из-за нехватки вычислительных ресурсов на этих узлах, то операция будет принудительно выполнена для выбранных узлов.

  Это может привести к полной или частичной недоступности ваших приложений в кластере до полного завершения операции для всей группы узлов.

  Пример

  Например, у вас есть группа узлов с такими параметрами:

  • Тип масштабирования — фиксированный.
  • Количество узлов — 5.
  • max_expansion — 0.
  • max_unavailable — 2.

  В такой конфигурации при изменении группы узлов:

  1. Нагрузка с двух узлов будет перенесена на оставшиеся три узла.
  2. Два узла без нагрузки перейдут в статус Reconciling, будут обновлены, перезагружены и снова вернутся в статус Running.
  3. Нагрузка со следующих необновленных двух узлов будет перенесена на два обновленных узла и один необновленный.
  4. Два необновленных узла без нагрузки перейдут в статус Reconciling, будут обновлены, перезагружены и снова вернутся в статус Running.
  5. Нагрузка с последнего необновленного узла будет перенесена на четыре обновленных узла.
  6. Последний необновленный узел без нагрузки перейдет в статус Reconciling, будет обновлен, перезагружен и снова вернется в статус Running.

• Политика с параметрами max_expansion > 0 и max_unavailable = 0.

  Эта политика не позволяет иметь недоступные узлы в процессе обновления (max_unavailable = 0).

  Изменение или обновление группы узлов будет выполняться путем последовательного расширения группы узлов на max_expansion новых узлов за раз. Эти узлы будут сразу создаваться с измененными параметрами или обновленной версией Kubernetes. Затем на созданные узлы будет перенесена нагрузка с существующих узлов с устаревшей конфигурацией с последующим удалением таких узлов. Процесс будет продолжаться до тех пор, пока все узлы с устаревшей конфигурацией не будут заменены на новые. Процесс переноса нагрузки с узлов также потребляет вычислительные ресурсы этих узлов.

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

  Важно

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

  При расширении группы узлов будет взиматься плата за созданные узлы. Подробнее см. в разделе Правила тарификации для Managed Service for Kubernetes.

  Пример

  Например, у вас есть группа узлов с такими параметрами:

  • Тип масштабирования — фиксированный.
  • Количество узлов — 5.
  • max_expansion — 2.
  • max_unavailable — 0.

  В такой конфигурации при изменении группы узлов:

  1. Будет создано два новых узла с обновленной конфигурацией.
  2. После того как новые узлы перейдут в статус Running, нагрузка с двух необновленных узлов будет перенесена на новые, а два узла без нагрузки будут удалены.
  3. Будут созданы еще два новых узла с обновленной конфигурацией.
  4. После того как новые узлы перейдут в статус Running, нагрузка с двух необновленных узлов будет перенесена на новые, а два узла без нагрузки будут удалены.
  5. Будет создан еще один новый узел с обновленной конфигурацией.
  6. После того как новый узел перейдет в статус Running, нагрузка с последнего необновленного узла будет перенесена на новый, а узел без нагрузки будет удален.

• Политика с параметрами max_expansion > 0 и max_unavailable > 0.

  Эта политика является комбинацией описанных выше политик.

  Изменение или обновление группы узлов будет выполняться путем последовательного выполнения операции для max_unavailable узлов за раз, пока операция не будет выполнена для всех узлов в группе. Так как в ходе операции выбранные узлы станут недоступны, то перед ее выполнением кластер попытается перенести рабочую нагрузку с этих узлов на оставшиеся узлы в группе. Процесс переноса нагрузки с узлов также потребляет вычислительные ресурсы этих узлов.

  При этом группа узлов также будет расширена на max_expansion узлов, чтобы иметь возможность принять рабочую нагрузку с узлов, для которых выполняется операция. Расширение группы и выполнение операции для узлов происходят одновременно.

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

  Пример

  Например, у вас есть группа узлов с такими параметрами:

  • Тип масштабирования — фиксированный.
  • Количество узлов — 5.
  • max_expansion — 2.
  • max_unavailable — 2.

  В такой конфигурации при изменении группы узлов:

  1. Начнется создание двух новых узлов с обновленной конфигурацией. В это же время нагрузка с двух необновленных узлов начнет переноситься на оставшиеся три необновленных узла.
  2. Новые узлы перейдут в статус Running и также начнут принимать нагрузку с расселяемых узлов.
  3. Два узла без нагрузки перейдут в статус Reconciling, будут обновлены, перезагружены и снова вернутся в статус Running.
  4. Нагрузка с двух необновленных узлов будет перенесена на четыре обновленных и один необновленный.
  5. Один узел без нагрузки перейдет в статус Reconciling, будет обновлен, перезагружен и снова вернется в статус Running. Другой узел без нагрузки будет удален.
  6. Нагрузка с оставшегося необновленного узла будет перенесена на пять обновленных. И этот узел будет удален.

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

См. такжеСм. также

• Настроить политику развертывания
• Автоматическое масштабирование группы узлов в Managed Service for Kubernetes
• Обновление Kubernetes