tocdepth

2

Ручное обновление кластера

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

Использование устаревших версий может привести к возникновению уязвимостей, проблемам с совместимостью и упущению полезных улучшений и исправлений.

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

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

  • Stable — доступны стабильные, тщательно протестированные и надежные функциональные возможности и улучшения.

  • Rеgular — доступны обновления, содержащие новую функциональность и улучшения.

  • Rapid — ранний доступ к новым или экспериментальным функциональным возможностям и улучшениям. Обновления могут быть нестабильны и содержать недоработки.

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

Подготовка к обновлению

Подготовка к обновлению версии Kubernetes поможет минимизировать риски и обеспечить успешное обновление кластера Managed Kubernetes.

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

  • Проверить текущую версию и ее совместимость с целевой версией.

    Перед тем как приступить к обновлению, важно определить текущую версию Kubernetes вашего кластера и убедиться, что ее обновление до желаемой версии поддерживается официальной политикой совместимости.

    Ознакомиться с информацией о допустимых обновлениях можно в разделе Version Skew Policy документации Kubernetes.

  • Оценить совместимость приложений и подов.

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

  • Оценить совместимость плагинов.

    Managed Kubernetes не обновляет плагины автоматически после обновления кластера до новой версии Kubernetes.

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

  • Сделать резервную копию кластера.

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

Порядок обновления

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

Основные шаги:

  1. Обновить плоскость управления.

  2. Обновить группы узлов в кластере.

  3. Обновить клиентские инструменты, такие как kubectl.

  4. Привести манифесты и другие ресурсы в соответствие с изменениями API в новой версии Kubernetes.

Подробнее читайте в Upgrade A Cluster документации Kubernetes.

Ограничения Managed Kubernetes

Обновление версии Kubernetes кластера Managed Kubernetes возможно только до следующей минорной версии. Например, с версии 1.26 можно обновиться только до версии 1.27. Это означает, что если вам нужно обновить несколько версий, то потребуется серия последовательных обновлений.

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

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

Политика обновления группы узлов

Для обновления групп узлов используется стратегия Rolling Update, которая позволяет минимизировать время простоя и риска для доступности приложений. Основными параметрами этой стратегии являются:

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

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

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

Параметры maxSurge и maxUnavailable можно указать при создании группы узлов в полях Расширение размера группы, макс., % и Уменьшение размера группы, макс., % соответственно.

Запустили Evolution free tier
для Dev & Test
Получить