Стратегия обновления версии Kubernetes в группе нод Managed Kubernetes

к сведению

Выбор стратегии обновления версии Kubernetes недоступен в группе нод на выделенных серверах.

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

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

Поведение группы нод при обновлении зависит от комбинаций значений параметров — типовые комбинации рассмотрены в сценариях использования параметров обновления нод. Для группы нод с включенным автомасштабированием учтите особенности обновления при автомасштабировании.

Стратегии обновления в группах нод одного кластера могут отличаться.

Способы обновления нод

перезагрузка (значение по умолчанию) — ноды будут перезапущены с новой версией Kubernetes. Конфигурация нод, настройки операционной системы и данные на дисках сохранятся;
переустановка — ноды будут пересозданы с новой версией Kubernetes. Данные с загрузочных дисков будут удалены. Для хранения данных используйте постоянные тома.

Способ обновления нод можно выбрать только при создании кластера или добавлении группы нод. Изменить способ обновления нод нельзя.

Параметры обновления нод

Расширение размера группы, макс

Расширение размера группы, макс	Максимальное количество дополнительных нод, которые создаются в группе во время обновления версии Kubernetes, чтобы принять вытесняемые поды с заменяемых нод. Новые ноды создаются сразу с обновленной версией Kubernetes. Допустимые значения от нуля до числа, которое вы указали в поле Количество нод. Ограничение связано с тем, что за один цикл обновления можно заменить не больше нод, чем есть в группе. Например, в группе из трех нод при значении `3` все ноды заменяются за один цикл, а четвертой дополнительной ноде было бы нечего заменять. Если вы используете автомасштабирование, максимальное значение этого параметра равно максимальному количеству нод при автомасштабировании, потому что к началу обновления группа может вырасти до этого размера. Если к началу обновления в группе меньше нод, чем указано в параметре, дополнительных нод будет создано столько, сколько нод в группе. Значение по умолчанию — `0`. Не может равняться нулю, если значение поля Уменьшение размера группы, макс равно нулю. Для создания дополнительных нод необходимы свободные квоты
Уменьшение размера группы, макс	Максимальное количество нод, которые могут быть одновременно недоступны во время обновления версии Kubernetes. Допустимые значения — от нуля до числа, которое вы указали в поле Количество нод. Недоступными не могут стать больше нод, чем есть в группе. Если вы используете автомасштабирование, максимальное значение этого параметра равно максимальному количеству нод при автомасштабировании. Если значение равно количеству нод в группе, все ноды в группе нод станут недоступны одновременно. Значение по умолчанию — `1`. Не может равняться нулю, если значение поля Расширение размера группы, макс равно нулю

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

Допустимые значения от нуля до числа, которое вы указали в поле Количество нод. Ограничение связано с тем, что за один цикл обновления можно заменить не больше нод, чем есть в группе. Например, в группе из трех нод при значении 3 все ноды заменяются за один цикл, а четвертой дополнительной ноде было бы нечего заменять.

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

Значение по умолчанию — 0.

Не может равняться нулю, если значение поля Уменьшение размера группы, макс равно нулю.

Для создания дополнительных нод необходимы свободные квоты

Уменьшение размера группы, макс

Максимальное количество нод, которые могут быть одновременно недоступны во время обновления версии Kubernetes.

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

Значение по умолчанию — 1.

Не может равняться нулю, если значение поля Расширение размера группы, макс равно нулю

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

Изменить параметры обновления нод

В панели управления в верхнем меню нажмите Продукты и выберите Managed Kubernetes.
В разделе Кластеры откройте страницу кластера → вкладка Состав кластера.
В меню группы нод выберите Изменить стратегию обновления.
Укажите новые значения.
Если вы увеличили значение в поле Расширение размера группы, макс, убедитесь, что для создания дополнительных нод достаточно квот. При необходимости измените квоты.
Нажмите Сохранить.

Вытеснение подов при обновлении

При обновлении версии сначала Managed Kubernetes вытесняет с нод поды (drain):

