Alauda Container Platform
  • Русский

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

    Путь обновления

    На этой странице описан путь с традиционной операционной системой для кластеров рабочей нагрузки. Для кластеров рабочей нагрузки, работающих на Immutable Infrastructure (Alauda OS on Huawei DCS, VMware vSphere или Huawei Cloud Stack), шаг Kubernetes находится в документации по immutable infrastructure — см. Обновление кластеров в Immutable Infrastructure. Шаги Core, Aligned и Agnostic, описанные на этой странице, по-прежнему применимы к кластерам на immutable-OS; отличается только способ развертывания Kubernetes.

    MySQL-PXC удалён в Alauda Database Service for MySQL v4.3.0

    MySQL-PXC удалён начиная с Alauda Database Service for MySQL v4.3.0. Существующие экземпляры PXC больше не будут управляться MySQL operator после обновления до ACP v4.3.0 или более поздней версии. См. Руководство по обновлению MySQL Operator для получения инструкций по миграции перед обновлением.

    Кластеры рабочей нагрузки можно обновлять после того, как глобальный уровень уже достиг целевой версии дистрибутива ACP. Глобальный уровень не нужно обновлять повторно, если он уже находится на этой версии дистрибутива.

    ACP 4.3 использует тот же рабочий процесс на основе CVO для кластеров рабочей нагрузки, что и для кластера global: подтвердите предварительные требования, выполните preflight-проверки, отправьте запрос на обновление и наблюдайте за его выполнением. У этого рабочего процесса есть два дополнительных правила:

    • Если платформа использует global DR, и резервный, и основной глобальные кластеры должны достичь целевой версии дистрибутива до того, как любой кластер рабочей нагрузки будет обновлён до этой версии.
    • Целевая версия обычно становится доступной для кластера рабочей нагрузки только после того, как глобальный уровень уже достиг той же версии дистрибутива.

    Обновление кластера рабочей нагрузки выполняется по той же схеме, что и обновление глобального кластера, но занимает меньше времени. У кластера рабочей нагрузки нет собственного cluster version operator — CVO работает на глобальном кластере и централизованно управляет обновлениями рабочих нагрузок — поэтому у кластера рабочей нагрузки нет собственного шага синхронизации артефактов или развертывания CVO:

    ФазаКогдаЧто происходит
    1. PreflightЗа 1–2 недели до окнаПодтвердите предварительные требования и выполните upgrade.sh --cluster=<cluster> --preflight; устраните все блокирующие проблемы до открытия окна.
    2. ОбновлениеВо время окна обслуживанияОтправьте запрос на обновление и наблюдайте за его выполнением, пока кластер не достигнет целевой версии.

    Содержание

    Рабочий процессПосле того как все кластеры рабочей нагрузки достигнут ACP 4.3Связанная документация

    Рабочий процесс

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

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

    • Версия кластера рабочей нагрузки ниже текущей версии кластера global.
    • Глобальный уровень уже достиг целевой версии дистрибутива ACP.
    • В средах global DR оба глобальных кластера — резервный и основной — уже достигли этой целевой версии дистрибутива.

    Запасной вариант для push операторов

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

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

    Если в глобальном окне пакеты операторов не были отправлены в этот кластер рабочей нагрузки — например, кластер был недоступен во время глобального окна или был добавлен позже — отправьте каждый используемый пакет оператора в этот кластер рабочей нагрузки до отправки запроса на обновление:

    violet push <path/to/operator-package> \
  --target-catalog-source "platform" \
  --platform-address "https://<your-platform-domain>" \
  --platform-token "<platform_token>" \
  --clusters "<workload-cluster-name>"

    Нужно выполнять push только для пакетов операторов тех операторов, которые действительно запущены на кластере рабочей нагрузки. Пакеты плагинов Aligned, которые по-прежнему находятся на стороне global, автоматически подхватываются CVO во время обновления кластера рабочей нагрузки.

    Выполните preflight-проверки

    Когда: за 1–2 недели до окна обслуживания, чтобы было время устранить все блокирующие проблемы до открытия окна.

    Запустите upgrade.sh в режиме preflight для целевого кластера:

    bash upgrade.sh --cluster=<cluster> --preflight

    Preflight работает только на чтение — он проверяет готовность к обновлению и не изменяет состояние кластера.

    Preflight возвращает две части:

    ВыводНазначение
    SummaryПоказывает общий результат, текущую версию, желаемую версию и желаемый образ.
    ChecksПоказывает результат каждой отдельной проверки.

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

    О шаблонах обработки блокировок preflight см. Обработка блокировок preflight при необходимости.

    Запросите обновление

    Когда: во время окна обслуживания, после успешного прохождения preflight.

    Запросите обновление через один из следующих входных путей. Оба варианта эквивалентны; выберите тот, который соответствует вашей модели эксплуатации.

    Веб-консоль
    ACP CLI

    Начните обновление из кластера рабочей нагрузки в Web Console. Запрос выполняется в два шага:

    • На Шаге 1 проверьте список RPCH.
    • Нажмите Acknowledge, чтобы перейти к Шагу 2.
    • На Шаге 2 проверьте Current Version и Target Version. На этом этапе на странице не отображаются список плагинов или панель предупреждения.
    • Целевая версия — это текущая версия кластера global, и её нельзя выбрать вручную в Web Console.
    • Нажмите Start Upgrade.
    • После отправки запроса на странице отобразится, что запрос на обновление отправлен, и действие перейдёт в состояние выполнения.

    Отслеживайте ход выполнения

    После отправки запроса на обновление используйте cvsh.status, чтобы отслеживать текущую версию, целевую версию, результаты preflight, этапы и историю:

    kubectl get cvsh <cluster> -n cpaas-system
