Оркестратор Docker: Swarm или Kubernetes

Дмитрий Лазаренко, Jelastic

Микросервисы

Микросервисы vs. Монолит

Оркестраторы контейнеров

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

Но это не тривиально…

Но это не тривиально…

Как бы вы строили приложение из 1000 узлов, не имея возможности

зайти в его админку? Вообще никогда.

Kubernetes

Идеология Kubernetes

Любой компонент в любой момент может упасть: • сервер• жесткий диск• сеть• VM• контейнер• приложение

Что позволяет делать Kubernetes?

1. Вы декларативно описываете конфигурацию приложения (YAML)

2. Каждая группа компонент (Pod) именуется (Label)3. Описываете какие группы компонент должны быть

продублированы, например сервис A запускать в 5 экземплярах

4. Kubernetes разворачивает указанную конфигурацию на доступной инфраструктуре (Nodes)

5. Kubernetes следит за тем, чтобы текущая конфигурация приложения всегда соответствовала эталонной

6. Есть встроенные health checks, на основе которых происходит оценка здоровья приложения и замена больных Pod на новые

7. В итоге ваше приложение всегда имеет нужное количество запущенных экземпляров

Архитектура Kubernetes

1. Master – Оркестратор2. Nodes - рабочие

сервера

Архитектура Kubernetes

Nodes

1. Каждый узел состоит из набора Pod-ов

2. Каждый Pod состоит из набора связанных контейнеров

3. Pod, а не контейнер – единица масштабирования в Kubernetes

4. Kubernetes содержит встроенные алгоритмы для Anti-affinity

Volumes

1. Empty Dir2. NFS3. GCEPersistentDisk4. awsElasticBlockStore5. Glusterfs6. Iscsi7. Rbd8. Secrets

Labels

1. Разметка вашей конфигурации. KEY/VALUE2. “labels”: {

“tier”: “frontend”“application.awesome-game/environment”:

“production”}

Label selector

1. Механизм запросов к Labels2. tier != frontend, game = super-shooter-23. environment in (production, qa)

tier notin (frontend, backend)partition

Replication controller

1. Несколько копий одного Pod называются репликами2. Replication Controller следит за поддержанием заданного

уровня репликации Pod3. Обеспечивает защиту от сбоев4. Позволяет изменять label для конкретного Pod, таким образом

исключая его из репликации или проводить ZDT Rolling Updates

5. Масштабирование приложения происходит только вручную через смену количества реплик для конкретного Pod

Services

1. Reverse-proxy2. Проброс HTTP-запросов

из вне на PODы3. Сервисы имеют

внешние IP4. Простая Round-Robin

балансировка

Services

Service Discovery

•Переменные окружения из Pod появляются на Node•Cluster DNS- Специальный Pod Etcd – хранение конфигурации SkyDns – DNS-сервер, читающий из Etcd Kube2sky –публикует актуальную информацию из

Kubernetes Master в Etcd

Health checking

▪TCP Socket▪HTTP GET▪Container Exec

livenessProbe:enabled: truetype: http

initialDelaySeconds: 30httpGet:

path: /_status/healthzport: 8080

Порталы управления

Как развернуть?

▪Local (Docker-based)▪Vagrant▪Local (No VM)▪Hosted Solution:

▪Google Container Engine▪AWS▪Azure▪Mesosphere▪OpenStack Magnum/Murano

Преимущества Kubernetes

1. Следит за тем, что ваше приложение всегда содержит нужное количество запущенных экземпляров

2. Хорошо подходит для Rolling updates3. Плохо подходит для Stateful приложений4. Есть проблемы с авто-масштабированием приложений

Недостатки Kubernetes

1. Сложно развернуть рабочий кластер своими руками2. Сложно настроить автоматическое горизонтальное

масштабирование3. Очень многое приходится делать в CLI4. Логика оркестрации скрыта в недрах Kubernetes5. Контейнер не является единицей управления

Docker Swarm

Docker Swarm

• Управляет узлами (Nodes) в кластере• Использует Docker APls для общения с Docker

Daemon на каждом узле• Может быть кластеризирован

Swarm Manager

• Отвечает за размещение контейнеров на узлах (Nodes)

• Pluggable architecture - Bring your own scheduler• Каждый Scheduler состоит из:

• Стратегии размещения• Списка фильтров

Scheduler

• Bin Packaging• Упаковывает узлы максимально полно

Scheduler - стратегии

Scheduler – Bin Packaging

• Bin Packaging• Упаковывает узлы максимально полно

• Spread • Распределяем равномерно

• Random• Обычно только для отладки

Scheduler - стратегии

• Affinity Filter• Constraint Filter • Health Filter – Выбирает только здоровые узлы• Port Filter

Scheduler - фильтры

1. Каждый Docker-host может иметь различный набор меток• OS, Storage (ssd, disk), kernel, env

2. Выбрать хост можно, указав критерий из меток• storage=ssd• region=us-east• environment=production

• Стандартные типы:• node ID or node Name (using key “node”)• storagedriver• executiondriver• kernelversion• operatingsystem

Constraint Filter

1. Affinity и anti-affinity правила• Помести db туда же, где и nginx• Помести db туда, где есть указанный

image• Не помещай контейнер, если

label==frontend2. Ограничения могут быть жесткими и

мягкими

Affinity filters

1. Поместить контейнер, только если на узле свободен определенный публичный порт. Например 80 или 443

Port filters

1. Можно объявить зависимости от уже существующих контейнеров1. Shared volumes2. Links3. Shared network stacks

Зависимости в фильтрах

• RAM• docker run -m 1g

• CPU• docker run -c 1

• Ports• docker run -p 80:80

Resource Management

• Token Based• etcd based• Zookeeper based• Consul Based• File Based• Bring your own?

Service Discovery

High Availability

• Multiple Swarm Managers• Похоже на Master-Master репликацию• При падении главного Master Manager,

выбирается новый Master• Работает только с

• Consul• Etcd• Zookeeper

• Требуется консенсус для корректного выбора нового Master

Requests Routing

• Нет стандартных паттернов• DIY

Как развернуть?

▪Вручную через Docker▪Docker machine▪OpenStack Magnum

Преимущества Swarm

1. Позволяет описать детально жизненный цикл вашего приложения

2. Управляем лучше, чем Kubernetes в части affinity & anti-affinity

3. Расширяемость4. Родной оркестратор для Docker

Недостатки Swarm

1. Сложно развернуть рабочий кластер своими руками2. Сложно настроить автоматическое горизонтальное

масштабирование3. Абсолютно все приходится делать через CLI 4. Нет возможности декларативно описать развертывание

приложения5. Нет встроенных health-checks6. Нет автоматического rescheduling при падениях узлов7. Только недавно вышел в Production

Спасибо!

Вопросы?@Jelastic & dl@jelastic.com