Alauda Container Platform
  • Русский

    • Подготовка к обновлению

    Поддерживаемые пути обновления:

    • С 4.0 → 4.3
    • С 4.1 → 4.3
    • С 4.2 → 4.3

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

    MySQL-PXC removed in Alauda Database Service for MySQL v4.3.0

    Если у вас есть экземпляры MySQL-PXC, после обновления до ACP v4.3.0 или более поздней версии они станут unmanaged (если также будет обновлен MySQL operator). См. Руководство по обновлению MySQL Operator для инструкций по миграции.

    INFO

    В инфраструктуре с неизменяемой ОС (Huawei DCS, VMware vSphere, Huawei Cloud Stack и bare-metal immutable OS) указанные выше поддерживаемые пути обновления относятся к ACP Distribution Version, которая по-прежнему обновляется напрямую до целевой версии через Cluster Version Operator. Когда целевая версия ACP более чем на одну minor-версию Kubernetes превышает текущую версию кластера, для обновления Kubernetes требуется дополнительная предварительная подготовка артефактов промежуточных версий. Перед началом окна обновления см. Подготовка к межверсионному обновлению.

    Содержание

    Важные примечанияЗагрузка пакетов для автономных средШаг 1: Загрузите пакет CoreШаг 2: Составьте инвентаризацию плагинов на каждом кластере в области действияШаг 3: Синхронизируйте список пакетов в Customer Portal

    Важные примечания

    • Убедитесь, что в каталоге /cpaas/minio на узлах control plane глобального кластера доступно не менее 120 GB свободного места на диске.
    • Перед обновлением global tier до ACP 4.3 все workload clusters должны оставаться в пределах Совместимых версий ACP 4.3, описанных в Матрица поддержки Kubernetes.
    • Если какой-либо workload cluster находится вне этого совместимого диапазона, сначала обновите этот workload cluster, пока он не войдет в совместимый диапазон ACP 4.3, и только после этого обновляйте global tier.
    • Workload cluster можно обновить только до версии дистрибутива, которой global tier уже достиг.

    Загрузка пакетов для автономных сред

    Окно планового обслуживания обычно обновляет Core , Aligned plugins (cluster plugins и operators, выпущенные вместе с той же версией ACP), а также используемые Agnostic plugins (независимо выпускаемые cluster plugins и operators) в рамках одного окна. Подготовьте каждый пакет, который текущий cluster использует, до начала обновления, даже если обновление Agnostic plugin технически необязательно. Если отложить Agnostic plugin на время этого окна, позже это часто приводит к необходимости второго окна обслуживания.

    Шаг 1: Загрузите пакет Core

    В Портале клиентов загрузите пакет Core . Пакет Core содержит только артефакты Core, которые upgrade.sh подготовит для обновления Core на основе CVO.

    Пакет Core не включает пакеты Aligned plugin, хотя CVO и знает, какие версии Aligned plugin соответствуют целевому релизу ACP. Пакеты Aligned plugin необходимо загрузить отдельно из Customer Portal и отправить с помощью violet; следующий шаг описывает этот процесс вместе с Agnostic plugins.

    Шаг 2: Составьте инвентаризацию плагинов на каждом кластере в области действия

    Cluster plugins и operators управляются разными механизмами. На этом шаге нужны оба:

    • Cluster plugins — это глобальные ресурсы. Cluster plugin, отправленный в global tier, становится доступным для установки и обновления на каждом cluster в платформе; каждый cluster plugin отправляется только один раз.
    • Operators привязаны к каждому cluster. Отправка operator в global tier — рекомендуемая отправная точка, однако тот же пакет operator должен быть доступен на каждом workload cluster до начала обновления этого cluster.

    Перейдите в раздел Инструменты CLI в Портале клиентов и загрузите инструмент violet. violet требуется для загрузки пакетов Aligned и Agnostic plugin. Дополнительные сведения о violet см. в Upload Packages.

    На любом компьютере с сетевым доступом к конечной точке платформы выполните violet list, чтобы вывести список плагинов (как Aligned, так и Agnostic), установленных в текущей среде, и экспортируйте результат в ./apps.yaml:

    violet list \
  --platform-address "https://<your-platform-domain>" \
  --platform-token "<platform_token>" \
  --output-file "./apps.yaml"

    Предпочтительно использовать --platform-token вместо --platform-password, чтобы не раскрывать пароли в истории shell и в списках процессов (ps aux).

    Шаг 3: Синхронизируйте список пакетов в Customer Portal

    Импортируйте экспортированный файл apps.yaml в Портал клиентов , чтобы согласовать список пакетов с тем, что фактически используется на ваших кластерах. После этого портал предоставит для загрузки соответствующие пакеты целевой версии — Core, Aligned plugins и используемые вашими кластерами Agnostic plugins.

    Загрузите все необходимые пакеты, чтобы к началу окна обновления они были доступны локально. Следующая страница, Обновление глобального кластера, описывает, как upgrade.sh и violet отправляют эти пакеты в платформу — эта отправка загружает артефакты только в registry и может быть выполнена в любое время до начала окна обслуживания.

    WARNING

    Если вы обновляетесь с ACP 4.0 до ACP 4.3 и на любых целевых кластерах установлен Build of TopoLVM, загрузите пакет TopoLVM на эти кластеры, прежде чем продолжить обновление. Этот шаг не требуется при обновлении с ACP 4.1 или ACP 4.2. В --clusters можно указать несколько целевых кластеров, разделяя их запятыми.

    violet push <path/to/directory/only_put_topolvm_plugin_here> \
  --target-catalog-source "platform" \
  --platform-address "https://example.com" \
  --platform-token "<platform_token>" \
  --clusters "cluster-a,cluster-b"
    WARNING

    Начиная с v4.2, мы представили новый плагин под названием Alauda Container Platform Log Essentials. Если ранее вы установили plugin для хранения логов, перед началом обновления также необходимо загрузить и этот plugin.