АРХИТЕКТУРА DOCKER И ТЕХНОЛОГИИ ОРКЕСТРОВКИ: DOCKER SWARM И KUBERNETES

Docker – это платформа, которая позволяет «создавать, поставлять и запускать любое приложение повсюду». Он нужен для более эффективного использование системы и ресурсов, быстрого развертывания готовых программных продуктов, а также для их масштабирования и переноса в другие среды с гарантированным сохранением стабильной работы.

Основной принцип работы Docker — контейнеризация приложений. Этот тип виртуализации позволяет упаковывать программное обеспечение по изолированным средам — контейнерам. Каждый из этих виртуальных блоков содержит все нужные элементы для работы приложения. Это дает возможность одновременного запуска большого количества контейнеров на одном хосте. Например, если программа написана на операционной системе windows, то с помощью docker мы можем запустить его в операционных системах macOS или Linux без необходимости вносить изменения в код и без никаких потерь. [1]

Работа Docker основана на принципах клиент-серверной архитектуры, которая основана на взаимодействии клиента с веб-сервером (хостом). Первый отправляет запросы на получение данных, а второй их предоставляет. Docker на хост­компьютере пользователя, обычно бывает разделен на две части: демон с прикладным программным интерфейсом RESTful и клиент, который общается с демоном по протоколу HTTP. Пользователь вызывает Docker ­клиент, чтобы получить информацию или дать инструкции демону. Демон  Docker – это сервер, который получает запросы и возвращает ответы от клиента по протоколу HTTP. В свою очередь, он будет отправлять запросы в другие службы для отправки и получения образов, также используя протокол HTTP. Сервер будет принимать запросы от клиента командной строки или любого, кто авторизован для подключения. Демон также отвечает за заботу о образах пользователя и контейнерах за кулисами, тогда как клиент выступает в качестве посредника между пользователем и интерфейсом RESTful. Существует еще частный реестр Docker. Это сервис, который хранит образы Docker. Его можно запросить у любого демона Docker, у которого есть соответствующий доступ. Этот реестр находится во внутренней сети и не является общедоступным, поэтому считается закрытым. Хост-компьютер пользователя, на котором установлен Docker, обычно находится в частной сети. Демон Docker станет обращаться к интернету, чтобы получить образы по запросу. Реестром, выбираемым по умолчанию, является Docker Hub. это общедоступный реестр, управляемый Docker Inc. В интернете также могут существовать другие публичные реестры, и ваш демон Docker способен взаимодействовать с ними. Ключевой момент заключается в том, что, когда пользователь запускаете Docker на своем компьютере, он может взаимодействовать с другими процессами на компьютере или даже со службами, работающими в сети пользователя или в интернете. [2]

Оркестровка и управление кластером – при развертывании большого количества контейнеров весьма важно наличие инструментов для контроля и управления всей системой в целом. Каждый новый контейнер должен быть размещен на некотором хосте, его нужно контролировать и обновлять. Система должна правильно реагировать на сбои или изменения нагрузки, перемещая, запуская или останавливая контейнеры соответствующим образом. Здесь можно отметить несколько конкурирующих решений, которые мы сегодня рассмотрим: Kubernetes от Google, а также собственный инструмент Docker Swarm.

