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
- вносим нужные правки и сохраняем файл
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
