Deployment kubernetes что это

Проброс порта в pod

А сейчас пробросим 80-й порт мастера в конкретный под и проверим, что nginx действительно работает в соответствии с установленным конфигом. Делается это следующим обарзом.

Перемещаемся в сосeднюю консоль мастера и там проверяем через curl.

# curl localhost:80
deployment-nginx-848cc4c754-w7q9s

Если сделать проброс в другой под и проверить подключение, вы получите в ответ на запрос curl на 80-й порт мастера имя второго пода. На практике, я не знаю, как можно использовать данную возможность. А вот для тестов в самый раз.

Clean up Policy

You can set .spec.revisionHistoryLimit field in a Deployment to specify how many old ReplicaSets for
this Deployment you want to retain. The rest will be garbage-collected in the background. By default,
it is 10.

Note: Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment thus that Deployment will not be able to roll back.

Kubernetes Deployment vs. StatefulSets

A StatefulSet is a workload API object for managing stateful applications. They let you ensure that pods are scheduled in a specific order, that they have persistent storage volumes available, and that they have a persistent network ID that is maintained even when a pod shuts down or is rescheduled.

Similar to Deployments, StatefulSets manage the behavior of pods. However, it differs from deployments in that it maintains a static ID for each pod. Pods are created from the same template, but each one has a separate identity, making it possible to maintain a persistent state across the full lifecycle of the pod.

Rolling Back a Deployment

Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
By default, all of the Deployment’s rollout history is kept in the system so that you can rollback anytime you want
(you can change that by modifying revision history limit).

Note: A Deployment’s revision is created when a Deployment’s rollout is triggered. This means that the new revision is created if and only if the Deployment’s Pod template (.spec.template) is changed, for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment, do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling. This means that when you roll back to an earlier revision, only the Deployment’s Pod template part is rolled back.

Checking Rollout History of a Deployment

In this example:

Note: You can specify the —record flag to write the command executed in the resource annotation kubernetes.io/change-cause. The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.

Note: You must specify an appropriate selector and Pod template labels in a Deployment (in this case, app: nginx). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn’t stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.

Pod-template-hash label

Caution: Do not change this label.

The pod-template-hash label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.

This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the PodTemplate of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels,
and in any existing Pods that the ReplicaSet might have.

Kubernetes Deployments vs. Pods

A Deployment is a management tool for controlling the behavior of pods. By default, Kubernetes runs one instance for each Pod you create. However, by defining a Deployment object, you can specify that Kubernetes should run multiple instances of the pod. Behind the scenes, the Deployment object creates ReplicaSets to run the required instances of the pod.

This is part of an extensive series of guides about Kubernetes.

Scaling a Deployment

kubectl scale deployment.v1.apps/nginx-deployment —replicas

The output is similar to this:

Assuming horizontal Pod autoscaling is enabled
in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
Pods you want to run based on the CPU utilization of your existing Pods.

kubectl autoscale deployment.v1.apps/nginx-deployment —min —max —cpu-percent

Proportional scaling

RollingUpdate Deployments support running multiple versions of an application at the same time. When you
or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress
or paused), the Deployment controller balances the additional replicas in the existing active
ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called proportional scaling.

For example, you are running a Deployment with 10 replicas, maxSurge=3, and maxUnavailable=2.

In our example above, 3 replicas are added to the old ReplicaSet and 2 replicas are added to the
new ReplicaSet. The rollout process should eventually move all replicas to the new ReplicaSet, assuming
the new replicas become healthy. To confirm this, run:

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m

The rollout status confirms how the replicas were added to each ReplicaSet.

NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m

Запуск контейнера nginx в kubernetes

Начнем с самого простого — создадим один pod, в котором запустим контейнер с последней версией nginx. P OD в терминологии kubernetes — это набор контейнеров, объединенных между собой общим . Самое важное тут то, что все контейнеры в одном поде связаны между собой сетью в рамках общего localhost. Они не могут использовать один и тот же порт. По сути, кубернетис работает не с докер контейнерами, а именно с подами.

Создаем файл pod-nginx.yaml следующего содержания:

—
apiVersion: v1
kind: Pod
metadata:
name: pod-nginx
spec:
containers:
— image: nginx:1.16
name: nginx
ports:
— containerPort: 80

Внимательно следите за пробелами в начале строк. Нужны именно пробелы, а не табуляция. В Yaml файлах очень важна структура. Запускаем получившийся pod.

# kubectl create -f pod-nginx.yaml
pod/pod-nginx created

Сразу сделаю пояснение насчет команды create. Вместо нее можно, а чаще всего и нужно, так как удобнее, использовать команду apply. Create создает новую абстракцию. Если вы ее измените и снова создадите с тем же именем, то получите ошибку. Вам придется сначала ее удалить, а потом создать заново. Команда apply сначала проверяет наличие абстракции, в данном случае и если ее нет, то создает. А если она уже есть, то просто перезапускает существующую с новыми параметрами.

Проверяем, что получилось.

# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-nginx 1/1 Running 0 2m32s