kubectl get cvsh <cluster> -n cpaas-system -o yaml

    Если текущий контекст ACP указывает на целевой кластер рабочей нагрузки, вы также можете проверить статус, возвращаемый CLI:

    # Show summary, preflight, and stage progress for the target cluster upgrade
ac adm upgrade status

    Подробная семантика вывода ac adm upgrade status (интерпретация preflight и этапов) описана в Обновление кластеров.

    Обновите Agnostic-плагины из Marketplace

    CVO управляет плагинами Core и Aligned. Agnostic-плагины находятся вне области ответственности CVO и должны обновляться по отдельности после того, как этот кластер рабочей нагрузки достиг целевой версии дистрибутива.

    Для каждого используемого Agnostic-плагина на этом кластере рабочей нагрузки:

    1. В Web Console переключитесь в представление Administrator.
    2. Перейдите в Marketplace > Cluster Plugins для Agnostic-плагинов кластера или в рабочий процесс оператора для Agnostic-операторов.
    3. Выберите целевой плагин или оператор и запустите обновление.

    Необходимость обновления каждого Agnostic-плагина в этом окне зависит от его совместимости с Kubernetes — см. примечания к выпуску плагина на предмет совместимости с новой версией Kubernetes, которую достиг кластер рабочей нагрузки.

    Если Marketplace не предлагает целевую версию оператора на этом кластере рабочей нагрузки, сначала выполните для этого оператора Запасной вариант для push операторов, а затем повторите обновление через Marketplace.

    При устранении неполадок сначала проверьте состояния, подробности preflight и историю:

    kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'

kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{.status.preflight.observedAt}{"\n"}{range .status.preflight.checks[*]}{.name}{"\t"}{.policy}{"\t"}{.state}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'

kubectl -n cpaas-system get cvsh <cluster> \
  -o jsonpath='{range .status.history[*]}{.version}{"\t"}{.state}{"\t"}{.startedTime}{"\t"}{.completionTime}{"\n"}{end}'

    После того как все кластеры рабочей нагрузки достигнут ACP 4.3

    После того как все кластеры рабочей нагрузки достигнут ACP 4.3, завершите усиление безопасности PKCE, выполнив Отключение простого метода PKCE.

    Связанная документация