Нода помечается как недоступная для планирования (cordon) — новые поды на нее не запускаются.
Поды вытесняются через Eviction API с учетом PodDisruptionBudget (PDB). Подробнее о PodDisruptionBudget в подразделе Pod disruption budgets документации Kubernetes.
Контроллеры (Deployment, StatefulSet, ReplicaSet) запускают вытесненные поды на других нодах кластера, которые подходят подам по ресурсам, тейнтам и правилам размещения (nodeSelector, affinity).
Когда на ноде не осталось подов приложений, нода обновляется.

При вытеснении:

поды, созданные без контроллера, удаляются и не запускаются заново;
данные в томах emptyDir удаляются вместе с подом;
поды DaemonSet не вытесняются — они остаются на ноде, пока нода не перезагрузится или не будет удалена. На новых нодах поды DaemonSet запускаются автоматически.

Чтобы не потерять данные, храните их в постоянных томах.

Если PDB не дает вытеснить поды

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

Вытеснение блокируется, например, когда:

в PDB указан maxUnavailable: 0;
в PDB minAvailable равен числу реплик приложения — например, приложение работает в одной реплике и в PDB указан minAvailable: 1;
часть реплик приложения уже недоступна, и PDB не разрешает вытеснить еще одну.

Если поды не удается вытеснить, обновление останавливается с ошибкой:

кластер переходит в статус ERROR, причину ошибки можно посмотреть в журнале событий;
ноды, которые уже обновлены, остаются на новой версии Kubernetes;
нода, с которой не удалось вытеснить поды, остается на старой версии и продолжает работать.

Чтобы продолжить обновление:

Найдите PDB, которые блокируют вытеснение:
```
kubectl get pdb --all-namespaces
```
Разрешите вытеснить хотя бы один под. Для этого увеличьте число реплик приложения или измените значение maxUnavailable или minAvailable в PDB.
Запустите обновление снова.

Сценарии использования параметров обновления нод

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

Обновление без дополнительных нод

Существующие ноды удаляются, если в полях:

Расширение размера группы, макс значение 0;
Уменьшение размера группы, макс значение больше нуля.

Версия Kubernetes обновляется одновременно для того количества нод, которое указано в поле Уменьшение размера группы, макс. Нагрузка с обновляемых нод переносится на другие ноды кластера. Если в кластере несколько групп нод, вытесненные поды запускаются на любых нодах кластера, которые подходят им по ресурсам, тейнтам и правилам размещения (nodeSelector, affinity). Поды, которые привязаны к нодам этой группы, переезжают только на ноды этой группы.

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

Этот сценарий подходит, если:

в проекте нет квот на дополнительные ноды или вы не хотите платить за них во время обновления;
в группе используются флейворы, которых может не оказаться в пуле в момент обновления, например с GPU;
приложения хранят данные на локальных дисках нод. Если выбран способ обновления Перезагрузка, ноды перезапускаются с сохранением дисков, а при создании дополнительных нод старые ноды удаляются вместе с данными.

Чтобы приложения не простаивали, на остальных нодах кластера должно хватать ресурсов для подов с обновляемых нод. Например, в кластере с одной группой из пяти нод со значением 2 в поле Уменьшение размера группы, макс поды всей группы должны поместиться на трех нодах. Если в кластере несколько групп нод, поды могут переехать на ноды других групп — если это не запрещают тейнты и правила размещения подов.

примечание

Например, у вас есть кластер с одной группой из пяти нод с параметрами обновления нод:

Расширение размера группы, макс — 0;
Уменьшение размера группы, макс — 2.

Способ обновления нод в группе нод — Перезагрузка.

В такой конфигурации при обновлении версии Kubernetes:

Две ноды помечаются как недоступные для планирования (cordon): новые поды на них не запускаются.
С этих нод вытесняются поды (drain) — подробнее в разделе Вытеснение подов при обновлении. Вытесненные поды контроллеры запускают на оставшихся трех нодах.
Когда на нодах не осталось подов приложений, ноды обновляются до новой версии Kubernetes и перезагружаются.
После перезагрузки ноды переходят в статус Ready и снова становятся доступны для планирования.
Шаги 1–4 повторяются для следующих двух нод. Поды с них вытесняются на две обновленные ноды и одну необновленную.
Шаги 1–4 повторяются для последней ноды. Поды с нее вытесняются на четыре обновленные ноды.

