Kubernetes vs Docker: в чем различия

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

Что такое Docker и Docker Swarm

Контейнеры позволяют упаковать приложение в единый образ, который можно запускать на любой системе, поддерживающей Docker. Это решает проблему несовместимости окружений, так как контейнеры гарантируют одинаковые условия  работы программы. Независимо от используемой операционной системы или аппаратного обеспечения.

У Docker есть собственный встроенный оркестратор Docker Swarm, который позволяет управлять кластером как единым логическим узлом. Swarm предоставляет возможности для работы с контейнерами в распределенной среде.

Некоторые особенности Swarm

• В Swarm приложение развертывается как сервис, который состоит из одной или нескольких задач. Сервисы можно масштабировать, изменяя количество задач.
• Swarm распределяет входящий трафик между контейнерами сервиса, обеспечивая равномерное распределение нагрузки.
• Swarm контролирует состояние задач и автоматически перезапускает их в случае сбоев или падений.

Хотя для сложных сценариев оркестрации чаще выбирают Kubernetes, Swarm остается популярным решением благодаря своей простоте и тесной интеграции с другими сервисами Docker.

Что такое Kubernetes

Это мощный инструмент для управления сложными распределенными приложениями. Рассмотрим основные компоненты Kubernetes.

Manaded Kubernetes

Отказоустойчивые и автомасштабируемые кластеры Kubernetes с гарантией доступности в облаке Selectel.

Корректно ли сравнивать Docker и Kubernetes

Сравнивать Kubernetes и Docker «лоб в лоб» не стоит. Первое решение — распределенная платформа оркестрации контейнеров, а второе — более низкоуровневое, которое чаще используется для сборки образов через Dockerfile и запуска контейнеров на одной машине. Поэтому корректнее будет рассматривать именно Kubernetes и Docker Swarm.

У обеих систем есть свои преимущества и особенности. Рассмотрим концептуальные различия между ними и выясним, когда следует использовать ту или иную систему, а также могут ли они работать вместе.

Архитектура

Архитектура Kubernetes состоит из множества компонентов. Рассмотрим некоторые из них подробнее. 

Kube-apiserver. С его помощью обеспечивается работа API кластера, обрабатываются REST-операции и предоставляется интерфейс, через который остальные компоненты взаимодействуют друг с другом. Помимо прочего, через Kube-apiserver проходят запросы на изменение состояния или чтение кластера. Работает на master-узлах.

Kube-scheduler. Определяет, на каких узлах разворачивать поды. По сути, это компонент-планировщик, который учитывает ограничения, требования к ресурсам, местонахождение данных и т. д. Работает на master-узлах.

Etcd. Распределенное хранилище в формате «ключ-значение». В нем хранится состояние всего кластера. Главная задача компонента — обеспечить отказоустойчивость кластера и консистентность данных. Развивается отдельно от Kubernetes как самостоятельный проект. Работает на master-узлах.

Kube-proxy. Управляет правилами балансировки нагрузки. Компонент конфигурирует правила IPVS или iptables, через которые выполняются проксирование и роутинг. Работает на worker-нодах.

Kube-controller-manager. Запускает работу контроллеров. Работает на master-нодах.

Kubelet. Cлужба управляет состоянием ноды: запуском, остановкой и поддержанием работы контейнеров и подов. Работает на worker-нодах.

Минимальная единица развертывания — под. Это группа контейнеров с общими разделами, которые запускаются как одно приложение. Есть поддержка пространств имен (namespaces) для логической изоляции ресурсов в пределах кластера. При этом состоянием кластера управляют мастер-узлы, которые также координируют рабочие узлы.

У Swarm более простая архитектура, которая легко интегрируется с существующей установкой Docker. Основные единицы оркестрации — это сервисы, состоящие из задач. Схема реализации узлов почти такая же, как и в Kube: мастер-узлы управляют состоянием кластера и распределением задач, а воркеры выполняют контейнеры.

Установка и настройка

Установка Kubernetes требует немало усилий, так как нужно настроить множество компонентов и конфигураций. Существует несколько инструментов для упрощения установки, например kubeadm и kOps. Но есть и более легкие в настройке и освоении инструменты, например microk8s, k3s или talos.

Swarm настраивается легко: достаточно включить соответствующий режим на узлах с помощью простой команды docker swarm init.

Масштабируемость и управление

Kubernetes подходит для управления крупномасштабными кластерами. Также можно настроить автомасштабирование, хотя «из коробки» такая опция не предусмотрена. Ее необходимо подключать самостоятельно, используя репозиторий с GitHub. Либо можно обратиться к услугам провайдера IT-инфраструктуры — в облаке Selectel реализована поддержка автомасштабирования Kubernetes на основе метрик.

У K8s мощные инструменты для управления ресурсами (quotas, limit ranges). Swarm же хорошо справляется с меньшими кластерами и не обладает столь мощными инструментами для масштабирования, поэтому подходит для небольших проектов.

Развертывание и управление приложениями

