#Обзор

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

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

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

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

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

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

• ClusterVersionShadow (cvsh): ресурс обновления, используемый для отслеживания текущей версии, целевой версии, результатов предварительных проверок, этапов выполнения и истории.
• Distribution Version: версия ACP, к которой в настоящее время достигнут кластер. Workload-кластер можно обновить только до той Distribution Version, которой глобальный уровень уже достиг.
• Preflight: проверки валидации, которые выполняются перед тем, как обновление начнет применять целевую версию. Для workload-кластеров просматривайте результаты preflight в выводе состояния обновления после отправки запроса на обновление.
• Доступные целевые версии обновления: версии обновления, которые в данный момент предлагаются для кластера. В Web Console целевая версия для текущего потока обновления определяется платформой.
• upgrade.sh: скрипт подготовки для обновления глобального кластера. Синхронизацию артефактов и предварительные проверки можно выполнить до окна обслуживания; Cluster Version Operator разворачивается внутри окна, непосредственно перед отправкой запроса на обновление.
• Глобальная среда DR: среда, в которой есть и основной, и резервный глобальный кластер.
• Основной глобальный кластер: глобальный кластер, на который в данный момент разрешается домен доступа платформы.
• Резервный глобальный кластер: другой глобальный кластер в паре DR. После failover роли двух кластеров меняются местами.

#Область обновления и последовательность

Полное обновление ACP выполняется поэтапно. Каждый кластер обновляется в одном окне обслуживания, но платформа переносится кластер за кластером: сначала глобальный уровень, затем workload-кластеры.

Одно окно обновления кластера охватывает четыре вида работ:

Несколько правил определяют, когда обновляется каждый компонент:

• Платформа требует, чтобы версия Kubernetes кластера обновлялась одновременно с его версиями Core и Aligned; сочетание нового выпуска Core со старой minor-версией Kubernetes не валидируется.
• Плагины кластера являются глобальными ресурсами. Отправка плагина кластера на глобальный уровень делает его доступным для установки и обновления на каждом кластере платформы; один и тот же плагин кластера не нужно отправлять повторно для каждого workload-кластера.
• Операторы имеют область действия на каждый кластер. Отправка операторов на глобальный уровень рекомендуется, но сама по себе недостаточна; один и тот же оператор должен быть доступен на каждом workload-кластере до обновления workload-кластера. Если вы забыли отправить оператор во время глобального окна, его можно отправить повторно перед обновлением workload-кластера в качестве запасного варианта.
• Обновления workload-кластеров требуются только тогда, когда workload-кластер выходит за пределы матрицы поддержки Kubernetes целевого релиза ACP. Workload-кластеры, которые остаются в поддерживаемом диапазоне, могут сохранить существующую версию Kubernetes после того, как глобальный уровень будет обновлен; платформа продолжит управлять ими.

#Сфера управления CVO

Cluster Version Operator (CVO) определяет, какие типы обновлений он выполняет end to end:

Клиенты, выполняющие реальные окна обслуживания в production, обычно обновляют Core, Aligned и используемые независимые плагины одновременно. Ниже описаны страницы обновления для этого пути: подготовьте все необходимые артефакты во время предобновления, выполните обновление Core и Aligned через CVO и завершите обновление используемых независимых плагинов из Marketplace.

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

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

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

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

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

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

• Предобновление
• Обновление глобального кластера
• Обновление workload-кластеров
• Глобальное аварийное восстановление кластера