• Русский
  • Обновление кластеров

    AC CLI предоставляет команды администратора для подготовки метаданных обновления, просмотра статуса обновления кластера и запроса обновлений кластера.

    Используйте эти команды, когда необходимо:

    • Создать ProductManifest для целевой версии
    • Проверить текущую версию кластера и доступные обновления
    • Запросить обновление до последней версии
    • Запросить обновление до конкретной версии
    • Просмотреть результаты предварительной проверки и ход выполнения обновления

    Перед началом

    В ACP availableUpdates — это не статический список, который вы поддерживаете вручную. Контроллер обновления должен сначала увидеть ProductManifest для целевой версии, прежде чем сможет опубликовать доступные цели обновления для кластера.

    Если вы не создадите ProductManifest сначала, типичные симптомы включают:

    • ac adm upgrade не показывает availableUpdates
    • ac adm upgrade --to-latest сразу завершается с ошибкой
    • Вы можете использовать только --allow-explicit-upgrade для ручного запроса версии

    Рекомендуемый порядок действий:

    1. Определитесь, какую версию вы хотите опубликовать или обновить.
    2. Создайте ProductManifest для этой версии.
    3. Подождите, пока метаданные обновления будут обработаны.
    4. Запустите ac adm upgrade и убедитесь, что availableUpdates заполнен.
    5. Запросите обновление.

    Предварительные требования

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

    • Вы вошли в ACP платформу.
    • У вас есть права администратора кластера или эквивалентные.
    • Вы знаете имя целевого кластера. Если оно не указано, ac adm upgrade по умолчанию использует global.
    • В целевой среде уже установлены CRD ProductManifest и контроллер обновления.

    Вы можете сначала проверить текущий контекст:

    ac config current-context

    Текущий контекст по-прежнему определяет, какие учетные данные и конечная точка используются AC для команды.

    • Для ac adm upgrade и ac adm upgrade status целевой кластер выбирается явно с помощью --cluster, по умолчанию global.
    • Для ac adm release import-manifest AC сначала проверяет REST URL текущего контекста. Если он указывает на путь ACP workload, AC автоматически переписывает запрос на соответствующий глобальный путь. Если текущий контекст не является URL ACP workload/global, AC использует текущий контекст как есть и не требует расширения сессии kubeconfig.

    При необходимости переключитесь на другую сессию ACP:

    # Переключение на другую сессию ACP
    ac config use-session production

    Создание ProductManifest

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

    ac adm release import-manifest --version 4.20.0

    Эта команда создаёт минимальный объект метаданных обновления, необходимый контроллеру:

    • metadata.name использует имя версии с префиксом v, например v4.20.0
    • spec.version использует переданную вами версию, например 4.20.0

    Если вы хотите, чтобы команда ждала, пока объект станет Ready, добавьте --wait:

    ac adm release import-manifest --version 4.20.0 --wait

    Также можно переопределить таймаут ожидания:

    ac adm release import-manifest --version 4.20.0 --wait --timeout=10m

    Поведение команды:

    • --version обязательный параметр.
    • Если ProductManifest не существует, AC создаёт его.
    • Если ProductManifest уже существует с той же версией, команда завершается успешно без изменений.
    • Если ProductManifest уже существует с другой версией, команда завершается с ошибкой и не перезаписывает существующий объект.
    • По умолчанию команда не ждёт Ready. Ожидание происходит только при явном указании --wait.

    Просмотр статуса обновления и доступных обновлений

    После создания ProductManifest используйте следующую команду для просмотра сводки обновления для кластера по умолчанию global:

    ac adm upgrade

    Обычно команда показывает:

    • Текущую версию кластера
    • Желаемую версию, если обновление уже запрошено
    • Текущий список доступных обновлений
    • Общие условия обновления

    Используйте её, чтобы быстро получить ответы на вопросы:

    • Какую версию сейчас использует кластер?
    • Запрошена ли уже целевая версия?
    • Есть ли сейчас новые доступные цели обновления?
    • Находится ли кластер в состоянии Ready, Reconciling или Degraded?

    Чтобы запросить конкретный кластер, добавьте --cluster:

    ac adm upgrade --cluster=workload-a

    Если вы только что создали ProductManifest и всё ещё не видите availableUpdates, контроллер может ещё обрабатывать метаданные. Подождите немного и запустите ac adm upgrade снова.

    Обновление до последней версии

    Когда availableUpdates присутствует, запросите обновление до последней версии командой:

    ac adm upgrade --to-latest

    AC выберет самую высокую версию из availableUpdates и отправит запрос на обновление.

    --to-latest — булевый флаг с значением по умолчанию false, что означает:

    • Если вы не указываете его, AC ведёт себя так, как будто использовано --to-latest=false.
    • Если вы указываете только --to-latest, AC воспринимает это как true.
    • Можно также явно написать --to-latest=true или --to-latest=false.

    Если availableUpdates нет, команда завершается с ошибкой и не отправляет новый запрос на версию.

    После запроса обновления просмотрите сводку снова:

    ac adm upgrade

    Обновление до конкретной версии

    Если хотите обновиться до конкретной версии, выполните:

    ac adm upgrade --to=<version>

    Пример:

    ac adm upgrade --to=4.20.0

    Типичные случаи:

    • Вы не хотите самую новую доступную версию
    • Следуете утверждённой цели выпуска из вашего процесса релизов
    • Хотите повторно запросить известную целевую версию

    По умолчанию запрошенная версия должна уже присутствовать в availableUpdates. Если её нет, команда завершается с ошибкой.

    Если вы намеренно хотите запросить версию, отсутствующую в availableUpdates, добавьте:

    ac adm upgrade --to=<version> --allow-explicit-upgrade

    --allow-explicit-upgrade по умолчанию false:

    • Если не указывать, AC ведёт себя как --allow-explicit-upgrade=false.
    • Если указать только --allow-explicit-upgrade, AC воспринимает как true.
    • Можно явно написать --allow-explicit-upgrade=true или --allow-explicit-upgrade=false.

    Пример:

    ac adm upgrade --to=4.20.0 --allow-explicit-upgrade=true

    Этот флаг меняет только валидацию на стороне клиента. Контроллер обновления и его проверки предварительного запуска по-прежнему решают, можно ли продолжить с запрошенной целью.

    Просмотр подробного статуса обновления

    Для более глубокой диагностики выполните:

    ac adm upgrade status

    Для просмотра конкретного кластера:

    ac adm upgrade status --cluster=workload-a

    По сравнению с ac adm upgrade эта команда расширяет:

    • Сводку текущей версии, желаемой версии и общих условий
    • Результаты предварительной проверки для текущей цели обновления
    • Этапы обновления и прогресс операций

    Результаты предварительной проверки

    Предварительная проверка описывает, можно ли перейти к выполнению обновления. Каждая проверка обычно включает:

    • Имя проверки
    • Политику повторного входа
    • Состояние
    • Причину
    • Сообщение

    Интерпретация состояний:

    • Passed: проверка пройдена.
    • Retry: проверка ещё не может дать окончательный результат. Подождите и проверьте снова.
    • Failed: существует блокирующее условие, которое нужно сначала устранить.

    Если данных предварительной проверки ещё нет, считайте это "результат ещё не получен", а не "все проверки пройдены".

    Этапы обновления

    После начала выполнения обновления вывод статуса показывает этапы и прогресс операций.

    Вывод этапа может включать:

    • Имя этапа
    • Приоритет
    • Фазу

    Вывод операции может включать:

    • Имя операции
    • Действие
    • Текущую версию
    • Целевую версию
    • Фазу

    Интерпретация фаз этапа:

    • Pending: этап ещё не начался.
    • Running: этап выполняется.
    • Finished: этап завершён.

    Если данных по этапам нет, вероятно, обновление ещё не перешло в фазу выполнения.

    Распространённые сигналы и устранение неполадок

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

    • Ready обычно означает, что кластер достиг желаемого состояния.
    • Reconciling обычно означает, что кластер всё ещё применяет текущий запрос обновления.
    • Degraded обычно означает, что обновление заблокировано или возникла ошибка.

    Если ac adm upgrade не показывает availableUpdates, проверьте сначала:

    1. Был ли создан ProductManifest для целевой версии?
    2. Если использовали --wait, достиг ли ProductManifest состояния Ready=True?
    3. Было ли достаточно времени у контроллера для обработки новых метаданных?

    Если ac adm upgrade показывает желаемую цель, но обновление не продвигается:

    1. Выполните ac adm upgrade status.
    2. Проверьте, нет ли элементов предварительной проверки в состоянии Retry или Failed.
    3. Посмотрите, начались ли этапы обновления.

    Если обновление уже в процессе:

    1. Выполните ac adm upgrade status.
    2. Просмотрите текущие фазы этапа и операции.
    3. Сравните текущую версию с целевой.

    Пример рабочего процесса

    # 1. Создайте ProductManifest для целевой версии
    ac adm release import-manifest --version 4.20.0 --wait
    
    # 2. Просмотрите сводку обновления для кластера по умолчанию global
    ac adm upgrade
    
    # 3. Просмотрите сводку для конкретного кластера
    ac adm upgrade --cluster=workload-a
    
    # 4. Запросите обновление до последней доступной версии
    ac adm upgrade --to-latest
    
    # 5. Просмотрите подробный статус
    ac adm upgrade status --cluster=workload-a
    
    # 6. Запросите обновление до конкретной версии
    ac adm upgrade --cluster=workload-a --to=4.20.0
    
    # 7. Запросите версию вне availableUpdates, если намеренно хотите это сделать
    ac adm upgrade --cluster=workload-a --to=4.20.0 --allow-explicit-upgrade