В Kubernetes для развертывания и управления используется как встроенный kubectl, так и Helm. Возможности Swarm в этом плане менее гибкие, однако здесь можно использовать стандартные команды Docker. Будет существенным плюсом для тех, кто уже знаком с этим ПО.

Экосистема и интеграции

Kubernetes поддерживает интеграцию с большим количеством сторонних решений, таких как мониторинг, логирование, CI/CD, и т. д. Также Kubernetes является Cloud-native, ведь его поддерживают облачные провайдеры и он включает в себя инструменты для управления облачными ресурсами.

Хотя Swarm интегрируется с экосистемой Docker, поддержка сторонних инструментов и решений менее развита. При этом Swarm больше подходит для локального развертывания и небольших проектов в облаке.

Что в Kubernetes реализовано лучше, чем в Docker

Рассмотрим, как в Kubernetes и Docker Swarm реализованы настройка контейнера, балансировка нагрузки, автоматизация управления, мониторинг и ряд других функций.

Настройка контейнера

Swarm поддерживает большинство инструментов Docker, однако проблемы возникают в случаях, когда Docker API не может выполнить необходимую операцию. Простых и удобных решений пока что нет.

Например, вы управляете кластером контейнеров, который работает с микросервисной архитектурой, и каждый сервис требует сложных сетевых конфигураций и динамического масштабирования на основе определенных метрик. В начале нужно развернуть Swarm-кластер и запустить сервисы. Это не сложно, но вскоре станет очевидной необходимость изоляции трафика и применения сложных сетевых политик.

В Swarm их настройки ограничены. Это приводит к сложностям в реализации строгих правил межсервисного взаимодействия и изоляции сетевого трафика. Если нужно определить, какой трафик может проходить между различными группами сервисов, у пользователя не будет необходимых инструментов для детального контроля на уровне кластера.

Swarm позволяет масштабировать сервисы, но у него нет встроенных возможностей, чтобы делать это автоматически на основе конкретных метрик, таких как нагрузка на CPU или память. Если сервисам требуется автоматическое масштабирование на основе этих метрик, Swarm не предоставит такой возможности. И в этом случае выручит Kubernetes.

Он предлагает Network Policies для управления трафиком на уровне подов. Это обеспечивает изоляцию и безопасное взаимодействие между компонентами. А также Kubernetes поддерживает Horizontal Pod Autoscaler, который может автоматически масштабировать количество реплик на основе метрик, таких как нагрузка на процессор, память и т. д.

Кроме того, у Kubernetes есть собственные API и определения клиентов, однако совместимость с Docker CLI и Docker Compose исключена. При этом настройка контейнеров в K8s удобнее благодаря поддержке автоматического масштабирования, самовосстановлению и интеграции с различными системами хранения.

Балансировка нагрузки

У Swarm есть только один DNS-элемент, который позволяет распределять входящие запросы по именам служб. Имена при этом назначаются автоматически или настраиваются на определенных портах.

Kubernetes предоставляет более гибкие и эффективные возможности для балансировки нагрузки. Это обусловлено поддержкой разнообразных внешних балансировщиков, а также интеграцией с облачными решениями для автоматического управления трафиком. Для балансировки в Kubernetes часто применяют Ingress, однако возможны и другие варианты реализации — например, Service Mesh.

Модель плоской сети

В Kubernetes каждый модуль может взаимодействовать с любым другим, а характер таких взаимодействий гибко настраивается в сетевых политиках. Для реализации подобной модели необходимы два CIDR: внутренний для сервисов и внешний для получения IP-адресов. Такая схема хорошо показывает себя в проектах с микросервисной архитектурой, где требуется сложное взаимодействие между большим количеством сервисов и их динамическое масштабирование.

В Swarm сетевая модель реализована иначе: узел, соединяющийся с кластером, используется для генерации оверлейной сети, которая охватывает все хосты. Такая схема подойдет проектам, где все узлы находятся в пределах одного или нескольких дата-центров и требуется простое объединение ресурсов. Swarm обеспечивает автоматическое создание и управление сетями между узлами.

Автоматизация оперативного управления

Для автоматизации оперативного управления в K8s есть гибкий контроллер kubectl, реализованный в виде командной строки. Это позволяет гибко настраивать работу контейнеров по заданным условиям.

В Swarm такого инструмента нет, поэтому тем, кто работает с Docker, стоит рассмотреть интеграцию с Kubernetes, если проект достаточно масштабный.

Абстрагирование от инфраструктуры

Kubernetes самостоятельно управляет базовой инфраструктурой проекта, что позволяет разработчикам заниматься непосредственно работой с кодом. В Docker Swarm ограничены возможности автоматического управления вычислительными и сетевыми ресурсами.

Мониторинг состояния сервисов

Kubernetes контролирует состояние среды выполнения в автоматическом режиме, самостоятельно проверяет доступность сервисов и перезапускает контейнеры при проблемах. Доступ предоставляется только к запущенным и стабильным сервисам.

В Docker Swarm по умолчанию нет автоматизации — нужна интеграция со сторонним ПО для мониторинга состояния сервисов. Однако в таких сценариях тоже остаются некоторые ограничения. 

