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

#Синхронизация артефактов обновления

Когда: в любое время до окна обслуживания. Этот шаг загружает артефакты в registry и не изменяет состояние кластера.

Из каталога с распакованным core package выполните upgrade.sh в режиме только синхронизации:

bash upgrade.sh --only-sync-image

--only-sync-image загружает образы и артефакты плагинов без развёртывания cluster version operator. CVO будет развёрнут позже, уже в окне обслуживания — см. Развёртывание cluster version operator.

upgrade.sh синхронизирует артефакты, необходимые для workflow на базе CVO, включая:

upgrade.sh охватывает Core . Плагины Aligned и Agnostic не отправляются upgrade.sh; отправьте их с помощью violet до запроса на обновление, используя пакеты, загруженные в Подготовке перед обновлением.

# Push Aligned plugins (cluster plugins) — global only
violet push <path/to/aligned-cluster-plugin-package> \
  --target-catalog-source "platform" \
  --platform-address "https://<your-platform-domain>" \
  --platform-token "<platform_token>"

# Push Aligned or Agnostic operators — to global, and to each workload cluster that runs the operator
violet push <path/to/operator-package> \
  --target-catalog-source "platform" \
  --platform-address "https://<your-platform-domain>" \
  --platform-token "<platform_token>" \
  --clusters "global,<workload-cluster-1>,<workload-cluster-2>"

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

Поведение registry зависит от конфигурации среды:

Когда целевой registry не является registry по умолчанию платформы, добавьте параметры registry:

Чтобы обойти проверку артефактов, когда известно, что она избыточна, добавьте --skip-check-artifacts.

#Выполнение предварительных проверок

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

Запустите upgrade.sh в режиме preflight:

bash upgrade.sh --preflight

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

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

Набор проверок по умолчанию включает:

• ResourcePatchUpgradeable
• ClusterVersionUpgradeable
• VersionUpgradePath
• KubernetesVersionSupported
• DockerRuntimeUnsupported
• ClusterRunning
• ClusterModuleStable
• ControlPlaneStaticPodsPresent
• CustomEtcdBackupCronJobsAbsent
• CRIUpgradePodsAbsent
• ModuleInfoStable
• PlatformLicense

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

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

Если ResourcePatchUpgradeable завершается с reason=UnexemptResourcePatches, проверьте блокирующий ResourcePatch и добавьте требуемую аннотацию исключения:

kubectl -n cpaas-system get cvsh global \
  -o jsonpath='{range .status.preflight.checks[?(@.name=="ResourcePatchUpgradeable")]}{.state}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'

kubectl get resourcepatches <rp-name> -o yaml

Ключ аннотации по умолчанию — config.cpaas.io/exempt-for-ver.

kubectl annotate resourcepatches <rp-name> \
  config.cpaas.io/exempt-for-ver=4.3.0 \
  --overwrite

Если для временной диагностики необходимо отключить определённые проверки, настройте cpaas-system/cvo-config:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cvo-config
  namespace: cpaas-system
data:
  preflight: |
    disabled:
      - ResourcePatchUpgradeable
      - VersionUpgradePath

#Развёртывание cluster version operator

Когда: в начале окна обслуживания.

Запустите upgrade.sh в режиме skip-sync. Синхронизация пропускается, поскольку артефакты уже были загружены на шаге Синхронизация артефактов обновления:

bash upgrade.sh --skip-sync-image

Это разворачивает или обновляет cluster version operator (CVO) и завершает оставшуюся подготовку. CVO управляет обновлением Core и плагинов Aligned после того, как обновление будет запрошено на следующем шаге.

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

После развёртывания cluster version operator запросите обновление через одну из следующих точек входа. Все три точки входа эквивалентны; выберите ту, которая соответствует вашей операционной модели.

# Request upgrade to the highest version currently published in availableUpdates
ac adm upgrade --cluster=global --to-latest

# Request upgrade to a specific target version
ac adm upgrade --cluster=global --to=4.3.0

# Show summary, preflight, and stage progress for the global cluster upgrade
ac adm upgrade status --cluster=global

kubectl patch cvsh global -n cpaas-system --type merge -p '{
  "spec": {
    "desiredUpdate": {
      "version": "4.3.0"
    }
  }
}'

kubectl edit cvsh global -n cpaas-system

