Что такое Kubernetes Deployment

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

Теперь обзорно пройдусь по устройству Kubernetes, чтобы от него плавно перейти к Deployment и его функционалу.

Кластер K8s состоит из двух типов узлов: управляющего и рабочих. Расскажу подробнее о каждом.

Мастер-узел состоит из:

• ETCD. Надежное распределенное хранилище типа «ключ-значение». Используется для всех данных кластера: конфигураций, информации о состоянии, секретах.

• API-сервер. Центральная точка доступа к Kubernetes. Принимает REST-запросы, проверяет их и вносит изменения в etcd. Все остальные компоненты взаимодействуют через kube-apiserver.

• Controller manager. Запускает различные контроллеры: репликации, endpoint, namespace, serviceaccounts. Они поддерживают желаемое состояние системы.

• Sheduler. Определяет, на какой ноде запустить каждый новый под. Для этого учитывает политики, требования к ресурсам, доступность и ограничения.

Управление всеми компонентами мастер-узла осуществляется с помощью команды kubectl. Работает все так: kubectl отправляет запрос на API-сервер, тот распознает запрос, передает его по цепочке и возвращает обратно. Через команду можно развертывать приложения, проверять состояние ресурсов (подов и сервисов), смотреть логи, масштабировать кластеры и управлять их конфигурацией.

Из чего состоят рабочие ноды:

• kube-proxy. Управляет сетевыми правилами и балансировкой, чтобы сделать доступ к сервисам безопасным. Может работать на iptables или на user-space прокси.

• kubelet. Агент на каждом узле, который получает команды от API-сервера и обеспечивает запуск, остановку, мониторинг контейнеров через container runtime.

• container, или container runtime. Среда выполнения контейнеров. Из примеров: Docker, containerd или CRI-O.

Мы разобрались, что из себя представляет K8s. Дальше поговорим о Deployment, или развертывании.

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

• Поддержание нужного количества экземпляров приложения. Deployment контролирует, чтобы указанное вами количество копий приложения (replicas) работало одновременно. Если какой-то экземпляр падает или становится недоступным, Deployment немедленно создает новый под, чтобы всегда поддерживать заданное количество реплик.

• Бесшовное обновление. Deployment создает новые реплики приложения с новым кодом и постепенно отключает старые. Так переход на новую версию получается бесшовным, во время обновления приложение не простаивает.

• Откат к предыдущим версиям. Kubernetes сохраняет историю всех развертываний. Если обновление привело к ошибке или нестабильной работе, вы можете откатить все изменения.

• Масштабирование прямо во время работы сервиса: вы можете быстро задать большее или меньшее количество реплик.

Kubernetes Deployment состоит из трех ключевых компонентов: реплик, селекторов и шаблонов. Рассмотрю каждый из них и объясню, что они делают.

Replicas — количество экземпляров

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

Selector — выбор подов

Механизм, который помогает определять, какие именно поды контролировать. Selector сравнивает метки подов и выбирает нужные объекты. Правильная настройка селектора защищает систему от конфликтов и ошибок.

Template — шаблоны подов

Это образец, по которому создаются новые поды. Здесь указывается, какой контейнер использовать, какие порты открыть и какие дополнительные параметры задать.

Покажу, из какого набора параметров состоит YAML-файл и дам к каждому пояснения:

Теперь расшифрую, что в этом файле чем является:

• apiVersion — версия API Kubernetes для этого объекта.

• apps/v1 — актуальная версия для Deployment, которая гарантирует поддержку всех фич в продакшене.

• kind — какой ресурс создается. В примере файла, который привожу выше, создается Deployment — контроллер, который управляет жизненным циклом подов.

• metadata — служебные поля для идентификации ресурса.

• name: myapp — уникальное имя ресурса Deployment. Это имя используется для управления Deployment через kubectl.

• labels: app: myapp — набор меток (label) для поиска, группировки и селекции. Используются в Service, kubectl, selectors.

• spec — основное тело спецификации для объекта Deployment.

• replicas: 3 — сколько копий (подов) всегда должно быть запущено одновременно.

• selector — правило, по которому Deployment выбирает свои поды. Здесь указывается, что управлять надо всеми подами с лейблом app: myapp.

• template — шаблон, из которого будут создаваться новые поды при деплое, обновлении или восстановлении.

• metadata.labels — здесь задаются те же лейблы, что и в селекторе.

Важно! selector.matchLabels и template.metadata.labels должны совпадать, иначе контроллер не сможет управлять созданными подами, не будет считать их своими. В итоге поведение контроллера будет непредсказуемым или некорректным.

• spec.containers — список контейнеров. В одном поде их может быть несколько.

• name: myapp — имя контейнера. В пределах одного пода оно должно быть уникально, при этом разные контейнеры в разных подах могут называться одинаково.

• image: nginx:1.25 — адрес docker-образа, который будет запускаться. В моем примере указан официальный nginx версии 1.25.

• ports.containerPort — объявление, к какому порту контейнера можно обращаться для приложений внутри и вне пода. В моем примере приложение слушает порт 80. Это не открывает порт наружу — для этого нужен Service.