Swarm представляет собой инструментальное средство компании Docker для кластеризации собственных контейнеров. Swarm использует стандартный прикладной программный интерфейс Docker API, поэтому контейнеры можно запускать обычными командами docker run, а Swarm позаботится о выборе подходящего хоста для каждого запускаемого контейнера. Это также означает, что другие инструменты, использующие Docker API, такие как Compose и специальные скрипты, могут использовать Swarm без каких-либо изменений и получить все преимущества кластера, по сравнению с работой на одном хосте. Базовая архитектура Swarm проста и понятна: на каждом хосте запускается агент (agent) Swarm, а на отдельном хосте запускается менеджер (manager) Swarm (в небольшом тестовом кластере этот хост может функционировать и как агент). Менеджер отвечает за оркестрацию и планирование работы контейнеров, распределенных по хостам. Предлагается несколько различных методик обнаружения хостов и добавления их в кластер, в Swarm они обозначены как механизм обнаружения (discovery). По умолчанию используется обнаружение на основе токена (token-based discovery), при котором адреса хостов содержатся в списке, хранящемся в реестре Docker Hub. Когда менеджер запускается, он инициализирует некое состояние для роя, а затем прослушивает входящие соединения от дополнительных узлов, чтобы добавить их к рою. В режиме swarm есть часть дополнительных функций, включенных по умолчанию, которые называются сеткой маршрутизации. Она позволяет каждому узлу в рое выглядеть так, как будто он может обслуживать запросы для всех служб в рое, у которых есть опубликованные порты, – все входящие соединения перенаправляются на соответствующий узел. Например, если пользователь снова вернетесь на узел менеджера h1 (который, как мы знаем, не запускает службу, поскольку имеет доступность типа drain), он все равно будет отвечать на любые запросы на порту 8000. Это может быть особенно полезно для простого вида обнаружения службы – если пользователь знает адрес одного узла, может очень легко получить доступ ко всем своим службам. [3]

Достоинства и недостатки Docker Swarm:

Достоинства:

1. Простая установка, которая подойдет тем, кто только начинает знакомство с оркестрацией контейнеров.
2. Небольшой вес и высокая производительность.
3. Является нативным оркестратором для Docker и полностью интегрирован с Docker Engine. Не требует дополнительных компонентов, кроме самого docker-engine.
4. Является проектом с открытым исходным кодом, что позволяет пользователям адаптировать и модифицировать его под свои нужды.
5. Поддерживает docker-compose и другие инструменты для разработки и развертывания приложений.

Недостатки:

1. Имеет ограниченный функционал из-за сильной привязки к Docker API.
2. Малое количество сторонних плагинов.
3. Максимальное число менеджеров = 7.
4. Ручное масштабирование.

Kubernetes – это инструментальное средство оркестрации контейнеров, созданное компанией Google и основанное на опыте использования контейнеров в течение более десяти лет. Kubernetes неизменно поддерживает и продвигает несколько концепций организации контейнеров и создания сетевой среды для них. Вначале рассмотрим его архитектуру. Kubernetes имеет архитектуру master­minion. Главные узлы отвечают за получение приказов о том, что следует запускать в кластере, и оркестровку его ресурсов. На каждом «ставленнике» (minion) установлен Docker, а также служба kubelet, которая управляет модулями (наборами контейнеров), запущенными на каждом узле. Информация о кластере хранится в etcd, распределенном хранилище данных типа «ключ/значение», и это – источник истины кластера. Конечная цель Kubernetes – сделать так, чтобы контейнеры пользователя работали в масштабе, просто объявив, что пользователь хочет, и предоставив Kubernetes возможность обеспечить соответствие кластера потребностям пользователя. Ниже приводится краткое описание самых главных концепций: [4]

1) pods – группы контейнеров, которые развертываются и планируются совместно. В Kubernetes такие группы образуют неделимую единицу планирования в противоположность отдельным контейнерам в других системах. Группа обычно содержит от 1 до 5 контейнеров, совместно обеспечивающих работу некоторого сервиса.

2) flat networking space – в Kubernetes функционирование сетевой среды значительно отличается от работы сети с Docker-шлюзом, принимаемой по умолчанию. В сетевой среде Docker по умолчанию контейнеры существуют в закрытой подсети и не могут напрямую обмениваться данными с контейнерами на других хостах без перенаправления портов на хосте или без использования механизма прокси. В Kubernetes контейнеры в одной группе (pod) совместно используют один IP-адрес, но все адресное пространство является «плоским» для всех групп (pods), таким образом, все группы (pods) могут обмениваться информацией друг с другом без какого-либо преобразования сетевых адресов (NAT).

