K8s Q A Deployments

Deployment controller

Контроллер развертывания (Deployment controller) предоставляет возможность декларативного обновления для объектов типа поды (Pods) и наборы реплик (ReplicaSets).

Достаточно описать желаемое состояние [подов/реплик] в объекте Deployment, после чего контроллер развертывания изменит текущее состояние объектов на желаемое в контролируемом режиме. Стоит отметить, что при манипуляциях с Deployments нам не нужно беспокоиться об управлении ReplicaSets - все необходимое будет выполнено непосредственно контроллером развертывания.

Как и для всех других API-объектов Kubernetes, для определения Deployment в yaml-файле нужны поля

• apiVersion
• kind
• metadata
• Кроме того, в Deployment также должна присутствовать секция .spec.

В секции .spec обязательно должна присутствовать вложенная секция .spec.template - шаблон Pod.
Он имеет точно такой же формат, как описание пода (Pod) без секций apiVersion и kind.
Кроме обязательных полей, в секции .spec.template при описании Deployment нужно указывать соответствующие метки (.spec.template.metadata.labels) и политику перезапуска (единственным допустимым значением для .spec.template.spec.restartPolicy является Always, которое соответствует значению по умолчанию).
В поле .spec.replicas указываем, сколько экземпляров подов должно быть запущено одновременно - если этого не сделать, то будет запущен только один экземпляр пода - .spec.replicas по умолчанию равно единице.
Можно указать .spec.selector - это необязательное поле, которое определяет селектор меток для подов, предназначенных для этого развертывания. В таком случае, .spec.selector должен соответствовать значению .spec.template.metadata.labels или будет отклонен API Kubernetes.
В поле .spec.strategy необходимо определить стратегию обновления старых подов (Pods) новыми. Допустимые значения для данного поля - Recreate или RollingUpdate (значение по умолчанию).
Если выбрать стратегию Recreate (.spec.strategy.type==Recreate), то перед стартом новых подов будут удалены все старые.
При стратегии обновления RollingUpdate поды будут обновляться плавно, по очереди (дополнительно контролировать этот процесс можно с помощью параметров maxUnavailable и maxSurge).
Параметр .spec.strategy.rollingUpdate.maxUnavailable - необязательное поле, указывающее максимальное количество подов, которые могут быть недоступны в процессе обновления. Значение может быть абсолютным числом (например, 5) или процентом от желаемого количества подов (Pods) (например, 10%). Абсолютное число рассчитывается из процента путем округления. Значение этого параметра не может быть установлено в 0, если .spec.strategy.rollingUpdate.maxSurge = 0, и по умолчанию равно 25%.
Параметр .spec.strategy.rollingUpdate.maxSurge - необязательное поле, указывающее максимальное количество подов (Pods), которое может быть создано сверх желаемого количества подов (Pods), описанного в развертывании. Значение может быть абсолютным числом (например, 5) или процентом от желаемого количества подов (например, 10%). Значение этого параметра не может быть установлено в 0, если .spec.strategy.rollingUpdate.maxUnavailable = 0, и по умолчанию равно 25%.

Ниже представлен пример развертывания (Deployment):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

В этом примере:

• создается развертывание (Deployment) с именем nginx-deployment (имя указано в поле metadata: name);
• развертывание создает три экземпляра пода (количество указано в поле replicas);
• в поле селектора указано, как развертывание (Deployment) обнаружит, какими подами (Pods) нужно управлять. В этом примере просто выбираем одну метку, определенную в шаблоне Pod‘а (app: nginx);
• описание шаблона Pod‘а в поле template: spec “требует” запустить docker-контейнер nginx, из образа nginx версии 1.7.9 (образ будет взят с Docker Hub). Данному поду будет присвоена метка app: nginx;
• развертывание открывает 80-й порт контейнера, так что контейнер может отправлять и принимать трафик.

Сохраним данный манифест в файл nginx-deployment.yaml и запустим его в кластере Kubernetes с помощью команды:

kubectl create -f nginx-deployment.yaml --record
Примечание. Параметр --record нам весьма пригодится для хранения истории изменений развертывания.

Если сразу же запустить команду kubectl get deployments, то скорее всего результат будет следующим:

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         0         0            0           1s

Когда вы с помощью данной команды хотите получить состояние развертываний (Deployments) в кластере, вам доступны следующие поля:

