Релизные каналы

Managed Service for Kubernetes предоставляет обновления с помощью релизных каналов.

В сервисе поддерживается три релизных канала Kubernetes. Версии мастера и группы узлов Managed Service for Kubernetes независимы, вы можете создавать их с указанием различных версий Kubernetes, доступных в пределах одного релизного канала.

При создании кластера Managed Service for Kubernetes вы указываете один из следующих релизных каналов. Изменить канал после создания кластера Managed Service for Kubernetes нельзя, возможно только пересоздать кластер и указать новый релизный канал.

Канал	Автообновления	Описание канала
RAPID	Нельзя отключить автообновления. Можно указать временной промежуток для автообновления.	На канале в первую очередь появляются обновления, содержащие новую функциональность и улучшения.
REGULAR	Можно отключить автообновления.	Новая функциональность и улучшения попадают на канал через некоторое время после того, как были предоставлены на канале RAPID.
STABLE	Можно отключить автообновления.	Новая функциональность и улучшения попадают на канал через некоторое время после того, как были предоставлены на канале REGULAR.

Информацию о поддерживаемых версиях Kubernetes в каналах см. на странице Поддержка версий Kubernetes в Yandex Managed Service for Kubernetes.

ОбновленияОбновления

Когда на релизном канале появляется обновление, соответствующая информация отображается в консоли управления. Устанавливать обновления можно автоматически или вручную.

• Автоматическое обновление устанавливается без участия пользователя в заданный промежуток времени.

  Обновление будет инициировано в указанный промежуток времени и должно завершиться также в рамках этого промежутка. В некоторых случаях при обновлении группы узлов Managed Service for Kubernetes обновление может продолжаться за рамками указанного временного промежутка.

  В автоматическое обновление входят: новая функциональность, улучшения или исправления сервиса Managed Service for Kubernetes, а также исправления компонентов Kubernetes.

• Ручное обновление инициируется пользователем в любое время.

  В ручное обновление входит обновление минорной версии Kubernetes. При этом обновление возможно только на одну минорную версию за раз.

  Например, с 1.31 до 1.32.

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

  Например, если версия кластера 1.33, версия группы узлов может быть 1.33, 1.32 или 1.31.

Прочитайте подробнее про прекращение поддержки версии Kubernetes, а также о том, как происходит процесс обновления для разных компонентов кластера Managed Service for Kubernetes.

Прекращение поддержки версии KubernetesПрекращение поддержки версии Kubernetes

Когда после обновления старая версия Kubernetes больше не поддерживается:

• Мастер Managed Service for Kubernetes не обновляется автоматически, его необходимо обновлять вручную.
• Минорные версии (например, с 1.20 до 1.21) необходимо обновлять вручную.
• Группы узлов Managed Service for Kubernetes автоматически обновляются, если автообновления включены. Если автообновления выключены, на группах узлов Managed Service for Kubernetes остается старая версия Kubernetes. В этом случае все проблемы, связанные с группой узлов Managed Service for Kubernetes, пользователь решает самостоятельно, так как старая версия Kubernetes становится неподдерживаемой.

Процесс обновления компонентов кластера KubernetesПроцесс обновления компонентов кластера Kubernetes

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

МастерМастер

Для разных типов мастера Managed Service for Kubernetes обновление различается временем, в течение которого мастер будет недоступен:

• Базовый мастер — недоступен в течение обновления.
• Высокодоступный мастер — не теряет сетевую доступность во время обновления.

Подробнее см. в разделе Обновление кластера.

Группа узловГруппа узлов

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

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

• Политика с параметрами 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 и групп узлов выпускаются на один год. Когда срок действия сертификата закончится, кластер Managed Service for Kubernetes или группа узлов станут неработоспособными. Чтобы этого избежать, сервис Managed Service for Kubernetes автоматически обновляет их сертификаты:

• Если автоматическое обновление включено, сертификаты обновляются автоматически при каждом обновлении кластера Managed Service for Kubernetes или группы узлов.
• Если автоматическое обновление выключено, сертификаты будут обновлены принудительно за неделю до окончания их срока действия.

Подробнее об обновлении сертификатов см. в документации Kubernetes.

Обязательное обновлениеОбязательное обновление

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

Если для кластера назначено обязательное обновление:

• Вы получите уведомление о планируемом обновлении. Проверьте, что у вас настроены способы получения уведомлений.
• На странице информации о кластере отображается блок Обязательное обновление запланировано с указанием даты обновления.

Особенности обязательного обновления:

• Невозможно отказаться от обязательных обновлений.

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

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

• Если у кластера выбрано окно обновлений, то обязательное обновление произойдет в это окно. Однако если в момент обновления кластер был недоступен, то оно применится в одно из последующих окон обновлений.

• Остановленные кластеры будут обновляться в их окна обновлений в порядке, определенном сервисом.

Подробнее см. в инструкции Работа с обязательными обновлениями.

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

• Поддержка версий Kubernetes в Yandex Managed Service for Kubernetes
• История изменений в Yandex Managed Service for Kubernetes
• Kubernetes Release History