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

#Подготовьте артефакты обновления

Выполните bash upgrade.sh из каталога извлеченного core package.

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

Поведение registry зависит от того, как настроена среда:

Общие параметры:

bash upgrade.sh

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

Выполните preflight перед запросом на обновление:

bash upgrade.sh --preflight

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

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

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

#При необходимости обработайте блокировки 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

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

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

• Используйте Web Console после того, как целевая версия станет доступна для кластера.
• Непосредственно измените ClusterVersionShadow.spec.desiredUpdate, если необходимо работать с базовым ресурсом CVO.
• Используйте ACP CLI, чтобы явно запросить обновление для global.

Если вы используете Web Console, запрос выполняется в два шага:

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

Пример kubectl:

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

Пример ACP CLI:

# Запросить обновление до самой высокой версии, которая сейчас опубликована в availableUpdates
ac adm upgrade --cluster=global --to-latest

# Запросить обновление до конкретной целевой версии
ac adm upgrade --cluster=global --to=4.3.0

# Показать summary, preflight и ход выполнения этапов для обновления global-кластера
ac adm upgrade status --cluster=global

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

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

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 Cluster Plugin.

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

Выполните обычные процедуры проверки global DR, чтобы убедиться, что данные в резервном global-кластере согласованы с основным global-кластером. Дополнительную информацию о топологии DR и рабочем процессе синхронизации см. в Disaster Recovery для глобального кластера.

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

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

kubectl get machines.platform.tkestack.io

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

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

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

#Подготовьте артефакты обновления на обоих global-кластерах

Выполните пункт Подготовьте артефакты обновления из стандартного рабочего процесса на резервном global-кластере и основном global-кластере.

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

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

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

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

После завершения подготовки выполните оставшиеся шаги стандартного рабочего процесса на резервном global-кластере:

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

#Обновите основной global-кластер

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

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

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

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

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

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

При настройке плагина:

• Если порт 2379 не перенаправляется через load balancer, правильно задайте Active Global Cluster ETCD Endpoints.
• Используйте значение по умолчанию для Data Check Interval.
• Оставьте Print detail logs отключенным, если только вы не выполняете устранение неполадок.

Убедитесь, что sync Pod запущен на резервном global-кластере:

kubectl get po -n cpaas-system -l app=etcd-sync
etcd_sync_pod=$(kubectl get po -n cpaas-system -l app=etcd-sync -o jsonpath='{.items[0].metadata.name}')
kubectl logs -n cpaas-system "$etcd_sync_pod" | grep -i "Start Sync update"

После появления Start Sync update пересоздайте один из Pod, чтобы запустить синхронизацию ресурсов с зависимостями ownerReference:

etcd_sync_pod=$(kubectl get po -n cpaas-system -l app=etcd-sync -o jsonpath='{.items[0].metadata.name}')
kubectl delete po -n cpaas-system "$etcd_sync_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: ключи существуют в основном global-кластере, но отсутствуют в резервном. Это часто решается после перезапуска одного Pod etcd-sync.
• LOCAL ETCD surplus keys: ключи существуют в резервном global-кластере, но отсутствуют в основном. Перед удалением обсудите их с вашей операционной командой.