• env — список переменных окружения, которые будут доступны внутри приложения в контейнере. Здесь внутри контейнера будет доступно ENV=PROD, например, для переключения в боевой режим.

• volumeMounts — список точек монтирования внешних volume в контейнере.

• name: myapp-storage — имя volume из секции ниже.

• mountPath: /data — папка внутри контейнера, куда будет примонтирован volume. Все, что пишется в /data, будет храниться в этом volume.

• volumes — определение всех volume, которые могут использоваться внутри пода.

• name: myapp-storage — имя, по которому volume подключается в volumeMounts.

• emptyDir: {} — встроенный тип volume: временное хранилище, которое при запуске пода создается пустым. Очищается после удаления пода.

Также есть дополнительные команды, которые можно учитывать при описании состояния:

1. resources

Ограничения и гарантии ресурсов поду или контейнеру: CPU и памяти.

• requests — какое минимальное количество ресурсов планировщик Kubernetes выделит поду.

• limits — лимит, который контейнер не может превысить. А если попытается, то будет ограничен или убит.

2. probes (health checks)

Позволяют Kubernetes автоматически проверять, «жив» и «готов» ли контейнер.

3. args и command

Позволяет задавать команду запуска контейнера и аргументы.

• command — переопределяет ENTRYPOINT. Нужно начинать с этой программы.

• args — заменяет и добавляет CMD, или отдельные параметры запуска.

4. envFrom (массовый импорт из ConfigMap/Secret)

Импортирует все ключи из указанных объектов как переменные окружения.

Жизненный цикл Deployment охватывает несколько ключевых этапов, каждый из которых важен для эффективного управления приложениями и контроля их состояния. Расскажу, что это за этапы и что происходит на каждом из них.

Шаг 1. Создание и развертывание

Вы создаете YAML-манифест или используете Helm-чарт — пакет готовых шаблонов манифестов с настраиваемыми параметрами. С Helm-чартами проще управлять сложными приложениями, так как несколько манифестов собрано в едином пакете.

Команда kubectl apply или helm install отправляет манифест на API-сервер, который сохраняет желаемое состояние: надо указать нужное количество реплик, шаблонов подов и другие параметры. Deployment Controller создаст ReplicaSet, Scheduler назначит ноды, а kubelet запустит на них контейнеры.

Шаг 2. Синхронизация состояния

Через отчеты kubelet Deployment Controller непрерывно отслеживает состояние кластера и сравнивает его с желаемым состоянием, указанным в манифесте. Если поды выходят из строя или не отвечают, контроллер автоматически создает новые, чтобы поддерживать нужное количество активных экземпляров.

Шаг 3. Обновление Deployment

При изменениях в манифесте Deployment (например, при замене образа контейнера) контроллер создает новый ReplicaSet, и поды постепенно заменяются на обновленные.

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

Шаг 4. Самовосстановление

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

Шаг 5. Завершение

Когда Deployment достигает конца своего жизненного пути или становится ненужным, его удаляют вместе со всеми связанными ресурсами командой kubectl delete.

Есть две стратегии обновления Deployment:

• Rolling Update, или постепенное обновление. Deployment постепенно создает поды с новой версией приложения и одновременно удаляет поды со старой. Обновление происходит поэтапно, благодаря чему сервис не простаивает: пока часть подов обновляется, остальные работают.

• Recreate, или пересоздание. Deployment убивает все существующие поды и создает другие, с обновленной версией. Это приводит к простою на время обновления, но может быть необходимо для приложений, которые не могут работать в двух разных версиях одновременно.

Работа с Deployment в Kubernetes включает несколько основных команд, которые позволяют создавать, проверять, масштабировать, обновлять и удалять приложения. Ниже описываю эти команды для командной строки и рассказываю об их назначении:

• Создание и применение Deployment:

deployment.yaml — файл с описанием настроек вашего приложения.

• Проверка статуса Deployment. Чтобы просмотреть, было ли создано развертывание, выполните:

Если нужна подробная информация, введите:

• Масштабирование приложений:

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

• Обновление и откат изменений. Чтобы выполнить обновление, используйте команду:

• Откат к предыдущей версии приложения:

• Просмотр истории и удаление Deployment. Узнать историю изменений Deployment можно с помощью команды:

• Удалить Deployment:

Я собрал 14 команд, которые пригодятся в повседневной работе с Kubernetes. Вот они:

1. Просмотреть поды во всех пространствах имен (namespaces):

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

3. Получить сведения об одном объекте:

4. Вывести логи контейнера:

5. Запустить команду внутри контейнера, нужен доступ через shell:

6. Применить или обновить конфигурацию:

7. Посмотреть события (event) в кластере:

8. Удалить объект:

9. Просмотр всех available namespaces:

10. Сменить namespace по умолчанию:

11. Показать состояние нод:

12. Быстро редактировать объект:

13. Получить все ресурсы текущего namespace:

14. Поиск объектов по меткам:

Kubernetes Deployment — это основной инструмент для управления жизненным циклом контейнерных приложений. С ним вы можете автоматически развертывать, масштабировать, восстанавливать и безопасно обновлять микросервисы. Главное преимущество Deployment в том, что вы описываете желаемое состояние системы, а Kubernetes сам подгоняет конфигурацию под ваш запрос.