Alauda Container Platform
  • Русский

    • Обзор

    ACP 4.3 использует рабочий процесс на основе Cluster Version Operator (CVO) для обновления кластера.

    В Web Console запрос на обновление теперь выполняется в два этапа: сначала выполняется просмотр элементов RPCH, а затем запрос на обновление отправляется на отдельном шаге подтверждения.

    При переносе платформы на новую версию ACP Distribution Version обновление обычно выполняется в два этапа:

    1. Обновите глобальный tier до целевой версии Distribution Version, следуя проверенной процедуре для глобального кластера, включая подготовку артефактов и предварительные проверки.
    2. После того как глобальный tier достигнет целевой версии Distribution Version, обновите workload clusters из поддерживаемой точки входа для workload-cluster и отслеживайте состояние кластера, пока каждый целевой кластер не достигнет той же версии Distribution Version.

    Workload cluster можно обновить только до той версии Distribution Version, которую глобальный tier уже достиг. В средах с global disaster recovery (DR) это означает, что и резервный, и основной глобальные кластеры должны достичь целевой версии Distribution Version, прежде чем workload clusters будут обновлены до этой версии Distribution Version. Это правило последовательности не отменяет предварительное условие Compatible Versions: до обновления глобального tier до ACP 4.3 workload clusters должны оставаться в диапазоне версий Kubernetes, совместимых с ACP 4.3.

    Содержание

    Ключевые понятияТочки входа для обновленияУсиление безопасности после обновленияСвязанная документация

    Ключевые понятия

    • ClusterVersionShadow (cvsh): ресурс обновления, используемый для отслеживания текущей версии, целевой версии, результатов предварительных проверок, этапов выполнения и истории.
    • Distribution Version: версия ACP, которую в данный момент достиг кластер. Workload cluster можно обновить только до той версии Distribution Version, которую глобальный tier уже достиг.
    • Preflight: проверки валидации, которые выполняются перед тем, как обновление начнет применять целевую версию. Для workload clusters просматривайте результаты preflight в выводе статуса обновления после отправки запроса на обновление.
    • Available upgrade targets: версии обновления, которые в данный момент доступны для кластера. В Web Console целевая версия для текущего потока обновления определяется платформой.
    • upgrade.sh: скрипт подготовки, который загружает артефакты и развертывает или обновляет cluster version operator перед продолжением обновления.
    • Global DR environment: среда, в которой есть и основной глобальный кластер, и резервный глобальный кластер.
    • Primary global cluster: глобальный кластер, на который в данный момент указывает домен доступа платформы.
    • Standby global cluster: второй глобальный кластер в паре DR. После failover роли двух кластеров меняются местами.

    Точки входа для обновления

    • Global clusters: следуйте проверенной процедуре на основе upgrade.sh. После завершения этапа подготовки запросите обновление в Web Console через двухэтапный поток проверки RPCH, используйте ACP CLI или обновите ClusterVersionShadow.spec.desiredUpdate напрямую.
    • Workload clusters: используйте Web Console через двухэтапный поток проверки RPCH или ACP CLI после того, как целевая версия Distribution Version станет доступна для workload cluster.

    Усиление безопасности после обновления

    После того как глобальный кластер и все workload clusters достигнут ACP 4.3, выполните усиление безопасности PKCE, следуя инструкции Отключение метода PKCE Plain Method.

    После того как глобальный кластер достигнет ACP 4.3, выполните требуемые обновления совместимости плагинов L5 в разделе Обновление глобального кластера.

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