В настоящий момент мы запустили в кластере kubernetes один контейнер с nginx. Существует команда edit, которая позволяет редактировать сущности кластера kubernetes в режиме реального времени. Применение изменений произойдет сразу же после сохранения изменений. Пример:

# kubectl edit pod pod-nginx

Вы увидите полный конфиг пода, который использует кластер. В нем намного больше информации, нежели в вашем yaml файле.

Удалить созданный pod можно следующей командой:

# kubectl delete pod pod-nginx
pod «pod-nginx» deleted

Или сразу все поды:

# kubectl delete pod —all

Pausing and Resuming a Deployment

You can pause a Deployment before triggering one or more updates and then resume it. This allows you to
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.

Note: You cannot rollback a paused Deployment until you resume it.

Deployment status

A Deployment enters various states during its lifecycle. It can be progressing while
rolling out a new ReplicaSet, it can be complete, or it can fail to progress.

Progressing Deployment

You can monitor the progress for a Deployment by using kubectl rollout status.

Complete Deployment

You can check if a Deployment has completed by using kubectl rollout status. If the rollout completed
successfully, kubectl rollout status returns a zero exit code.

kubectl rollout status deployment.v1.apps/nginx-deployment

Failed Deployment

One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
(.spec.progressDeadlineSeconds). .spec.progressDeadlineSeconds denotes the
number of seconds the Deployment controller waits before indicating (in the Deployment status) that the
Deployment progress has stalled.

kubectl patch deployment.v1.apps/nginx-deployment -p

Примечание. Kubernetes не предпринимает никаких действий в отношении остановленного развертывания, кроме сообщения о состоянии состояния с Reason=ProgressDeadlineExceeded. Оркестраторы более высокого уровня могут воспользоваться этим и действовать соответствующим образом, например, откатить развертывание до его предыдущей версии.

Примечание. Если вы приостановите развертывание, Kubernetes не будет проверять прогресс в соответствии с указанным вами сроком. Вы можете безопасно приостановить развертывание в середине развертывания и возобновить его, не вызывая условия превышения крайнего срока.

kubectl описывает развертывание nginx-deployment

Если вы запустите kubectl get deployment nginx-deployment -o yaml, статус развертывания будет примерно таким:

В конце концов, как только крайний срок выполнения развертывания будет превышен, Kubernetes обновит статус и
причина прогрессирующего состояния:

Условия:
Тип Статус Причина
—- —— ——
Доступно True MinimumReplicasAvailable
Выполняется False ProgressDeadlineExceeded
ReplicaFailure True FailedCreate

Вы можете решить проблему недостаточной квоты, уменьшив масштаб своего развертывания, уменьшив другие
контроллеров, которые вы можете использовать, или увеличив квоту в вашем пространстве имен. Если вы выполните квоту
условий, а затем контроллер развертывания завершает развертывание развертывания, вы увидите
Обновление состояния развертывания с условием успешного выполнения (Status=True и Reason=NewReplicaSetAvailable).

Условия:
Тип Статус Причина
—- —— ——
Доступно True MinimumReplicasAvailable
Прогресс True NewReplicaSetAvailable

Type=Available with Status=True означает, что ваше развертывание имеет минимальную доступность. Минимальная доступность диктуется
по параметрам, указанным в стратегии развертывания. Type=Progressing with Status=True означает, что ваше развертывание
либо находится в середине развертывания и выполняется, либо успешно завершено его выполнение и минимальные
требуемые новые реплики доступны (подробности см. в причине условия — в нашем случае
Reason=NewReplicaSetAvailable означает, что развертывание завершено).

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

Действия при неудачном развертывании

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

Примеры развертывания Kubernetes YAML

apiVersion: apps/v1
вид: развертывание
метаданные:
имя: nginx-развертывание
этикетки:
приложение: веб
спецификация:
селектор:
метки соответствия:
приложение: веб
реплики: 5
стратегия:
тип: RollingUpdate
шаблон:
метаданные:
этикетки:
приложение: веб
спецификация:
контейнеры:
—имя: nginx
изображение: nginx
порты:
—КонтейнерПорт: 80

Важные моменты в этой конфигурации:

С ограничениями ресурсов

apiVersion: apps/v1
вид: развертывание
метаданные:
имя: nginx-развертывание
этикетки:
приложение: веб
спецификация:
селектор:
метки соответствия:
приложение: веб
реплики: 5
стратегия:
тип: RollingUpdate
шаблон:
метаданные:
этикетки:
приложение: веб
спецификация:
контейнеры:
—имя: nginx
изображение: nginx
Ресурсы:
пределы:
память: 200Ми
Запросы:
процессор: 100 м
память: 200Ми
порты:
—КонтейнерПорт: 80

Поле spec.containers.resources указывает:

С проверкой здоровья

