Облачная платформаAdvanced

Обновление и откат нагрузки

Эта статья полезна?
Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

После создания нагрузки вы можете обновить её и выполнить откат. Гибкий механизм обновления и отката обеспечивает плавный переход между версиями без прерывания сервисов. Если во время обновления возникнет проблема, вы можете быстро восстановить предыдущую стабильную версию. Механизм обновления и отката применяется к нескольким нагрузкам:

  • Обновление: применяется к Deployments, StatefulSets и DaemonSets.
  • Откат: применяется к Deployments.

Использование консоли

  1. Войдите в CCE консоль и нажмите название кластера, чтобы открыть консоль кластера.
  2. В панели навигации выберите Нагрузки. В верхнем правом углу отображаемой страницы нажмите Создать нагрузку.
  3. В Обновление область под Расширенные настройки, выберите режим обновления. Подробнее см. Таблица 1. Общие параметры для скользящих обновлений и обновлений замены служат аналогичным целям, хотя их реализации различаются.

    Таблица 1 Режимы обновления нагрузки

    Параметр

    Описание

    Ограничение

    Максимальное количество недоступных Подов (maxUnavailable)

    Максимальное количество или процент подов, которые могут быть недоступны во время скользящего обновления. Это также задает предел для количества работающих подов, находящихся ниже ожидаемого количества. Значение по умолчанию — 25%. При обновлении процент преобразуется в абсолютное число и округляется вниз.

    Например, если spec.replicas установлено в 2, нет pod'ов (2 x 0.25 = 0.5, округлено вниз до 0), которые могут быть недоступны. Поэтому во время обновления всегда будет работать как минимум два pod'а (2 желаемых - 0 недоступных). Каждый старый pod удаляется только после создания нового, гарантируя, что как минимум два pod'а всегда работают, пока все pod'ы не будут обновлены.

    Этот параметр доступен только для Deployments и DaemonSets.

    Max. Surge (maxSurge)

    Максимальное количество или процент pod'ов, которые могут существовать сверх желаемого количества pod'ов во время скользящего обновления. Этот параметр определяет максимальное количество новых pod'ов, которые могут быть созданы одновременно для замены старых pod'ов. Значение по умолчанию 25%. Во время обновления процент преобразуется в абсолютное число и округляется вверх.

    Например, если spec.replicas установлено в 2, максимум один Под (2 x 0.25 = 0.5, округляется до 1) может быть создан одновременно по умолчанию. Поэтому во время обновления может существовать до 3 Подов (2 желаемых + 1 surge).

    Этот параметр доступен только для Deployments и DaemonSets.

    Мин. Ready Seconds (minReadySeconds)

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

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

    None

    Ограничение истории ревизий (revisionHistoryLimit)

    Максимальное количество старых ReplicaSets, сохраняемых для отката. Они потребляют ресурсы etcd и появляются в kubectl get rs вывод.

    Исторические конфигурации каждого Deployment хранятся в соответствующем ReplicaSet. Удаление старого ReplicaSet делает невозможным откат Deployment до этой версии. По умолчанию CCE сохраняет последние 10 старых ReplicaSets.

    None

    Максимальная длительность обновления (progressDeadlineSeconds)

    Максимальное время в секундах, которое Развертывание может занять для выполнения прогресса, прежде чем будет считаться неудачным. При указании этого параметра убедитесь, что его значение больше minReadySeconds.

    Во время скользящего обновления, если Развертывание не делает прогресс в течение времени, указанного progressDeadlineSeconds, он помечается следующими условиями: Type=Progressing, Status=False, и Reason=ProgressDeadlineExceeded. Приведённая выше информация указывает на то, что обновление Развертывания не удалось. CCE фиксирует событие сбоя, но не откатывает Развертывание к предыдущей версии автоматически. Откат необходимо выполнить вручную или инициировать через внешний механизм.

    Этот параметр доступен только для Развертываний.

    Временное окно масштабирования‑вниз (terminationGracePeriodSeconds)

    Максимальное время, которое kubelet ожидает завершения контейнеров в pod корректно при удалении pod. Значение по умолчанию — 30 секунд. Контейнеры должны завершиться в течение этого периода. В противном случае они будут принудительно завершены сигналом SIGKILL.

    Нет

  4. Настройте остальные параметры и нажмите Создать рабочую нагрузку. Статус нагрузки изменится на Запущено позже.