Обновление с дополнительными нодами

Дополнительные ноды создаются, если в полях:

Расширение размера группы, макс значение больше нуля;
Уменьшение размера группы, макс значение 0.

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

Дополнительные ноды оплачиваются так же, как и обычные рабочие ноды. Подробнее в инструкции Модель оплаты и цены Managed Kubernetes.

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

Этот сценарий подходит для production-окружений.

примечание

Например, у вас есть группа из пяти нод с параметрами обновления нод:

Расширение размера группы, макс — 2;
Уменьшение размера группы, макс — 0.

В такой конфигурации при обновлении версии Kubernetes:

Managed Kubernetes создает две дополнительные ноды с новой версией Kubernetes и ждет, когда они перейдут в статус Ready. В группе семь нод.
С двух нод со старой версией вытесняются поды — подробнее в разделе Вытеснение подов при обновлении. Поды запускаются на других нодах кластера: на новых нодах или на оставшихся старых.
Две ноды со старой версией без подов удаляются. В группе снова пять нод.
Шаги 1–3 будут повторены для следующих двух нод со старой версией.
Для последней ноды со старой версией будет создана одна дополнительная нода с новой версией.
Поды с последней ноды со старой версией будут вытеснены на новую ноду.
Нода без подов будет удалена.

Обновление занимает три цикла. В группе всегда не меньше пяти нод в статусе Ready, а во время обновления — до семи. Дополнительные ноды оплачиваются, пока существуют.

Способ обновления нод в этом сценарии не влияет на результат: старые ноды удаляются, а не перезагружаются или переустанавливаются. Данные на их локальных дисках и в томах emptyDir удаляются, у новых нод будут другие приватные IP-адреса.

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

Комбинированный сценарий

Сценарий считается комбинированным, если в полях:

Расширение размера группы, макс значение больше нуля;
Уменьшение размера группы, макс значение больше нуля.

Сценарий объединяет два предыдущих: за один цикл Managed Kubernetes одновременно создает дополнительные ноды и освобождает старые ноды от подов. За цикл обновляется до суммы значений полей Расширение размера группы, макс и Уменьшение размера группы, макс.

Дополнительные ноды создаются с новой версией Kubernetes и остаются в группе. Вместо них удаляется столько же старых нод. Остальные старые ноды обновляются выбранным способом обновления.

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

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

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

Этот сценарий подходит для больших групп нод, если важна скорость обновления. Например, группа из 20 нод со значениями 2 и 2 обновится примерно за пять циклов вместо 10.

примечание

Например, у вас есть группа из пяти нод с параметрами обновления нод:

Расширение размера группы, макс — 2;
Уменьшение размера группы, макс — 2.

Способ обновления нод в группе нод — Перезагрузка.

В такой конфигурации при обновлении версии Kubernetes:

Managed Kubernetes начинает создавать две дополнительные ноды с новой версией Kubernetes. Одновременно с двух старых нод вытесняются поды — подробнее в разделе Вытеснение подов при обновлении. Пока дополнительные ноды не перешли в статус Ready, поды запускаются на трех оставшихся старых нодах.
Дополнительные ноды переходят в статус Ready и тоже принимают поды.
Две старые ноды без подов обновляются, перезагружаются и возвращаются в статус Ready. В группе семь нод: четыре обновленные и три старые.
С двух следующих старых нод вытесняются поды.
Одна из этих нод обновляется и перезагружается, другая удаляется. В группе шесть нод: пять обновленных и одна старая.
С последней старой ноды вытесняются поды, нода удаляется. В группе пять обновленных нод.

В итоге две старые ноды заменены дополнительными, три обновлены перезагрузкой. Во время обновления в группе было от трех до семи нод в статусе Ready.

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

