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

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

• Обновление версии 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
  v1.35	v1.36

  Note

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

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

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

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

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

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

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

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

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

   Тип резервного копирования	Объект резервного копирования	Режим резервного копирования	Продолжительность Бэкапа	Продолжительность отката	Описание
   Бэкап данных etcd	данные etcd	Автоматический бэкап во время обновления	1-5 minutes	2 hours	Обязательно. Данные автоматически бэкапятся во время обновления.
   CBR cloud server backup	Диски мастер‑узла, включая образы компонентов, конфигурации, логи и данные etcd	Бэкап одним щелчком на веб‑странице (вручную инициированный)	От 20 minutes до 2 hours (based on the cloud backup tasks in the current region)	20 minutes	Эта функция постепенно заменяется EVS Снапшот бэкап.
   EVS Снапшот Бэкап	Диски master node, включая образы компонентов, конфигурации, логи и данные etcd	Однократный бэкап на веб‑странице (вручную инициированный)	1-5 minutes	20 minutes	Эта функция скоро появится. После выпуска этой функции она заменит CBR cloud server backup.

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

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

   • Add-on Upgrade Configuration: Add-ons that have been installed in your cluster are listed. During the cluster upgrade, CCE automatically upgrades the selected add-ons to be compatible with the target cluster version. You can click Set to re-define the add-on parameters.
     Note

     Если 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 будет предпочтительно обновлять узел с наименьшей нагрузкой (рассчитывается на основе количества pod‑ов, уровня запросов ресурсов и количества PV) в соответствии с политикой по умолчанию.
     • Scope of Node Upgrade Batches: Параметр пакетного обновления узлов может применяться ко всему кластеру или к отдельным пулам узлов. Вы можете выбрать любой вариант. По умолчанию он применяется ко всему кластеру.
       • При применении ко всему кластеру все узлы в кластере обновляются пакетами, независимо от их групп пулов узлов. Например, если в первом пакете обновляется один узел, а во втором — четыре узла, количество узлов, обновляемых в каждом последующем пакете, будет увеличиваться в четыре раза, пока не достигнет максимально допустимого количества узлов в пакете.
       • При применении к конкретным пулам узлов узлы в каждом пуле обновляются пакетами согласно предопределённой последовательности. Обновление начинается с одного узла в первом пакете, затем четыре узла во втором пакете. Количество узлов в каждом последующем пакете увеличивается в четыре раза, пока не будет достигнуто максимальное количество узлов в пакете. При переходе процесса обновления к следующему пулу узлов расчёт размера пакета сбрасывается и начинается снова с одного узла.
   • Настройки сертификата кластера
     • Rotate CCE Cluster Certificate: Вы можете выбрать, выполнять ли ротацию сертификата кластера CCE во время обновления кластера в зависимости от оставшегося срока действия сертификата. При успешной ротации сертификаты действительны в течение пяти лет.
       Caution

       Включение OpenID Connect (OIDC) для кластера аннулирует существующий публичный ключ подписи кластера. После обновления кластера необходимо получить новый ключ, иначе аутентификация OIDC завершится неудачей.

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

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

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