3) abels – ярлыки представляют собой пары ключ-значение, закрепленные за объектами в Kubernetes, в основном за группами (pods), и используемые для определения идентификационных характеристик объекта (например, version:devилиtier:frontend). Обычно ярлыки могут быть повторяющимися, предполагается, что они идентифицируют группы контейнеров.

4) services – сервисы являются стабильными точками входа, к которым можно обращаться по имени. Сервисы могут устанавливать соединения с группами контейнеров (pods), используя селекторы ярлыков. Например, сервис пользователя cache может установить соединение с несколькими группами (pods) redis, определяемыми по селектору ярлыка"type":"redis". Этот сервис будет автоматически посылать циклические запросы, распределяемые по заданным группам (pods). Таким образом, сервисы можно использовать для соединения различных частей системы.

Достоинства и недостатки Kubernetes:

Достоинства:

1. Имеет практически неограниченный функционал. Небольшой вес и высокая производительность.
2. Обеспечивает автоматическое восстановление при сбоях, перезапуская контейнеры и перенося их на другие узлы. Является проектом с открытым исходным кодом, что позволяет пользователям адаптировать и модифицировать его под свои нужды.
3. Доступен в большинстве облачных провайдеров, в том числе и в Timeweb Cloud.
4. Автоматизирован и поддерживает автомасштабирование приложений.
5. Имеет большое и активное пользовательское сообщество.

Недостатки:

1. Сложный в установке и настройке.
2. Требует много времени для обучения и освоения.
3. Требует значительного объема ресурсов для развертывания и управления кластером.
4. Настройка сети в Kubernetes может быть сложной задачей, особенно при использовании множества подсетей и различных провайдеров сетевых решений.
5. Расширенный функционал требует установки дополнительных плагинов от сторонних разработчиков.

Сравнение Docker Swarm vs Kubernetes по критериям:

1. Установка и настройка: Docker Swarm более прост и быстр в установке чем kubernetes.
2. Ресурсные требования: у Docker Swarm более низкие ресурсные требования чем у kubernetes.
3. Поддерживаемые типы контейнеров: Docker Swarm поддерживает только docker, а kubernetes: Containerd, Docker, CRI-O и другие.
4. Масштабируемость: Docker Swarm использует ручное масштабирование, а Kubernetes автоматическое.
5. Балансировка нагрузки: у Docker Swarm встроенная автоматическая балансировка нагрузки, а у Kubernetes балансировка нагрузки отсутствует. Она интегрируется с помощью сторонних инструментов.
6. Мониторинг: у Docker Swarm мониторинг отсутствует. Он интегрируется с помощью сторонних инструментов, а Kubernetes использует встроенный мониторинг.
7. Управление сетью: Docker Swarm имеет ограниченные возможности, в то же время Kubernetes имеет широкий набор инструментов и возможностей.
8. Графический интерфейс: Kubernets предоставляет веб-интерфейс Kubernetes Dashboard, который облегчает процесс управления и мониторинга кластера. В отличие от Kubernetes, Docker Swarm не имеет собственного графического интерфейса. Однако существуют сторонние инструменты для этих целей. Например: Portainer, SwarmUI, Shipyard.
9. Сообщество и поддержка: Docker Swarm имеет меньшее количество пользователей и разработчиков, ограниченные ресурсы. Kubernetes имеет большое и активное сообщество, обширную поддержку и документацию.
10. Для кого подойдет: Docker Swarm больше подходит для малых и средних проектов, команд с небольшим опытом, простых приложений. А Kubernets больше подходит для крупных и сложных проектов, команд с опытом, сложных и высоконагруженных приложений. [4]

ЗАКЛЮЧЕНИЕ

В представленной читателю статье была рассмотрена информация об архитектуре докер, а также технологиях оркестровки docker swarm и kubernetes. Проанализированы преимущетсва и недостатки работы docker swarm и kubernetes, и было проведено их сравнение по критериям.