Обзор рынка оркестраторов Docker. Детальное технологическое сравнение Docker Swarm и Kubernetes. Обзор архитектуры и возможностей каждогого из них. Кто лучше справляется с построением масштабируемых микросервисных архитектур

1. Оркестратор Docker:
Swarm или Kubernetes
Дмитрий Лазаренко, Jelastic

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

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

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

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

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

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

8. Как бы вы строили приложение из 1000
узлов, не имея возможности зайти в его
админку? Вообще никогда.

9. Kubernetes

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

11. Что позволяет делать Kubernetes?
1. Вы декларативно описываете конфигурацию приложения (YAML)
2. Каждая группа компонент (Pod) именуется (Label)
3. Описываете какие группы компонент должны быть
продублированы, например сервис A запускать в 5 экземплярах
4. Kubernetes разворачивает указанную конфигурацию на
доступной инфраструктуре (Nodes)
5. Kubernetes следит за тем, чтобы текущая конфигурация
приложения всегда соответствовала эталонной
6. Есть встроенные health checks, на основе которых происходит
оценка здоровья приложения и замена больных Pod на новые
7. В итоге ваше приложение всегда имеет нужное количество
запущенных экземпляров

12. Архитектура Kubernetes
1. Master – Оркестратор
2. Nodes - рабочие сервера

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

14. Nodes
1. Каждый узел состоит из
набора Pod-ов
2. Каждый Pod состоит из
набора связанных
контейнеров
3. Pod, а не контейнер –
единица масштабирования
в Kubernetes
4. Kubernetes содержит
встроенные алгоритмы для
Anti-affinity

15. Volumes
1. Empty Dir
2. NFS
3. GCEPersistentDisk
4. awsElasticBlockStore
5. Glusterfs
6. Iscsi
7. Rbd
8. Secrets

16. Labels
1. Разметка вашей конфигурации. KEY/VALUE
2. “labels”: {
“tier”: “frontend”
“application.awesome-game/environment”: “production”
}

17. Label selector
1. Механизм запросов к Labels
2. tier != frontend, game = super-shooter-2
3. environment in (production, qa)
tier notin (frontend, backend)
partition

18. Replication controller
1. Несколько копий одного Pod называются репликами
2. Replication Controller следит за поддержанием заданного уровня
репликации Pod
3. Обеспечивает защиту от сбоев
4. Позволяет изменять label для конкретного Pod, таким образом
исключая его из репликации или проводить ZDT Rolling Updates
5. Масштабирование приложения происходит только вручную
через смену количества реплик для конкретного Pod

19. Services
1. Reverse-proxy
2. Проброс HTTP-запросов
из вне на PODы
3. Сервисы имеют
внешние IP
4. Простая Round-Robin
балансировка

20. Services

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

22. Health checking
▪ TCP Socket
▪ HTTP GET
▪ Container Exec
livenessProbe:
enabled: true
type: http
initialDelaySeconds: 30
httpGet:
path: /_status/healthz
port: 8080

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

24. Как развернуть?
▪ Local (Docker-based)
▪ Vagrant
▪ Local (No VM)
▪ Hosted Solution:
▪ Google Container Engine
▪ AWS
▪ Azure
▪ Mesosphere
▪ OpenStack Magnum/Murano

25. Преимущества Kubernetes
1. Следит за тем, что ваше приложение всегда содержит
нужное количество запущенных экземпляров
2. Хорошо подходит для Rolling updates
3. Плохо подходит для Stateful приложений
4. Есть проблемы с авто-масштабированием приложений

26. Недостатки Kubernetes
1. Сложно развернуть рабочий кластер своими руками
2. Сложно настроить автоматическое горизонтальное
масштабирование
3. Очень многое приходится делать в CLI
4. Логика оркестрации скрыта в недрах Kubernetes
5. Контейнер не является единицей управления

27. Docker Swarm

28. Docker Swarm

29. • Управляет узлами (Nodes) в кластере
• Использует Docker APls для общения с Docker Daemon
на каждом узле
• Может быть кластеризирован
Swarm Manager

30. • Отвечает за размещение контейнеров на узлах (Nodes)
• Pluggable architecture - Bring your own scheduler
• Каждый Scheduler состоит из:
• Стратегии размещения
• Списка фильтров
Scheduler

31. • Bin Packaging
• Упаковывает узлы максимально полно
Scheduler - стратегии

32. Scheduler – Bin Packaging

33. • Bin Packaging
• Упаковывает узлы максимально полно
• Spread
• Распределяем равномерно
• Random
• Обычно только для отладки
Scheduler - стратегии

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

35. 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

36. 1. Affinity и anti-affinity правила
• Помести db туда же, где и nginx
• Помести db туда, где есть указанный image
• Не помещай контейнер, если label==frontend
2. Ограничения могут быть жесткими и
мягкими
Affinity filters

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

38. 1. Можно объявить зависимости от уже
существующих контейнеров
1. Shared volumes
2. Links
3. Shared network stacks
Зависимости в фильтрах

39. • RAM
• docker run -m 1g
• CPU
• docker run -c 1
• Ports
• docker run -p 80:80
Resource Management

40. • Token Based
• etcd based
• Zookeeper based
• Consul Based
• File Based
• Bring your own?
Service Discovery

41. High Availability
• Multiple Swarm Managers
• Похоже на Master-Master репликацию
• При падении главного Master Manager, выбирается
новый Master
• Работает только с
• Consul
• Etcd
• Zookeeper
• Требуется консенсус для корректного выбора нового
Master

42. Requests Routing
• Нет стандартных паттернов
• DIY

43. Как развернуть?
▪ Вручную через Docker
▪ Docker machine
▪ OpenStack Magnum

44. Преимущества Swarm
1. Позволяет описать детально жизненный цикл вашего
приложения
2. Управляем лучше, чем Kubernetes в части affinity & anti-
affinity
3. Расширяемость
4. Родной оркестратор для Docker

45. Недостатки Swarm
1. Сложно развернуть рабочий кластер своими руками
2. Сложно настроить автоматическое горизонтальное
масштабирование
3. Абсолютно все приходится делать через CLI
4. Нет возможности декларативно описать развертывание
приложения
5. Нет встроенных health-checks
6. Нет автоматического rescheduling при падениях узлов
7. Только недавно вышел в Production

46. Спасибо!
Вопросы?
@Jelastic & dl@jelastic.com