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

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

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

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

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

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

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

Когда приложение выходит из строя из-за неправильного образа или развертывание нестабильно, мы можем захотеть откатить развертывание (k8s rollback). По умолчанию вся история развертывания сохраняется в системе, которая может быть использована позже для отката в случае нестабильного развертывания. Мы можем использовать эту историю для отката в любое время.

Чтобы узнать больше о Постепенном обновлении и Откате, посетите официальную документацию Kubernetes здесь.

В этой статье мы обновим развертывание с использованием стратегии постепенного обновления по умолчанию и откатим развертывание. Для отката развертывания мы используем неправильный образ в одном из обновлений развертывания.

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

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

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

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

На приведенном выше скриншоте вы можете увидеть, что в revision-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”. Мы увидели, как развертывание сохраняет свою версию, к которой оно может быть откатано в случае, если мы не хотим сохранять последние обновления в развертывании.