Deployment kubernetes что это
Знакомство с Kubernetes. Часть 5: Развертывания (Deployments)
May 28, 2018 07:33 · 1495 words · 8 minute read kubernetes deployments
Контроллер развертывания (Deployment controller) предоставляет возможность декларативного обновления для объектов типа поды ( Pods ) и наборы реплик ( ReplicaSets ). Давайте разберемся!
При стратегии обновления RollingUpdate поды будут обновляться плавно, по очереди (дополнительно контролировать этот процесс можно с помощью параметров maxUnavailable и maxSurge ).
Ниже представлен пример развертывания ( Deployment ):
Сохраним данный манифест в файл nginx-deployment.yaml и запустим его в кластере Kubernetes с помощью команды:
Когда вы с помощью данной команды хотите получить состояние развертываний ( Deployments ) в кластере, вам доступны следующие поля:
Через несколько секунд (нужно ведь подождать, пока скачается docker-образ) еще раз проверяем состояние развертываний в кластере с помощью kubectl get deployments :
Для обновления развертывания (например, изменения версии docker-образа на 1.9.1) можно воспользоваться такой командой:
Как видим, новый (ориентируемся по времени) набор реплик ( ReplicaSet ) находится в желаемом состоянии, в то время как в старом наборе количество экземпляров пода равно нулю.
Детальное описание развертывания получаем командой kubectl describe deployments :
Обновление застопорится (ожидаемо, ведь такого docker-образа нет):
Состояние набора реплик будет выглядеть примерно так:
Состояние подов будет таким:
Для возврата на предыдущую (работоспособную) версию развертывания необходимо сначала проверить историю изменений (узнать номер ревизии):
Для отката на предыдущую ревизию достаточно выполнить такую команду:
Для масштабирования (увеличения/уменьшения количества подов) можно использовать команду:
На этом все, еще больше информации можно найти в официальной документации по Kubernetes, а в следующей статье мы поговорим об уборке мусора.
Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)
Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.
Схема взята из другого обзора стратегий выката, сделанного в Container Solutions
Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.
Более короткие и частые развертывания имеют следующие преимущества:
В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.
Стратегии деплоя
Существует несколько различных типов стратегий развертывания, коими можно воспользоваться в зависимости от цели. Например, вам может потребоваться внести изменения в некое окружение для дальнейшего тестирования, или в подмножество пользователей/клиентов, или возникнет необходимость провести ограниченное тестирование на пользователях, прежде чем сделать некую функцию общедоступной.
Rolling (постепенный, «накатываемый» деплой)
Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.
Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:
Параметры накатываемого обновления можно уточнить в файле манифеста:
Recreate (повторное создание)
В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:
Соответствующий манифест выглядит примерно так:
Blue/Green (сине-зеленые развертывания)
Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:
После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:
Canary (канареечные развертывания)
Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.
Эта стратегия применяется, когда необходимо испытать некую новую функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы создать два практически одинаковых сервера: один обслуживает почти всех пользователей, а другой, с новыми функциями, обслуживает лишь небольшую подгруппу пользователей, после чего результаты их работы сравниваются. Если все проходит без ошибок, новая версия постепенно выкатывается на всю инфраструктуру.
Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.
Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:
Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)
Канареечные развертывания с Weaveworks Flagger
Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.
Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.
На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:
Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.
Dark (скрытые) или А/В-развертывания
Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).
С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.
Flagger и A/B-развертывания
Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.
Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.
Учимся разворачивать микросервисы. Часть 2. Kubernetes
Это вторая часть из серии статей «Учимся разворачивать микросервисы». В предыдущей части мы написали 2 простеньких микросервиса — бекенд и шлюз, и разобрались с тем, как их упаковать в docker-образы. В этой же статье мы будем организовывать оркестрацию наших docker-контейнеров с помощью Kubernetes. Мы последовательно составим конфигурацию для запуска системы в Minikube, а затем адаптируем ее для деплоя в Google Kubernetes Engine.
Ключевые слова: Java 11, Spring Boot, Docker, image optimization
Разработка Kubernetes конфигурации и деплой системы в Google Kubernetes Engine
Ключевые слова: Kubernetes, GKE, resource management, autoscaling, secrets
Ключевые слова: Helm 3, chart deployment
Ключевые слова: Jenkins configuration, plugins, separate configs repository
Что конкретно мы попытаемся добиться с помощью Kubernetes:
Kubernetes — сложный механизм, призванный сделать нашу систему масштабируемой, отказоустойчивой и простой в развертывании. Он включает в себя множество настроек и возможностей. В статье основной акцент будет сделан на создании Kubernetes-конфигурации для конкретного учебного проекта.
Код проекта доступен на GitHub по ссылке.
Среда Kubernetes
Minikube — это удобный инструмент для экспериментов с Kubernetes на локальной машине. Изначально мы создадим конфигурацию для работы именно в этой среде. Далее мы поговорим, какие корректировки нужно внести, чтобы задеплоить систему в GKE. Google Cloud Platform был выбран из-за бесплатных 300$ на эксперименты в первый год. Для приведенной в статье конфигурации стоит использовать кластер из 2+ стандартных машин (n1-standard-1).
Ссылки по настройке среды:
Объекты Kubernetes
При работе с Kubernetes инженер описывает желаемое состояние системы через определение объектов и связей между ними. А конкретные действия для достижения нужного состояния оркестратор волен выбирать сам. То есть можно сказать, что настройка носит декларативный характер.
Рассмотрим некоторые объекты Kubernetes:
Namespace — пространство имен. Объекты могут взаимодействовать, только если находятся в одном неймспейсе. С помощью неймспейсов возможно развернуть несколько виртуальных кластеров на одном физическом.
Pod — минимальный юнит развертывания. В большинстве случаев включает в себя один контейнер. Множество настроек пода делегируются непосредственно контейнеру докера, например, управление ресурсами, политики рестартов, управление портами.
ReplicaSet — контроллер, позволяющий создать набор одинаковых подов и работать с ними, как с единой сущностью. Поддерживает нужное количество реплик, при необходимости создавая новые поды или убивая старые. На самом деле в большинстве случаев вы не будете работать с ReplicaSet напрямую — для этого есть Deployment.
Deployment — контроллер развертывания, являющийся абстракцией более высокого уровня над ReplicaSet’ом. Добавляет возможность обновления управляемых подов.
Service — отвечает за сетевое взаимодействие группы подов. В системе обычно существует несколько экземляров одного микросервиса, соответственно каждый из них имеет свой IP-адрес. Количество подов может изменяться, следовательно набор адресов также не постоянен. Другим частям системы для доступа к рассматриваемым подам нужен какой-то статичный адрес, который Service и предоставляет.
Во избежание путаницы здесь и в дальнейшем под словом «сервис» я буду подразумевать именно объект Kubernetes, а не экземпляр приложения.
Существует несколько видов сервисов. Перечисленные ниже типы для простоты понимания можно рассматривать, как матрешку. Каждый последующий оборачивает предыдущий и добавляет некоторые правила маршрутизации. Создавая сервис более высокого уровня, автоматически создаются сервисы нижележащего типа. Типы сервисов:
Также Kubernetes из коробки предоставляет поддержку DNS внутри кластера, позволяя обращаться к сервису по его имени. Более подробно про сервисы можно почитать тут.
ConfigMap — объект с произвольными конфигурациями, которые могут, например, быть переданы в контейнеры через переменные среды.
Secret — объект с некой конфиденциальной информацией. Секреты могут быть файлами (№ SSL-сертификатами), которые монтируются к контейнеру, либо же base64-закодированными строками, передающимися через те же переменные среды. В статье будут рассмотрены только строковые секреты.
HorizontalPodAutoscaler — объект, предназначенный для автоматического изменения количества подов в зависимости от их загруженности.
Minikube configuration
Namespace:
Установим его как текущий:
Далее все объекты будут создаваться в неймспейсе ‘msvc-ns’. Если этот шаг пропустить, то будет использоваться неймспейс ‘default’.
Обычно конфигурация для Kubernetes представляет собой обычный yaml-файл с описанием объектов, но также есть возможность создавать эти объекты и через CLI. В дальнейшем все объекты будут описываться в yaml-формате.
ConfigMap
Объект, предоставляющий свойства для подов. В нашем случае шлюзу для связи с подами бекенда необходимо знать URL-адрес их сервиса. Наш ConfigMap будет содержать адреса внутренних сервисов нашего кластера, и его можно будет заинжектить во все заинтересованные микросервисы (в нашей системе это только шлюз).
Как я говорил ранее, в кластере Kubernetes сервисы доступны по их именам. Как мы увидим далее, сервис бекенда будет иметь имя ‘backend’ и использовать 8080 порт.
Secret
Тип Opaque подразумевает, то что секрет задается парами ключ-значение. Для особых секретов, например, паролей реестров Docker-образов, существуют отдельные типы. В данном конфиге мы указываем пароль в открытом виде в блоке stringData. Так как секреты хранятся в кодировке base64, то наши данные будут закодированы автоматически. Секрет можно указать в уже закодированном виде:
Deployments
У нас будет два деплоймента — для бекенда и шлюза.
metadata.labels
Эти поля служат для настройки связей между объектами, а также для их уникальной идентификации. В нашем случае мы отмечаем, что наш деплоймент принадлежит приложению с названием ‘microservices’ и слою ‘gateway’.
Дополнительно хочется отметить похожий по смыслу блок metadata.annotations — он используются исключительно для предоставления метаинформации, которая может быть интроспектирована внешними инструментами.
spec.replicas
В этом поле задается количество реплик нашего микросервиса.
spec.selector.matchLabels
Этот элемент устанавливает связь между деплойментом и управляемыми подами. Так в нашем случае деплоймент будет управлять только теми подами, у которых есть метка tier, равная ‘backend’. Далее в spec.template мы зададим шаблон для создания подов, причем для корректной работы у каждого из них в поле metadata.labels должна быть та же метка, что и здесь.
spec.strategy
Блок spec.strategy описывает стратегию обновления подов. Тип ‘rollingUpdate’ подразумевает, что будет создан новый ReplicaSet, старые поды постепенно будут удаляться из старого ReplicaSet’а, а обновленные добавляться в новый. Скорость замены подов (максимальное количество добавляемых/удаляемых реплик от нужного количества) можно регулировать параметрами maxSurge и maxUnavailable. Эта стратегия позволяет плавно обновить деплоймент, избежав даунтайма. В данном контексте блок spec.strategy приведен только в демонстрационных целях, так как полностью совпадает с дефолтным значением.
spec.templates
Блок spec.templates содержит информацию о создаваемых деплойментом подах.
spec.templates.metadata.labels
Как уже было сказано выше, это поле должно коррелировать с spec.selector.matchLabels, чтобы создаваемые поды могли быть «подхвачены» деплойментом.
spec.templates.spec.containers.image
Используемый образ. Тег latest будет присвоен Docker-образу, если мы его запушим в реестр, явно не указав другой тег. Хоть по смыслу этот тег и обозначает самый свежий образ, однако его использование — не лучшая практика в Kubernetes. В случае чего мы не сможем откатиться к предыдущей версии пода, если его образ был перезаписан в реестре. Как минимум поэтому лучше использовать образы с уникальными тегами. Сейчас же мы умышленно используем ‘latest’ образ и поправим это в 4 части этого цикла статей, когда будем настраивать пайплайн в Jenkins.
spec.templates.spec.containers.envFrom.configMapRef
Ссылаемся на уже созданный ConfigMap и помещаем все значения из него в переменные среды.
spec.templates.spec.containers.env
В этом блоке создаем переменную среды ‘SECRET’, равную значению из нашего объекта-секрета под ключом ‘secret’.
spec.templates.spec.containers.readinessProbe
Проверка готовности пода принимать трафик. Здесь мы указываем эндпойнт, предоставляющий информацию о состоянии микросервиса. Kubernetes будет периодически делать запросы на этот адрес, и если 3 раза подряд статус ответа будет не 200, то проблемный под будет исключен из балансировки нагрузки.
initialDelaySeconds — задежка перед первой проверкой.
periodSeconds — интервал между проверками.
Также существует проверка жизнеспособности пода livenessProbe, но я сомневаюсь в рациональности ее применения здесь (хорошая статья на эту тему).
spec.templates.spec.containers.resources
Ограничения контейнера по ресурсам. limits — максимально доступное количество, а requests — количество ресурсов, предоставляемое контейнеру единовременно при старте. 200m — 200 миллиядер (одна пятая ядра), Mi — мегабайты.
Деплоймент микросервиса бекенда имеет аналогичную конфигурацию, за исключением того, что мы не должны сообщать ему секрет через переменную среды.
Services
Так как мы работаем с Minikube, и у нас нет внешнего балансировщика нагрузки, то выберем тип сервиса NodePort. spec.ports.nodePort — порт на хосте. Если его не указать, то будет выбран рандомный порт из интервала 30000-32767.
Итоговый файл конфигурации для Minikube
Запуск
Подождем пока все объекты Kubernetes запустятся и получим URL нашего приложения:
Далее сгенерируем трафик:
Вывод команды (будет отличаться в вашем случае):
Запросы поступают бекендам равномерно, и каждый бекенд принимает запросы именно от своего шлюза. Признаюсь, я несколько раз проводил запуск, чтобы получить такую картину. Если запустить команду повторно через какое-то время, то шлюзы и бекенды могут быть связаны уже по-другому, причем есть вероятность, что все шлюзы будут слать запросы одному бекенду. Это связано с тем, что имеет место балансировка между клиентами, а не запросами. Например, если один клиент будет слать 1 запрос в секунду, а другой 1000, и они будут изначально «привязаны» к разным репликам, то это приведет к разнице в нагрузке в 1000 раз. Это, безусловно, не лучший вариант балансировки трафика, однако дальнейшее исследование этой темы оставим за рамками данной статьи. Подробнее можно прочитать здесь.
Управление кластером
Здесь я перечислю несколько полезных команд для управления кластером.
Извлечение информации
Изменение конфигурации кластера
Дебаг
GKE configuration
Как я уже говорил, далее мы обсудим, как можно изменить конфигурацию, чтобы задеплоить систему в Google Kubernetes Engine.
Services
Инфраструктура GKE предоставляет нам внешний балансировщик нагрузки, который нам нужен для получения статичного внешнего IP-адреса. Чтобы подключить балансировщик, изменим тип сервиса шлюза на LoadBalancer:
HorizontalPodAutoscalers
HorizontalPodAutoscaler будет автоматически масштабировать деплоймент в зависимости от нагрузки на его поды. Мне не удалось заставить работать этот компонент на Minikube (какие-то странные неполадки с сервером метрик), но в GKE он работает из коробки.
В spec.scaleTargetRef мы указываем, что мы собираемся автомасштабировать деплоймент под именем backend. Далее сообщаем, что собираемся содержать от 1 до 3 реплик и планируем держать поды загруженными на 50%. Отмечу, чтобы задавать планируемую загрузку в процентах (можно указывать и в абсолютных величинах), то надо обязательно указать requests.cpu у управляемых контейнеров.
Конфигурация HorizontalPodAutoscaler’а шлюза аналогична.
Quotas
Квоты позволяют настроить максимальное потребление ресурсов всем кластером. Это обычно нужно, если несколько команд используют один кластер (multitenant environment). Давайте ограничим ресурсы, доступные объектам нашего неймспейса:
Если мы проставляем жесткие ограничения квот по какому-либо параметру, то для каждого из создаваемых подов этот параметр становится обязательным. Это может вызывать неудобства, например, при создании контейнеров из CLI (см. kubectl run ), поэтому установим дефолтные параметры с помощью объекта LimitRange:
Так как конфигурация квот напрямую не относится к нашему приложению, то лучше оформить ее в отдельный файл.
Kubernetes: типы Deployment Strategies и Argo Rollouts
Одна из целей, которые мы преследуем внедряя ArgoCD в Kubernetes – использование новых Deployment Strategies для наших приложений.
Ниже рассмотрим типы деплойментов в Kubernetes, как работают Deployment в Kubernetes, и быстрый пример использования Argo Rollouts, который более детально будем рассматривать в следущих постах.
Deployment Strategies и Kubernetes
Кратко рассмотрим стратегии деплоя, имеющиеся в Kubernetes.
Также, Kubernetes позволяет реализовать аналоги Canary и Blue-Green deployments, хотя с ограничениями.
Recreate
Тут всё достаточно просто: при этой стратегии, Kubernetes останавливает все запущенные в Deployment поды, и на их месте запускает новые.
Очевидно, что при таком подходе будет определённый даунтайм : пока остановятся старые поды (см. Pod Lifecycle — Termination of Pods), пока запустятся новые, пока они пройдут все Readiness проверки – приложение будет недоступно для пользователей.
Имеет смысл использовать его, если ваше приложение не может функционировать с двумя разными версиями одновременно, например из-за ограничений работы с базой данных.
Пример такого деплоймента:
Деплоим version: «1.0» :
Оба пода убиваются, и затем создаются новые:
Rolling Update
С RollingUpdate всё немного интереснее: тут Kubernetes запускает новые поды параллельно с запущенными старыми, а затем убивает старые, и оставляет только новые. Таким образом, в процессе деплоя некоторое время одновременно работают две версии приложения – и старое, и новое. Является типом по-умолчанию.
При таком подходе получаем zero downtime, так как в процессе обновления часть подов со старой версией остаётся жива.
Из недостатков – могут быть ситуации, когда такой подход неприменим. Например, если при старте подов выполняются MySQL-миграции, которые меняют схему базы данных таким образом, что предыдущая версия приложения не сможет её использовать.
Пример такого деплоймента: