После создания нагрузки вы можете обновить её и выполнить откат. Гибкий механизм обновления и отката обеспечивает плавный переход между версиями без прерывания сервисов. Если во время обновления возникнет проблема, вы можете быстро восстановить предыдущую стабильную версию. Механизм обновления и отката применяется к нескольким нагрузкам:
Параметр | Описание | Ограничение |
|---|---|---|
Максимальное количество недоступных Подов (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. | Нет |
В дальнейшем используется Deployment в качестве примера для описания того, как настроить политику обновления рабочей нагрузки с помощью kubectl.
vi nginx-deployment.yaml
Ниже приведён пример файла. Для получения подробностей о конфигурации Deployment, смотрите Официальная документация Kubernetes.
apiVersion: apps/v1kind: Deploymentmetadata:name: nginxnamespace: defaultspec:replicas: 2selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:latestimagePullPolicy: Alwaysname: nginxresources:requests:cpu: 250mmemory: 512Milimits:cpu: 250mmemory: 512MiimagePullSecrets:- name: default-secretterminationGracePeriodSeconds: 30strategy:type: RollingUpdate # A rolling upgrade. Recreate indicates a replacement upgrade.rollingUpdate: # Configure rolling upgrade parameters.maxUnavailable: 25%maxSurge: 25%minReadySeconds: 0revisionHistoryLimit: 10progressDeadlineSeconds: 600
Параметр | Описание | Ограничение |
|---|---|---|
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. | Нет |
kubectl create -f nginx-deployment.yaml
Если отображается информация, похожая на следующую, Deployment создаётся:
deployment.apps/nginx created
kubectl get deployment
Если отображается информация, похожая на следующую, Deployment был создан:
NAME READY UP-TO-DATE AVAILABLE AGEnginx 2/2 2 2 4m5s
kubectl edit deploy nginx
Измените образ в spec.containers.image, сохраните изменения и выйдите.
kubectl get rs
Отображается информация, похожая на следующую:
NAME DESIRED CURRENT READY AGEnginx-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%, количество подов меняется следующим образом:
Во время обновления может существовать до трёх подов в общей сложности, при этом два всегда доступны для сервисов. CCE создаёт новые поды, проверяет их готовность и удаляет старые поды один за другим, пока все не будут обновлены.
kubectl get pods
В выводе команды, если все pod находятся Выполняется, Deployment был обновлён.
NAME READY STATUS RESTARTS AGEnginx-6f9f58dffd-tdmqk 1/1 Running 0 1mnginx-6f9f58dffd-tesqr 1/1 Running 0 1m
Если во время обновления произошла ошибка, вы можете откатить Deployment до предыдущей версии. Это возможно, потому что ReplicaSet‑ы предыдущих версий сохраняются после каждого обновления. Откат по сути заменяет обновлённый ReplicaSet старым. Вы можете использовать revisionHistoryLimit для контроля максимального количества сохраняемых исторических версий (по умолчанию: 10).
Выполните следующую команду, чтобы откатить целевой Deployment:
kubectl rollout undo deployment nginx
Если отображается информация, схожая со следующей, откат выполнен успешно:
deployment.apps/nginx rolled back