NAME - список имен развертываний в кластере; DESIRED - отображает желаемое количество экземпляров пода (определяется при создании развертывания); CURRENT - отображает количество экземпляров пода в настоящее время; UP-TO-DATE - отображает количество экземпляров пода, которые были обновлены для достижения желаемого состояния; AVAILABLE - отображает количество экземпляров пода, которые доступны пользователям; AGE - отображает время с момента запуска развертывания.
Чтобы увидеть текущий статус (прогресс) развертывания, можно использовать команду kubectl rollout status deployment/nginx-deployment. Вывод будет примерно таким:

Waiting for rollout to finish: 2 out of 3 new replicas have been updated... deployment "nginx-deployment" successfully rolled out

Через несколько секунд (нужно ведь подождать, пока скачается docker-образ) еще раз проверяем состояние развертываний в кластере с помощью kubectl get deployments:

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           18s

Как видим, данное развертывание создало три экземпляра пода (как мы и писали в желаемом состоянии) - “под капотом” был также создан набор реплик (ReplicaSet) - убедиться в этом можно с помощью команды kubectl get rs:

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-2035384211   3         3         3       18s

Имя набора реплик формируется автоматически и выглядит как [DEPLOYMENT-NAME]-[POD-TEMPLATE-HASH-VALUE], hash-значение генерируется при создании развертывания. Узнать какие метки были автоматически добавлены каждому поду можно командой kubectl get pods --show-labels, вывод может выглядеть так:

NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-2035384211-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211

Для обновления развертывания (например, изменения версии docker-образа на 1.9.1) можно воспользоваться такой командой:

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment "nginx-deployment" image updated
или изменить сам манифест развертывания (меняем значение .spec.template.spec.containers[0].image):
kubectl edit deployment/nginx-deployment deployment "nginx-deployment" edited или (предпочтительный вариант) - изменить файл с манифестом развертывания и применить изменения:

nano nginx-deployment.yaml

1. вносим нужные правки и сохраняем файл

kubectl apply -f nginx-deployment.yaml deployment "nginx-deployment" configured Как и раньше, наблюдаем за процессом обновления и получаем интересующую нас информацию командами kubectl rollout status deployment/nginx-deployment, kubectl get deployments и kubectl get rs (ниже приведен только результат последней команды):

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         3       6s
nginx-deployment-2035384211   0         0         0       36s

Как видим, новый (ориентируемся по времени) набор реплик (ReplicaSet) находится в желаемом состоянии, в то время как в старом наборе количество экземпляров пода равно нулю.
Детальное описание развертывания получаем командой kubectl describe deployments:

Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision=2
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
  Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
  Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
  Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
  Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
  Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
  Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0

Рассмотрим пример отката (возвращения к предыдущему состоянию) развертывания (Deployment). Допустим, при обновлении мы ошиблись и указали неверную версию docker-образа - nginx:1.91 вместо nginx:1.9.1:

kubectl set image deployment/nginx-deployment nginx=nginx:1.91 deployment "nginx-deployment" image updated Обновление застопорится (ожидаемо, ведь такого docker-образа нет):

kubectl rollout status deployments nginx-deployment Waiting for rollout to finish: 2 out of 3 new replicas have been updated... Состояние набора реплик будет выглядеть примерно так:

kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   2         2         0       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   2         2         2       6s

Состояние подов будет таким:

kubectl get pods
NAME                                READY     STATUS             RESTARTS   AGE
nginx-deployment-1564180365-70iae   1/1       Running            0          25s
nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s

Примечание. Дополнительную информацию о состоянии развертывания можно также получить используя kubectl describe deployment, но уже и так ясно - необходим откат.

Для возврата на предыдущую (работоспособную) версию развертывания необходимо сначала проверить историю изменений (узнать номер ревизии):

kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

Благодаря параметру --record мы можем увидеть изменения, которые применяли в каждой из ревизий. Узнать больше подробностей о конкретной ревизии развертывания можно указав ее номер, например так:

kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <none>
  No volumes.

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

kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back

Для отката на конкретную ревизию необходимо указать ее номер в параметре --to-revision:

kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back

Для масштабирования (увеличения/уменьшения количества подов) можно использовать команду:

kubectl scale deployment nginx-deployment --replicas=10
deployment "nginx-deployment" scaled

хотя все же лучше вносить изменения в файл с манифестом развертывания (Deployment) и применять их командой kubectl apply.

К развертываниям также применимо горизонтальное масштабирование подов (HPA) - если такое включено в вашем кластере Kubernetes - и применить его можно так:

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment "nginx-deployment" autoscaled