[Документация Yandex Cloud](../../../index.md) > [Yandex Managed Service for Kubernetes](../../index.md) > [Концепции](../index.md) > Группа узлов > Политика развертывания группы узлов

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

При [изменении](../../operations/node-group/node-group-update.md) группы узлов (в том числе при [обновлении версии Kubernetes](../../operations/update-kubernetes.md#node-group-upgrade)) может потребоваться остановить, перезагрузить или удалить узлы в группе. При этом группа перейдет в статус `Reconciling`, а узлы станут недоступны.

С помощью _политики развертывания_ (deploy policy) вы можете контролировать количество доступных узлов в группе во время выполнения таких операций. Политика задается с помощью пары параметров `max_expansion` и `max_unavailable`, которые можно настроить при [создании](../../operations/node-group/node-group-create.md) или [изменении](../../operations/node-group/node-group-update.md) группы узлов.

#|
|| **Параметр** | **Описание** ||
|| `max_expansion` | Максимальное количество узлов, на которое можно расширить группу при ее изменении или обновлении.

Эти узлы не являются временными и создаются с новыми параметрами, заданными для группы, например с указанными вычислительными ресурсами или версией Kubernetes.

Минимальное значение — `0` (расширение группы узлов запрещено), максимальное — `100`, по умолчанию — `3`.

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

Минимальное значение — `0` (в группе не должно быть недоступных узлов), максимальное — `100`, по умолчанию — `0`.

Если в группе не должно быть недоступных узлов, то необходимо разрешить расширение группы узлов. ||
|#

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

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

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

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

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

  {% note warning %}

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

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

  {% endnote %}

  {% cut "Пример" %}

  > Например, у вас есть группа узлов с такими параметрами:
  > * Тип масштабирования — фиксированный.
  > * Количество узлов — 5.
  > * `max_expansion` — 0.
  > * `max_unavailable` — 2.
  > 
  > В такой конфигурации при изменении группы узлов:
  > 1. Нагрузка с двух узлов будет перенесена на оставшиеся три узла.
  > 1. Два узла без нагрузки перейдут в статус `Reconciling`, будут обновлены, перезагружены и снова вернутся в статус `Running`.
  > 1. Нагрузка со следующих необновленных двух узлов будет перенесена на два обновленных узла и один необновленный.
  > 1. Два необновленных узла без нагрузки перейдут в статус `Reconciling`, будут обновлены, перезагружены и снова вернутся в статус `Running`.
  > 1. Нагрузка с последнего необновленного узла будет перенесена на четыре обновленных узла.
  > 1. Последний необновленный узел без нагрузки перейдет в статус `Reconciling`, будет обновлен, перезагружен и снова вернется в статус `Running`.

  {% endcut %}

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

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

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

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

  {% note warning %}

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

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

  {% endnote %}

  {% cut "Пример" %}

  > Например, у вас есть группа узлов с такими параметрами:
  > * Тип масштабирования — фиксированный.
  > * Количество узлов — 5.
  > * `max_expansion` — 2.
  > * `max_unavailable` — 0.
  > 
  > В такой конфигурации при изменении группы узлов:
  > 1. Будет создано два новых узла с обновленной конфигурацией.
  > 1. После того как новые узлы перейдут в статус `Running`, нагрузка с двух необновленных узлов будет перенесена на новые, а два узла без нагрузки будут удалены.
  > 1. Будут созданы еще два новых узла с обновленной конфигурацией.
  > 1. После того как новые узлы перейдут в статус `Running`, нагрузка с двух необновленных узлов будет перенесена на новые, а два узла без нагрузки будут удалены.
  > 1. Будет создан еще один новый узел с обновленной конфигурацией.
  > 1. После того как новый узел перейдет в статус `Running`, нагрузка с последнего необновленного узла будет перенесена на новый, а узел без нагрузки будет удален.

  {% endcut %}

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

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

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

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

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

  {% cut "Пример" %}

  > Например, у вас есть группа узлов с такими параметрами:
  > * Тип масштабирования — фиксированный.
  > * Количество узлов — 5.
  > * `max_expansion` — 2.
  > * `max_unavailable` — 2.
  > 
  > В такой конфигурации при изменении группы узлов:
  > 1. Начнется создание двух новых узлов с обновленной конфигурацией. В это же время нагрузка с двух необновленных узлов начнет переноситься на оставшиеся три необновленных узла.
  > 1. Новые узлы перейдут в статус `Running` и также начнут принимать нагрузку с расселяемых узлов.
  > 1. Два узла без нагрузки перейдут в статус `Reconciling`, будут обновлены, перезагружены и снова вернутся в статус `Running`.
  > 1. Нагрузка с двух необновленных узлов будет перенесена на четыре обновленных и один необновленный.
  > 1. Один узел без нагрузки перейдет в статус `Reconciling`, будет обновлен, перезагружен и снова вернется в статус `Running`. Другой узел без нагрузки будет удален.
  > 1. Нагрузка с оставшегося необновленного узла будет перенесена на пять обновленных. И этот узел будет удален.
  >
  > Поведение может немного отличаться от указанного в зависимости от того, какое событие наступает раньше: расселение подов с необновленного узла или переход новых или перезагружаемых узлов в статус `Running`, однако в конечном итоге группа перейдет в требуемое состояние.

  {% endcut %}

### Полезные ссылки {#see-also}

* [Настроить политику развертывания](../../operations/node-group/node-group-update.md#configure-deploy-policy)
* [Автоматическое масштабирование группы узлов в Managed Service for Kubernetes](cluster-autoscaler.md)
* [Обновление Kubernetes](../../operations/update-kubernetes.md)