spec:
  desiredUpdate:
    version: 4.3.0

#Наблюдение за выполнением

Используйте следующую команду, чтобы проверить общий статус:

kubectl get cvsh -n cpaas-system

Важные поля статуса:

Сначала обратите внимание на следующие условия:

Полезная диагностика:

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

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

#(Условно) Обновление Service Mesh Essentials

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

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

CVO управляет Core и плагинами Aligned. Agnostic-плагины не входят в область действия CVO и должны обновляться по отдельности после того, как кластер достигнет целевой версии Distribution Version. Нужно ли обновлять каждый Agnostic-плагин, зависит от его собственной совместимости с Kubernetes — см. release notes плагина на предмет совместимости с целевой версией Kubernetes.

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

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

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

#Проверьте среду DR перед обновлением

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

Если обнаружены несоответствия, не удаляйте плагин синхронизации etcd на следующем шаге и перед продолжением обратитесь в техническую поддержку. Удаление плагина, когда в резервном глобальном кластере отсутствуют данные, которые есть в основном, может привести к некорректному разрешению owner references, а объекты Machine узлов кластера рабочих нагрузок — включая кластеры на immutable OS, где это приведёт к уничтожению базовой виртуальной машины — могут быть удалены.

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

kubectl get machines.platform.tkestack.io

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

#Удалите плагин синхронизации etcd с резервного глобального кластера

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

#Синхронизируйте артефакты обновления на обоих глобальных кластерах

Выполните Синхронизацию артефактов обновления из стандартного workflow на обоих кластерах: и на резервном, и на основном.

Используйте один и тот же режим синхронизации на обоих кластерах.

#Обновите резервный глобальный кластер

Если вы будете использовать Web Console на резервном глобальном кластере, убедитесь, что ProductBase резервного кластера включает резервный VIP в spec.alternativeURLs:

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

После завершения синхронизации выполните оставшиеся шаги из стандартного workflow на резервном глобальном кластере:

1. Выполните предварительные проверки
2. Разверните cluster version operator
3. Запросите обновление
4. Наблюдайте за выполнением до тех пор, пока резервный глобальный кластер не достигнет целевой версии

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

После того как резервный глобальный кластер достигнет целевой версии, выполните оставшиеся шаги из стандартного workflow на основном глобальном кластере:

1. Выполните предварительные проверки
2. Разверните cluster version operator
3. Запросите обновление
4. Наблюдайте за выполнением до тех пор, пока основной глобальный кластер не достигнет целевой версии

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

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

Чтобы переустановить плагин:

kubectl get job -n cpaas-system etcd-sync-bootstrap
kubectl logs -n cpaas-system job/etcd-sync-bootstrap
kubectl get secret -n cpaas-system remote-etcd-ca
kubectl get issuer -n cpaas-system remote-etcd-issuer
kubectl get certificate -n cpaas-system remote-etcd-client
kubectl get secret -n cpaas-system remote-etcd-client

Дождитесь, пока kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}' вернёт непустое значение, прежде чем продолжать.

Проверьте, что sync Pods запущены на резервном глобальном кластере, и определите текущий leader:

kubectl get po -n cpaas-system -l app=etcd-sync
kubectl get lease -n cpaas-system etcd-sync-mirror
leader_pod=$(kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}')
kubectl logs -n cpaas-system "$leader_pod" | grep -E "Acquired leader lease|Start Sync update"

Если ресурсы с зависимостями ownerReference нужно пересинхронизировать, пересоздайте текущий Pod leader после появления Start Sync update:

leader_pod=$(kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}')
kubectl delete po -n cpaas-system "$leader_pod"

Проверьте состояние синхронизации:

mirror_svc=$(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')
ipv6_regex="^[0-9a-fA-F:]+$"
if [[ $mirror_svc =~ $ipv6_regex ]]; then
  mirror_host="[$mirror_svc]"
else
  mirror_host="$mirror_svc"
fi
curl -g "http://${mirror_host}/check"

Интерпретация вывода:

• LOCAL ETCD missed keys: ключи существуют в основном глобальном кластере, но отсутствуют в резервном. Часто это устраняется после перезапуска текущего Pod leader etcd-sync.
• LOCAL ETCD surplus keys: ключи существуют в резервном глобальном кластере, но отсутствуют в основном. Перед удалением обсудите их с вашей операционной командой.