Поиск по сайту:

Последовательные обновления и откаты в Kubernetes


На этой странице

  1. Предварительные условия
  2. Что мы будем делать?
  3. Последовательное обновление и откат
  4. Заключение

Одним из преимуществ использования развертывания является возможность выполнять последовательные обновления и создавать стратегию непрерывного обновления. Последовательные обновления позволяют нам постепенно обновлять конфигурацию модулей.

Стратегия обновления (k8s rollupdate, стратегия обновления k8s) является наиболее важным параметром для настройки последовательных обновлений. В определении развертывания spec.strategy.type имеет два возможных значения:

  • RollingUpdate: новые пакеты добавляются постепенно, а старые постепенно закрываются.
  • Повторное создание. Все старые модули удаляются сразу перед добавлением новых.

Есть еще 2 варианта обновления развертывания с помощью RollingUpdate.

  • maxSurge: количество модулей, которое может быть создано сверх желаемого количества модулей во время обновления.
  • maxUnreachable: количество пакетов, которые могут быть недоступны в процессе обновления.

Используя последовательные обновления развертывания, мы можем обновить образ, используемый развертыванием. Состояние развертывания (статус развертывания kubectl) сохраняется, что позволяет нам вернуться к любым предыдущим версиям развертывания.

Предпосылки

  1. Кластер Kubernetes по крайней мере с 1 рабочим узлом.
    Если вы хотите научиться создавать кластер Kubernetes, нажмите здесь. Это руководство поможет вам создать кластер Kubernetes с 1 мастером и 2 узлами на экземплярах AWS Ubuntu 18.04 EC2.

Что мы будем делать?

  1. Последовательное обновление и откат

Последовательное обновление и откат

Создайте файл определения развертывания для Nginx с шаблоном модуля развертывания. Здесь мы указали версию Nginx как \nginx:1.14.2\.

vim my-deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-demo
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Давайте проверим существующие модули и создадим развертывание.

kubectl get pods
kubectl create -f my-deployment.yml

Получите подробную информацию о развертывании, которое мы только что создали. Это развертывание создало 4 модуля и управляется набором реплик.

kubectl get deployments
kubectl get pods
kubectl  get replicaset

На приведенном выше снимке экрана вы можете видеть, что у нас есть 1 развертывание, в котором у нас есть 1 набор реплик и 4 модуля, контролируемых набором реплик.

Теперь давайте изменим версию Nginx с \nginx:1.14.2\ на \nginx:1.61.1\.

vim my-deployment.yml

Примените изменение к развертыванию и получите подробную информацию о модулях, наборе реплик и развертывании.

kubectl apply -f my-deployment.yml
kubectl get pods
kubectl get deployments
kubectl get replicaset

На приведенном выше снимке экрана видно, что был создан новый набор реплик, в котором есть 4 пода. Но мы по-прежнему видим старый набор реплик с 0 модулями.

Теперь, если мы снова изменим версию Nginx, но на этот раз укажем неправильную версию Nginx, развертывание завершится ошибкой, так как образ Nginx не существует для неправильной версии.

vim my-deployment.yml

Давайте применим изменение к развертыванию.

kubectl apply -f my-deployment.yml
kubectl get pods
kubectl get deployments

Теперь давайте попробуем получить детали набора реплик.

kubectl get replicaset

На приведенном выше снимке экрана видно, что новые модули не работают с ошибкой «ErrImagePull». Моды не работают, так как образ Nginx не существует для версии «ngin: 1.1.1».

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

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

kubectl rollout history deployments rolling-update-demo

Теперь, используя следующую команду с \--revision=2\, мы можем проверить детали развертывания, которое у нас есть в \--revision=2\

kubectl rollout history deployments rolling-update-demo --revision=2

На приведенном выше снимке экрана вы можете видеть, что версия-2 имеет версию образа Nginx «nginx: 1.16.1», которая работала до того, как мы обновили наше развертывание с версией Nginx «ngin: 1.1.1», которая не удалась.

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

kubectl get deployments
kubectl rollout undo deployment rolling-update-demo
kubectl get pods
kubectl get replicaset

На приведенном выше снимке экрана видно, что мы вернули последнее развертывание, и теперь у нас есть версия развертывания, которая работала до последнего обновления.

Чтобы узнать больше о развертывании, его можно описать с помощью следующей команды.

kubectl get deployments
kubectl describe deployment rolling-update-demo

Заключение

В этой статье мы рассмотрели шаги по созданию развертывания и его обновлению. Мы видели, как можно откатить развертывание, если оно по какой-то причине не удалось. Здесь ошибка, которую мы увидели для неудавшегося развертывания, была \ErrImagePull\. Мы увидели, как развертывание сохраняет свою ревизию, до которой его можно откатить, если мы не хотим сохранять последние обновления в развертывании.