Обновление кластера

Кластеры CCE развиваются итеративно на основе версии Kubernetes сообщества. Версия кластера CCE состоит из версии Kubernetes сообщества и патч‑версии CCE. Поэтому предоставляются два пути обновления кластера.

• Обновление версии Kubernetes

  Исходная версия Kubernetes	Целевая версия Kubernetes
  v1.13 or earlier	Не поддерживается
  v1.15	v1.19
  v1.17	v1.19
  v1.19	v1.21 or v1.23
  v1.21	v1.23
  v1.23	v1.25, v1.27, or v1.28
  v1.25	v1.27 or v1.28
  v1.27	v1.28
  v1.28	v1.29 or v1.31
  v1.29	v1.30 or v1.31
  v1.30	v1.31
  v1.31	v1.32 or v1.34
  v1.32	v1.33 or v1.34
  v1.33	v1.34
  v1.34	v1.35

  Note

  • Версия, для которой завершено обслуживание, не может быть напрямую обновлена до последней версии. Необходимо обновлять такую версию несколько раз, например, от v1.15 до v1.19, v1.23, а затем до v1.27/v1.28.
  • Версию Kubernetes можно обновить только после того, как патч будет обновлен до последней версии. CCE автоматически сгенерирует оптимальный путь обновления в console на основе текущей версии кластера.
• Обновление версии патча

  Управление версиями Патч доступно для CCE clusters v1.19 и новее, чтобы предоставить новые функции и исправить ошибки и уязвимости в обслуживаемых кластерах без необходимости крупного обновления версии.

  После выпуска новой версии патча вы можете напрямую обновить любую версию патча до последней версии патча. Подробную информацию об истории выпусков версий патчей см. в CCE Patch Release Notes.

cluster upgrade process включает проверку перед обновлением, резервное копирование, обновление и проверку после обновления.

После определения целевой версии кластера внимательно прочитайте precautions и предотвратите функциональную несовместимость во время обновления.

1. Проверка перед обновлением

   Перед обновлением кластера CCE проверяет обязательные элементы, такие как статус кластера, дополнения, совместимость рабочих нагрузок и узлы, чтобы убедиться, что кластер соответствует требованиям обновления. Подробнее см. Pre-upgrade Check. Если какой‑либо элемент проверки имеет отклонения, исправьте ошибку согласно подсказкам в консоли.

2. Резервное копирование

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

   Тип резервного копирования	Объект резервного копирования	Режим резервного копирования	Продолжительность резервного копирования	Продолжительность отката	Описание
   бэкап данных etcd	данные etcd	Автоматический бэкап во время обновления	1-5 minutes	2 hours	Обязательно. Данные автоматически бэкапятся во время обновления.
   CBR cloud server backup	Диски главного узла, включая образы компонентов, конфигурации, журналы и данные etcd	Однокнопочный бэкап на веб‑странице (вручную инициировано)	От 20 минут до 2 часов (в зависимости от задач бэкапа в текущем регионе)	20 минут	Эта функция постепенно заменяется EVS snapshot backup.
   EVS snapshot backup	Диски главного узла, включая образы компонентов, конфигурации, журналы и данные etcd	One-click backup на веб-странице (вручную запущено)	1-5 минут	20 минут	Эта функция скоро появится. После выпуска этой функции она заменит CBR cloud server backup.

3. Конфигурация и обновление

   Настройте параметры перед обновлением. CCE предоставил настройки по умолчанию, которые можно изменить по мере необходимости. После конфигурации обновите add-ons, master nodes и worker nodes последовательно.

   • Add-on Upgrade Configuration: В вашем кластере перечислены установленные Add-ons. Во время обновления кластера CCE автоматически обновляет выбранные add-ons, чтобы они были совместимы с целевой версией кластера. Вы можете нажать Set, чтобы переопределить параметры add-on.
     Note

     Если add-on помечен справа, add-on не может быть совместим как с исходной, так и с целевой версиями обновления кластера. В этом случае CCE обновит add-on после обновления кластера. Add-on может быть недоступен во время обновления кластера.

   • Node Upgrade Configuration
     • Max. Nodes for Batch Upgrade: Вы можете настроить максимальное количество узлов, которые будут обновлены за одну партию.

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

     • Node Priority: Вы можете настроить приоритеты обновления узлов. Если приоритеты не указаны, CCE выполнит обновление на основе приоритетов, сформированных по умолчанию.
       • Add Upgrade Priority: Вы можете задать приоритеты обновления пулов узлов. Если приоритеты не указаны, CCE будет предпочитать обновлять пул узлов с наименьшим количеством узлов согласно политике по умолчанию.
       • Add Node Priority: Вы можете задать приоритеты обновления узлов в пуле узлов. Если приоритеты не указаны, CCE будет предпочитать обновлять узел с наименьшей нагрузкой (рассчитывается на основе количества pods, уровня запросов ресурсов и количества PV) согласно политике по умолчанию.
     • Scope of Node Upgrade Batches: Параметр пакетного обновления узлов может применяться ко всему кластеру или к отдельным пулам узлов. Вы можете выбрать любой вариант. По умолчанию применяется ко всему кластеру.
       • При применении ко всему кластеру все узлы в кластере обновляются пакетами, независимо от их групп пулов узлов. Например, если в первом пакете обновляется один узел, а во втором — четыре узла, количество узлов, обновляемых в каждом последующем пакете, будет увеличиваться в четыре раза, пока не достигнет максимально разрешённого количества узлов в пакете.
       • При применении к конкретным пулам узлов узлы в каждом пуле обновляются пакетами согласно предопределённой последовательности. Обновление начинается с одного узла в первом пакете, затем четыре узла во втором пакете. Количество узлов в каждом последующем пакете увеличивается в четыре раза, пока не будет достигнуто максимальное количество узлов в пакете. При переходе процесса обновления к следующему пулу узлов расчёт размера пакета сбрасывается и начинается снова с одного узла.
   • Cluster Certificate Settings
     • Rotate CCE Cluster Certificate: Вы можете выбрать, вращать ли сертификат кластера CCE во время обновления кластера в зависимости от оставшегося срока действия этих сертификатов. При успешном вращении сертификаты действительны в течение пяти лет.
       Caution

       Если OIDC Provider включён (проверьте статус в Connection Information на странице Cluster Overview), вам необходимо получить открытый ключ подписи кластера после обновления. Если этого не сделать, аутентификация OIDC будет недействительна.

     • Rotate Self-Managed Certificate: Если вы предоставили самоуправляемый сертификат при создании кластера, вы можете выбрать, вращать ли его во время обновления. Чтобы завершить вращение, загрузите корневой сертификат CA, клиентский сертификат и закрытый ключ клиента согласно подсказке.
4. Post-upgrade verification

   После обновления CCE автоматически проверит такие элементы, как статус кластера и статус узлов. Вам необходимо вручную проверить сервисы, новые узлы и новые pod‑ы, чтобы убедиться, что кластер функционирует корректно после обновления. Подробности см. в Performing Post-Upgrade Verification.

• Подробности о том, как обновлять ОС узлов, см. Upgrading an OS.