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