Использование kubectl

В дальнейшем используется Deployment в качестве примера для описания того, как настроить политику обновления рабочей нагрузки с помощью kubectl.

  1. Используйте kubectl для доступа к кластеру. Подробнее см Доступ к кластеру с использованием kubectl.
  2. Создайте файл с именем nginx-deployment.yaml. Имя является лишь примером. Вы можете переименовать его по необходимости.

    vi nginx-deployment.yaml

    Ниже приведён пример файла. Для получения подробностей о конфигурации Deployment, смотрите Официальная документация Kubernetes.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: nginx
    namespace: default
    spec:
    replicas: 2
    selector:
    matchLabels:
    app: nginx
    template:
    metadata:
    labels:
    app: nginx
    spec:
    containers:
    - image: nginx:latest
    imagePullPolicy: Always
    name: nginx
    resources:
    requests:
    cpu: 250m
    memory: 512Mi
    limits:
    cpu: 250m
    memory: 512Mi
    imagePullSecrets:
    - name: default-secret
    terminationGracePeriodSeconds: 30
    strategy:
    type: RollingUpdate # A rolling upgrade. Recreate indicates a replacement upgrade.
    rollingUpdate: # Configure rolling upgrade parameters.
    maxUnavailable: 25%
    maxSurge: 25%
    minReadySeconds: 0
    revisionHistoryLimit: 10
    progressDeadlineSeconds: 600

    Таблица 2 Режимы обновления нагрузки

    Параметр

    Описание

    Ограничение

    maxUnavailable

    Максимальное количество или процент pod‑ов, которые могут быть недоступны во время rolling upgrade. Это также устанавливает ограничение на количество запущенных pod‑ов, которые могут быть ниже ожидаемого числа. Значение по умолчанию 25%. При обновлении процент преобразуется в абсолютное число и округляется вниз.

    Например, если spec.replicas установлен в 2, нет pods (2 x 0.25 = 0.5, округляется вниз до 0) могут быть недоступны. Поэтому во время обновления всегда будет работать как минимум два pods (2 desired - 0 unavailable). Каждый старый pod удаляется только после создания нового, гарантируя, что как минимум два pod'а всегда работают, пока все pod'ы не обновятся.

    Этот параметр доступен только для скользящих обновлений.

    maxSurge

    Максимальное количество или процент pods, которые могут превышать желаемое количество pods во время скользящего обновления. Этот параметр определяет максимальное количество новых pods, которые могут быть созданы одновременно для замены старых pods. Значение по умолчанию — 25%. Во время обновления процент преобразуется в абсолютное число и округляется вверх.

    Например, если spec.replicas установлено в 2, максимум один pod (2 x 0.25 = 0.5, округляется вверх до 1) может быть создан одновременно по умолчанию. Поэтому во время обновления может существовать до 3 pod'ов (2 желаемых + 1 surge).

    Этот параметр доступен только для rolling upgrades.

    minReadySeconds

    Минимальная продолжительность, в течение которой новый pod должен оставаться в состоянии ready, прежде чем будет помечен как доступный.

    Это обеспечивает стабильный период наблюдения, предотвращая подключение нестабильных pod к сервису слишком рано и тем самым повышая стабильность и надёжность развертывания.

    Нет

    revisionHistoryLimit

    Максимальное количество старых ReplicaSet, сохраняемых для отката. Они используют ресурсы etcd и отображаются в kubectl get rs вывод.

    Исторические конфигурации каждого Deployment хранятся в соответствующем ReplicaSet. Удаление старого ReplicaSet делает невозможным откат Deployment к этой версии. По умолчанию CCE сохраняет последние 10 старых ReplicaSet.

    Нет

    progressDeadlineSeconds

    Максимальное время, в секундах, которое Deployment может занимать для достижения прогресса, прежде чем считается неудачным. При указании этого параметра убедитесь, что его значение больше чем minReadySeconds.

    Во время поочерёдного обновления, если Deployment не делает прогресс в течение времени, указанного в progressDeadlineSeconds, он помечается следующими условиями: Type=Progressing, Status=False, и Reason=ProgressDeadlineExceeded. Приведённая выше информация указывает, что обновление Deployment завершилось неудачей. CCE фиксирует событие отказа, но не откатывает Deployment автоматически к предыдущей версии. Откат должен быть выполнен вручную или инициирован внешним механизмом.

    Нет

    terminationGracePeriodSeconds

    Максимальное время, которое kubelet ожидает завершения контейнеров в pod корректно при удалении pod. По умолчанию — 30 секунд. Контейнеры должны завершиться в течение этого периода. В противном случае они будут принудительно завершены с помощью SIGKILL.

    Нет

  3. Создайте Deployment.

    kubectl create -f nginx-deployment.yaml

    Если отображается информация, похожая на следующую, Deployment создаётся:

    deployment.apps/nginx created

  4. Проверьте статус Deployment.

    kubectl get deployment

    Если отображается информация, похожая на следующую, Deployment был создан:

    NAME READY UP-TO-DATE AVAILABLE AGE
    nginx 2/2 2 2 4m5s

  5. Измените образ, используемый Deployment, на nginx:alpine.

    kubectl edit deploy nginx

    Измените образ в spec.containers.image, сохраните изменения и выйдите.

  6. Проверьте ReplicaSets Deployment.

    kubectl get rs

    Отображается информация, похожая на следующую:

    NAME DESIRED CURRENT READY AGE
    nginx-6f9f58dffd 2 2 2 1m # New-version ReplicaSet (activated)
    nginx-7f98958cdf 0 0 0 48m # Old-version ReplicaSet (deactivated)

    Во время обновления, с spec.replicas установить в 2 и оба maxSurge и maxUnavailable установить в 25%, количество подов меняется следующим образом:

    • maxSurge = 1 (2 x 25% = 0.5, округлено вверх) -> Можно добавить не более одного дополнительного пода.
    • maxUnavailable = 0 (2 x 25% = 0.5, округлено вниз) -> Недоступный под не допускается.

    Во время обновления может существовать до трёх подов в общей сложности, при этом два всегда доступны для сервисов. CCE создаёт новые поды, проверяет их готовность и удаляет старые поды один за другим, пока все не будут обновлены.

  7. После завершения обновления проверьте статусы pod:

    kubectl get pods

    В выводе команды, если все pod находятся Выполняется, Deployment был обновлён.

    NAME READY STATUS RESTARTS AGE
    nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m
    nginx-6f9f58dffd-tesqr 1/1 Running 0 1m

Откат рабочей нагрузки

Если во время обновления произошла ошибка, вы можете откатить Deployment до предыдущей версии. Это возможно, потому что ReplicaSet‑ы предыдущих версий сохраняются после каждого обновления. Откат по сути заменяет обновлённый ReplicaSet старым. Вы можете использовать revisionHistoryLimit для контроля максимального количества сохраняемых исторических версий (по умолчанию: 10).

  • Используя консоль
    1. Войдите в CCE консоль и нажмите имя кластера, чтобы открыть консоль кластера.
    2. В навигационной панели выберите Рабочие нагрузки. В Операция столбец целевой рабочей нагрузки, выберите Больше > Roll Back.

  • Использование kubectl

    Выполните следующую команду, чтобы откатить целевой Deployment:

    kubectl rollout undo deployment nginx

    Если отображается информация, схожая со следующей, откат выполнен успешно:

    deployment.apps/nginx rolled back