• Следить за работоспособностью своих ВМ и контейнеров, автоматически заменяя неисправные (автовосстановление).
• Масштабировать количество ВМ и контейнеров в обе стороны в зависимости от нагрузки (автомасштабирование).
• Распределять трафик между своими ВМ и контейнерами (балансировка нагрузки).
• Позволять своим ВМ и контейнерам находить друг друга и общаться между собой по сети (обнаружение сервисов).
Выполнение этих задач находится в сфере ответственности средств оркестрации, таких как Kubernetes, Marathon/Mesos, Amazon Elastic Container Service (Amazon ECS), Docker Swarm и Nomad. Например, Kubernetes позволяет описывать и администрировать контейнеры Docker в виде кода. Вначале развертывается кластер Kubernetes, который представляет собой набор серверов для выполнения ваших контейнеров Docker. У большинства облачных провайдеров есть встроенная поддержка развертывания управляемых кластеров Kubernetes: вроде Amazon Elastic Container Service for Kubernetes (Amazon EKS), Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS).
Подготовив рабочий кластер, вы можете описать развертывание своего контейнера Docker в виде кода внутри YAML-файла:
apiVersion: apps/v1
# Используем объект Deployment для развертывания нескольких реплик вашего
# Docker-контейнера (возможно, больше одного) и декларативного выкатывания
# обновлений для него
kind: Deployment
# Метаданные этого развертывания, включая его имя
metadata:
name: example-app
# Спецификация, которая конфигурирует это развертывание
spec:
# Благодаря этому развертывание знает, как искать ваш контейнер
selector:
matchLabels:
app: example-app
# Приказываем объекту Deployment развернуть три реплики Docker-контейнера
replicas: 3
# Определяет способ обновления развертывания. Здесь указываем скользящие обновления
strategy:
rollingUpdate:
maxSurge: 3
maxUnavailable: 0
type: RollingUpdate
# Этот шаблон описывает, какие контейнеры нужно развернуть
template:
# Метаданные контейнера, включая метки
metadata:
labels:
app: example-app
# Спецификация контейнера
spec:
containers:
# Запускаем Apache на порту 80
- name: example-app
image: httpd:2.4.39
ports:
- containerPort: 80
Этот файл говорит Kubernetes, что нужно создать развертывание, которое декларативно описывает следующее.
• Один или несколько контейнеров Docker для совместного запуска. Эта группа контейнеров называется подом, или под-оболочкой. Под, описанный в приведенном выше коде, содержит единственный контейнер, который запускает Apache.
• Настройки каждого контейнера Docker в под-оболочке. В нашем примере под-оболочка настраивает Apach для прослушивания порта 80.
• Сколько копий (реплик) под-оболочки должно быть в вашем кластере. У нас указано три реплики. Kubernetes автоматически определяет, в какой области кластера их следует развернуть, используя алгоритм планирования для выбора оптимальных серверов с точки зрения высокой доступности (например, каждая под-оболочка может оказаться на отдельном сервере, чтобы сбой на одном из них не остановил работу всего приложения), ресурсов (скажем, выбираются серверы с доступными портами, процессором, памятью и другими ресурсами, необходимыми вашему контейнеру), производительности (в частности, выбираются наименее загруженные серверы) и т. д. Кроме того, Kubernetes постоянно следит за тем, чтобы в кластере всегда было три реплики. Для этого автоматически заменяется любая под-оболочка, вышедшая из строя или переставшая отвечать.
• Как развертывать обновления. Когда выходит новая версия контейнера Docker, наш код выкатывает три новые реплики, ждет, когда они станут работоспособными, и затем удаляет три старые копии.
Так много возможностей всего в нескольких строчках на YAML! Чтобы развернуть свое приложение в Kubernetes, нужно выполнить команду kubectlapply-fexample-app.yml. Чтобы выкатить обновления, вы можете отредактировать YAML-файл и снова запустить kubectlapply.
Средства инициализации ресурсов
В отличие от инструментов для управления конфигурацией, шаблонизации серверов и оркестрации, код которых выполняется на каждом сервере, средства инициализации ресурсов, такие как Terraform, CloudFormation и OpenStack Heat, отвечают за создание самих серверов. С их помощью можно создавать не только серверы, но и базы данных, кэши, балансировщики нагрузки, очереди, системы мониторинга, настройки подсетей и брандмауэра, правила маршрутизации, сертификаты SSL и почти любой другой аспект вашей инфраструктуры (рис. 1.5).