Downloaded 21 times
Uploaded byDmitry Lazarenko
Docker Containers orchestrators: Kubernetes vs. Swarm
Документ сравнивает оркестраторы контейнеров Docker Swarm и Kubernetes, описывая их архитектуры, функциональности и преимущества. Kubernetes предлагает мощные функции автоматизации и управления, такие как декларативное описание конфигураций и встроенные проверки состояния, но имеет сложности в настройке и использовании CLI. Docker Swarm, в свою очередь, более интуитивен для разработчиков, но ограничен в функционале и требует много ручной работы.
More Related Content
![[ISC] Docker + Swarm](https://cdn.slidesharecdn.com/ss_thumbnails/docker-170331122353-thumbnail.jpg?width=640&height=640&fit=bounds)
Docker Containers orchestrators: Kubernetes vs. Swarm
- 1. Оркестратор Docker: Swarm илиKubernetes Дмитрий Лазаренко, Jelastic
- 2.
- 3.
- 4.
- 5. Контейнеры могут быть спасениемдля разработчиков
- 6. Но это нетривиально…
- 7. Но это нетривиально…
- 8. Как бы выстроили приложение из 1000 узлов, не имея возможности зайти в его админку? Вообще никогда.
- 9.
- 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.
- 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.
- 21. Service Discovery • Переменныеокружения из Pod появляются на Node • Cluster DNS- Специальный Pod Etcd – хранение конфигурации SkyDns – DNS-сервер, читающий из Etcd Kube2sky –публикует актуальную информацию из Kubernetes Master в Etcd
- 22. Health checking ▪ TCPSocket ▪ 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.
- 28.
- 29. • Управляет узлами(Nodes) в кластере • Использует Docker APls для общения с Docker Daemon на каждом узле • Может быть кластеризирован Swarm Manager
- 30. • Отвечает заразмещение контейнеров на узлах (Nodes) • Pluggable architecture - Bring your own scheduler • Каждый Scheduler состоит из: • Стратегии размещения • Списка фильтров Scheduler
- 31. • Bin Packaging •Упаковывает узлы максимально полно Scheduler - стратегии
- 32. Scheduler – BinPackaging
- 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 • dockerrun -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 • MultipleSwarm 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.