• Русский
  • Обновление глобального кластера

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

    В этом документе описана процедура обновления глобального кластера.

    Если глобальный кластер настроен с решением global DR (Disaster Recovery), строго следуйте процедуре global DR. В противном случае следуйте Стандартной процедуре.

    Содержание

    Стандартная процедура

    WARNING

    Если вы обновляетесь с версии 3.16.x или 3.18.x и у вас установлены Application Services, пожалуйста, ознакомьтесь с руководством по обновлению Application Services для выполнения дополнительных шагов перед обновлением глобального кластера.

    Загрузка образов

    Скопируйте основной пакет на любой узел управляющей плоскости глобального кластера. Распакуйте пакет и перейдите в распакованную директорию.

    • Если глобальный кластер использует встроенный реестр, выполните:

      bash upgrade.sh --only-sync-image=true
    • Если глобальный кластер использует внешний реестр, необходимо также указать адрес реестра:

      bash upgrade.sh --only-sync-image=true --registry <registry-address> --username <username> --password <password>

    Если вы планируете обновлять Operator и Cluster Plugin вместе с обновлением глобального кластера, вы можете заранее загрузить их образы в реестр глобального кластера. Инструкции по массовой загрузке см. в разделе Только загрузка образов из всех пакетов в директории.

    ИНФОРМАЦИЯ

    Загрузка образов обычно занимает около 2 часов, в зависимости от вашей сети и производительности диска.

    Если ваша платформа настроена для глобального аварийного восстановления (DR), помните, что резервный глобальный кластер также требует загрузки образов. Планируйте окно обслуживания соответственно.

    WARNING

    При использовании violet для загрузки пакетов в резервный кластер необходимо указать параметр --dest-repo <VIP адрес резервного кластера>.
    В противном случае пакеты будут загружены в репозиторий образов основного кластера, что помешает резервному кластеру устанавливать или обновлять расширения.

    Также обратите внимание, что необходимо предоставить либо данные аутентификации реестра образов резервного кластера, либо параметр --no-auth.

    Для подробностей по подкоманде violet push смотрите Загрузка пакетов.

    Запуск обновления

    После завершения загрузки образов выполните следующую команду для запуска процесса обновления:

    bash upgrade.sh --skip-sync-image

    Дождитесь завершения скрипта перед продолжением.

    Если вы заранее загрузили образы Operator и Cluster Plugin в реестр глобального кластера, затем можете выполнить Создание только CR из всех пакетов в директории. После выполнения команды подождите около 10–15 минут, пока не появятся уведомления об обновлении функциональных компонентов. После этого вы сможете обновить Operator и Cluster Plugin вместе на следующих шагах обновления.

    WARNING

    При обновлении глобального кластера не используйте параметр --clusters для создания CR в кластерах рабочих нагрузок на шаге Создание только CR из всех пакетов в директории.

    Это может привести к сбоям обновления при последующем обновлении кластеров рабочих нагрузок.

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

    ПРЕДУПРЕЖДЕНИЕ

    Если вы обновляетесь с версий 3.16 или 3.18 и на платформе установлены Data Services, необходимо также обновить соответствующие расширения при обновлении кластеров.

    Подробнее см. Обновление Data Services.

    1. Войдите в Web Console глобального кластера и переключитесь в режим Administrator.
    2. Перейдите в раздел Clusters > Clusters.
    3. Нажмите на кластер global для открытия его подробного просмотра.
    4. Перейдите на вкладку Functional Components.
    5. Нажмите кнопку Upgrade.

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

    ИНФОРМАЦИЯ
    • Обновление версии Kubernetes является необязательным. Однако, поскольку возможны перебои в работе сервисов в любом случае, рекомендуется включить обновление Kubernetes, чтобы избежать нескольких окон обслуживания.
    • Если в глобальном кластере установлен плагин Alauda Container Platform GitOps и после обновления его поды работают некорректно, обратитесь к Обновлению Alauda Container Platform GitOps.

    Установка плагина Product Docs

    INFO

    Плагин Alauda Container Platform Product Docs предоставляет доступ к документации продукта внутри платформы. Все ссылки на справку в платформе будут вести к этой документации. Если плагин не установлен, при нажатии на ссылки справки в платформе будет возникать ошибка 404.

    Начиная с версии 4.0 встроенная документация продукта выделена в отдельный плагин Alauda Container Platform Product Docs. Если вы обновляетесь с версии 3.x, необходимо установить этот плагин, выполнив следующие шаги:

    1. Перейдите в раздел Administrator.

    2. В левой боковой панели выберите Marketplace > Cluster Plugins и выберите кластер global.

    3. Найдите плагин Alauda Container Platform Product Docs и нажмите Install.

    (Опционально) Установка Service Mesh Essentials

    Если установлен Service Mesh v1, ознакомьтесь с документацией Alauda Service Mesh Essentials Cluster Plugin перед обновлением кластеров рабочих нагрузок.

    После обновления

    Процедура global DR

    Проверка согласованности данных

    Следуйте вашим стандартным процедурам проверки global DR, чтобы убедиться, что данные в резервном глобальном кластере согласованы с основным глобальным кластером.

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

    На обоих кластерах выполните следующую команду, чтобы убедиться, что нет узлов Machine в состоянии, отличном от запущенного:

    kubectl get machines.platform.tkestack.io

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

    Удаление плагина синхронизации etcd

    Обновление с 3.16
    Обновление с 3.18
    Обновление с 4.0

    Войдите на любой узел управляющей плоскости основного глобального кластера и выполните:

    helm3 del etcd-sync -n default 2> /dev/null
    helm3 del etcd-sync -n cpaas-system 2> /dev/null
    
    kubectl delete configmaps,secret -n kube-system   etcd-master-mirror-cert etcd-slave-mirror-cert etcd-sync-env   etcd-sync-ignore-text &> /dev/null
    
    kubectl delete deploy -n kube-system etcd-mirror-etcd-mirror &> /dev/null
    
    kubectl get pod -n kube-system | grep etcd-mirror  # Убедитесь, что поды etcd-mirror отсутствуют

    Загрузка образов

    Выполните шаг Загрузка образов на обоих кластерах — резервном и основном.

    Подробности см. в разделе Загрузка образов в Стандартной процедуре.

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

    ИНФОРМАЦИЯ

    Для выполнения обновления требуется доступ к Web Console резервного кластера.

    Перед продолжением проверьте, что ресурс ProductBase резервного кластера корректно настроен с VIP кластера в поле spec.alternativeURLs.

    Если нет, обновите конфигурацию следующим образом:

    apiVersion: product.alauda.io/v1alpha2
    kind: ProductBase
    metadata:
      name: base
    spec:
      alternativeURLs:
        - https://<standby-cluster-vip>

    На резервном кластере выполните шаги из Стандартной процедуры для завершения обновления.

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

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

    Переустановка плагина синхронизации etcd

    Перед переустановкой убедитесь, что порт 2379 корректно проброшен с обоих VIP глобального кластера на их узлы управляющей плоскости.

    Для переустановки:

    1. Зайдите в Web Console резервного глобального кластера по его IP или VIP.
    2. Переключитесь в режим Administrator.
    3. Перейдите в Marketplace > Cluster Plugins.
    4. Выберите кластер global.
    5. Найдите Alauda Container Platform etcd Synchronizer, нажмите Install и укажите необходимые параметры.

    Для проверки установки выполните:

    kubectl get po -n cpaas-system -l app=etcd-sync  # Убедитесь, что под в состоянии 1/1 Running
    
    kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | awk '{print $1}' | head -1) | grep -i "Start Sync update"
    # Дождитесь появления в логах строки "Start Sync update"
    
    # Пересоздайте под, чтобы инициировать синхронизацию ресурсов с ownerReferences
    kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | awk '{print $1}' | head -1)

    Проверка статуса синхронизации

    Выполните следующую команду для проверки статуса синхронизации:

    curl "$(kubectl get svc -n cpaas-system etcd-sync-monitor -ojsonpath='{.spec.clusterIP}')/check"

    Объяснение вывода:

    • "LOCAL ETCD missed keys:" – Ключи есть в основном кластере, но отсутствуют в резервном. Обычно решается после перезапуска пода.
    • "LOCAL ETCD surplus keys:" – Ключи есть в резервном кластере, но отсутствуют в основном. Перед удалением обсудите с вашей операционной командой.