apiVersion: apps/v1
вид: развертывание
метаданные:
имя: nginx-развертывание
этикетки:
приложение: веб
спецификация:
селектор:
метки соответствия:
приложение: веб
реплики: 5
стратегия:
тип: RollingUpdate
шаблон:
метаданные:
этикетки:
приложение: веб
спецификация:
контейнеры:
—имя: nginx
изображение: nginx
порты:
—КонтейнерПорт: 80
живостьзонд:
httpПолучить:
путь: /
порт: 80
начальные секунды задержки: 5
периодСекунды: 5

Поле template.spec.containers.livenessProbe определяет, что kubelet должен проверить, чтобы убедиться, что модуль жив:

С постоянными томами

apiVersion: apps/v1
вид: развертывание
метаданные:
имя: nginx-развертывание
этикетки:
приложение: веб
спецификация:
селектор:
метки соответствия:
приложение: веб
реплики: 5
стратегия:
тип: RollingUpdate
шаблон:
метаданные:
этикетки:
приложение: веб
спецификация:
сходство:
сродство узлов:
requiredDuringSchedulingIgnoredDuringExecution:
нодселектортермс:
—matchExpressions:
—ключ: тип диска
оператор: В
ценности:
— SSD
контейнеры:
—имя: nginx
изображение: nginx
порты:
—КонтейнерПорт: 80

Поле spec.affinity определяет критерии, которые могут повлиять на то, будет ли модуль планироваться на определенном узле или нет:

Развертывание Kubernetes с Codefresh

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

Замечательно то, что вы можете ответить на все эти вопросы, просмотрев одну панель. Панель управления нашими приложениями показывает:

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

Развертывание реальных приложений в кластере

Давайте теперь на яву попробуем что-то играть в кластере kubernetes. Я предлагаю использовать демо магазин носков из этого репозитория — https://github.com/microservices-demo/microservices-demo. Там есть длиннющий файл yaml, который содержит в себе все необходимое (развертывание, обслуживание и т.д.) для запуска магазина. Принцип состоит из компонентов, так что мы придерживаемся практики, как легко и быстро можно использовать сложные приложения в кластере.

Магазин настроения на работе в отдельном пространстве имен — sock-shop. Его предварительно надо создать.

# kubectl create namespace sock-shop

Запускаем деплой всего проекта одной команды.

# kubectl get pods -n sock-shop -w

После того, как они все будут доступны, можно проверить работу. В этом проекте не используется ingress, поэтому чтобы понять, как подключиться к магазину, необходимо провести расследование. Для начала просмотра запущенных сервисов.

# kubectl get service -n sock-shop -o wide

Нас интересует тип NodePort, поэтому он не может быть подключен извне. Видим, что портировано 30001 и имя приложения . Посмотрим, где оно запущено.

# kubectl get pod -n sock-shop -o wide

Этот модуль запущен на kub-node-2. Посмотрим ее ip.

# kubectl get node -o wide

Ее ip адрес — 10.1.4.33. Значит для проверки магазина надо идти по урлу http://10.1.4.33:30001/

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

—
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ingress-sock
namespace: sock-shop
spec:
rules:
— host: sock-shop.cluster.local
http:
paths:
— backend:
serviceName: front-end
servicePort: 80

Не забывайте указывать нужный namespace и правильное имя сервиса, для которого настраиваем ingress. Применяем конфиг.

# kubectl apply -f ingress-sock.yaml

Смотрим, что получилось.

# kubectl get ingress -n sock-shop -o wide
NAME HOSTS ADDRESS PORTS AGE
ingress-sock sock-shop.cluster.local 10.1.4.39 80 29s

Редактируем файл hosts и идем в браузер проверять.

Поздравляю, ваш кластер работает, а вы теперь администратор кластера Kubernetes и инженер yaml файлов 🙂 У вас теперь будет большая дружба с лапшеподобным синтаксисом. Идите к руководству и требуйе прибавки к зарплате минимум на 30%.

Kubernetes Deployment Strategies

Deployment strategies are different ways of rolling out a new version of an application in a Kubernetes cluster.

Recreate Deployment

A rolling update deployment strategy allows for a sequential, gradual transition from one application version to another. In this deployment, a new version of a ReplicaSet is started alongside the existing ReplicaSet with the old version. The Deployment object launches new pods using the new version of the pod specification, and when the new pods start successfully, shuts down the old pods.

Rolling updates allow you to migrate between versions in a safe and controlled manner, but the transition to the new version can take time. Also, it can be difficult to roll back or interrupt the deployment in the middle if something goes wrong.

Blue/Green Deployment (Also Known as Red/Black Deployment)

The blue/green strategy allows for a quick transition from the old application version to the new version, and enables testing of the new version in production. “ Green” refers to the new version, which is deployed alongside the old version, called the “blue” version.

The downside of a blue/green deployment is that it requires twice the resource utilization, at least during the staging and cut-off period.

Canary Deployment

A downside of canary deployment is that the application must be able to run two versions at the same time, which is not supported by many legacy applications. In addition, for an effective canary strategy, you also need a service mesh or network gateway to split traffic between current and canary versions.

A/B Testing

In the context of Kubernetes, A/B testing refers to a deployment in which traffic is distributed between different versions of an application based on certain parameters.