Особенности обновления нод при автомасштабировании

Когда начинается обновление, кластер переходит в один из двух статусов PENDING_UPGRADE_MINOR_VERSION или PENDING_UPGRADE_PATCH_VERSION. До конца обновления автомасштабирование не работает: группа не увеличивается и не уменьшается. Обновление начинается с тем количеством нод, которое есть в группе в этот момент.

Значения параметров обновления можно задать до максимального количества нод при автомасштабировании: к началу обновления группа может вырасти до этого размера. Если к началу обновления в группе меньше нод, чем указано в параметре, Managed Kubernetes уменьшает значение до количества нод в группе:

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

Дополнительные ноды не учитываются в лимитах автомасштабирования. Во время обновления нод в группе может быть больше, чем максимальное количество нод при автомасштабировании, — до двух таких максимумов.

Перед обновлением:

проверьте, что квот хватит на дополнительные ноды при максимальном размере группы. Например, при максимуме 7 нод и значении 7 в поле Расширение размера группы, макс во время обновления в группе может быть до 14 нод;
не указывайте в поле Уменьшение размера группы, макс значение, близкое к максимальному количеству нод при автомасштабировании: если к началу обновления в группе будет мало нод, недоступными станут все ее ноды;
учитывайте, что во время обновления автомасштабирование не добавит ноды: если подам не хватит ресурсов, они будут ждать запуска в статусе Pending до конца обновления.

Пример 1. Группа уменьшилась до обновления — дополнительных нод будет меньше

Например, в группе нод:

автомасштабирование — от 1 до 5 нод;
Расширение размера группы, макс — 3;
Уменьшение размера группы, макс — 0.

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

В такой конфигурации при обновлении версии Kubernetes:

Создаются две дополнительные ноды с новой версией Kubernetes.
Когда дополнительные ноды переходят в статус Ready, с двух старых нод вытесняются поды.
Старые ноды удаляются.

Обновление проходит за один цикл. В пике в группе четыре ноды.

Пример 2. Группа уменьшилась до обновления — недоступных нод будет меньше

Например, в группе нод:

автомасштабирование — от 1 до 5 нод;
Расширение размера группы, макс — 0;
Уменьшение размера группы, макс — 3.

К началу обновления автомасштабирование уменьшило группу с четырех до двух нод. Недоступными становится не больше нод, чем есть в группе, поэтому вместо трех недоступными станут две ноды — вся группа.

В такой конфигурации при обновлении версии Kubernetes с обеих нод одновременно вытесняются поды. Дальше все зависит от PodDisruptionBudget (PDB):

если PDB настроен — PDB не дает вытеснить поды, и обновление не продолжается. Подробнее в подразделе Если PDB не дает вытеснить поды.
если PDB не настроен — поды вытесняются и запускаются на нодах других групп, если там хватает ресурсов. Если других групп нет или ресурсов не хватает, поды ждут в статусе Pending, пока ноды не обновятся. Все это время приложения недоступны.

Чтобы избежать простоя, в поле Уменьшение размера группы, макс укажите значение меньше минимального количества нод при автомасштабировании. Если минимум — одна нода, используйте обновление с дополнительными нодами.

Пример 3. Значение поля Уменьшение размера группы, макс равно размеру группы — возможен простой

Например, в группе нод:

автомасштабирование — от 1 до 5 нод;
Расширение размера группы, макс — 4;
Уменьшение размера группы, макс — 4.

К началу обновления в группе четыре ноды. Это комбинированное обновление: одновременно создаются четыре дополнительные ноды и с четырех старых нод вытесняются поды — то есть со всех нод группы.

Результат зависит от того, что произойдет раньше:

если дополнительные ноды перешли в статус Ready — поды переезжают на них, приложения работают;
если вытеснены поды — подам некуда переехать внутри группы. Они запускаются на нодах других групп, если там хватает ресурсов, или ждут в статусе Pending, пока дополнительные ноды не будут готовы. Все это время приложения недоступны.

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