Например, для мониторинга состояния сервисов и контейнеров настраивают интеграции Swarm с Prometheus и Grafana. Это требует значительных усилий. В отличие от Kubernetes, где автоматизация мониторинга встроена в платформу (например, через Prometheus Operator), в Docker Swarm придется вручную настраивать сбор метрик, их хранение и визуализацию.

Единое управление всеми узлами

В кластере Kubernetes может быть много узлов и контейнеров, которые поддерживают разные политики доступа. Однако все они легко управляются через основной сервер, а централизацию обеспечивает API оркестратора. За счет этого, например, при отправке команды на обновление сервиса, Kubernetes самостоятельно найдет его ноду и обновит.

В Docker реализация менее гибкая. При наличии нескольких узлов в кластере централизованное управление невозможно, поскольку узлы ничего не знают друг о друге. Так что при разветвленном кластере лучшим выбором будет именно Kubernetes.

Управление конфигурациями и конфиденциальными данными

Есть два полезных инструмента Kubernetes — ConfigsMaps и Secrets. Благодаря централизованному управлению настройки каждого приложения доступны из любой ноды кластера.

В Docker нет полноценного централизованного управления кластером. Все настройки конфигурации и конфиденциальности приходится выполнять в ручном режиме.

Автомасштабирование узлов

В Kubernetes можно подключить и настроить автомасштабирование. В инструменте есть настройки для автоподключения новых нод при увеличении нагрузки, а также их автоматическое отключение при ее снижении.

У контейнеров Docker нет функций для автоматического масштабирования. Из этого следует, что Docker-daemon не в состоянии отслеживать нагрузку нод и подключать новые при необходимости.

Обновления приложений и откаты

Kubernetes поддерживает полноценные Rolling-Updates, в том числе сложные сценарии развертывания, пошаговые обновления и автоматические откаты. Для релиза свежей версии приложения потребуется лишь указать ее в файле Deployment. Также Deployment поддерживает и обновления по типу, а откаты выполняются простой командой rollout, после чего Kubernetes все делает автоматически.

В Docker подобной автоматизации нет. Каждый контейнер нужно обновлять в индивидуальном порядке, причем для этого приходится искать каждый узел с развернутым приложением и затем поочередно обновлять их.

Система хранения данных

Объекты PersistentVolume и PersistentVolumeClaim значительно упрощают работу с дисками в Kubernetes. Благодаря этим инструментам настройка томов выполняется всего один раз, после чего каждый контейнер может запрашивать ресурсы без дополнительных настроек.

Тома (Volumes) в Docker требуют индивидуальной настройки для каждого контейнера. Хранилище придется подключать последовательно к каждой ноде, после чего — монтировать том в каждый контейнер.

Когда использовать Kubernetes, а когда — Docker Swarm

Рассмотрим, в каких случаях лучше использовать Kubernetes.

• Если ваше приложение состоит из множества микросервисов. Kubernetes предоставляет мощные инструменты для управления взаимодействиями, автоматического масштабирования и балансировки нагрузки.
• Если вам нужны строгие меры безопасности и детальное управление доступом. Kubernetes предлагает расширенные возможности сетевых политик и управление доступом на основе ролей (RBAC).
• Если вы используете облачные платформы. Архитектура Kubernetes позволит обеспечить полноценную интеграцию с облачными сервисами.

Теперь взглянем, кому подойдет Docker Swarm.

• Небольшим проектам, где важна скорость развертывания и простота управления. Swarm требует меньше времени на настройку и обучение.
• Небольшим командам, в которых нет выделенных специалистов по DevOps. Освоить и использовать базовые функции оркестрации Swarm легче, чем сложные возможности Kubernetes.
• Проектам, где все узлы и ресурсы находятся в пределах одного дата-центра.

Могут ли Kubernetes и Docker Swarm работать вместе

Поскольку обе системы являются оркестраторами, их совместное использование в большинстве случаев нецелесообразно. Однако есть сценарии, когда Kubernetes и Docker Swarm неплохо дополняют друг друга.

Миграция приложений с Docker Swarm на Kubernetes. Разработчики создают новый кластер Kubernetes и переносят микросервисы, оставляя старые монолитные приложения под управлением Docker Swarm. Это позволяет изучать и настраивать Kubernetes, не прерывая работу всех приложений.

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

Чем поможет Managed Kubernetes в Selectel

Вот что еще предлагает Managed Kubernetes.

• Всегда актуальные версии K8s. Мы одни из первых, кто обновляет версии Kube и всегда поддерживает их актуальность.
• Доступные цены и оплату по модели pay-as-you-go, то есть за фактически потребленные ресурсы.
• Экосистему сервисов и простую интеграцию с другими сервисами Selectel для построения cloud-native сервисов и архитектуры приложений с широким выбором инфраструктурных продуктов.
• Ускорение релизов за счет полноценной поддержки инструментов CI/CD.
• Ускорение вычислений, проведение ML-экспериментов и анализ больших данных в производительных кластерах с GPU.