Аппаратная виртуализация предоставляет ряд преимуществ, таких как масштабируемость, безопасность, изоляция и т. д., используя гипервизоры для разделения физического оборудования с виртуальными машинами (ВМ). В настоящее время виртуальные машины не являются единственной формой виртуализации, так как контейнеры также стали довольно популярными. В то время как ВМ разделяют физическое оборудование базовых машин, контейнеры разделяют ядро базовой операционной системы. Контейнеры не являются легковесными виртуальными машинами, но являются стандартизированными исполняемыми пакетами, используемыми для доставки приложений, включая приложения, разработанные с использованием архитектуры программного обеспечения на основе микросервисов, и содержат все компоненты, необходимые для запуска приложений.
Движок Docker является самой популярной платформой для запуска контейнеров. Kubernetes – это термин, который вы можете услышать с увеличивающейся частотой в сфере контейнеризации и облачных вычислений. Но что лучше – Docker или Kubernetes? Это популярная тема дискуссии, но сформулировать её таким образом технически некорректно. Например, вы не можете спросить: “Что лучше – горячее или синее?”
Что такое Docker?
Docker – это открытое автономное приложение, которое работает как движок, используемый для запуска контейнеризованных приложений. Оно устанавливается на вашу операционную систему (ОС), предпочтительно на Linux, но также может быть установлено на Windows и macOS, которые, в свою очередь, работают на физической или виртуальной машине.
Приложение, запущенное в контейнере, изолировано от остальной системы и от других контейнеров, но создает иллюзию работы в собственном экземпляре ОС. Несколько контейнеров Docker могут работать на одной операционной системе одновременно; вы можете управлять этими контейнерами с помощью Docker, и Docker может работать без Kubernetes. Если у вас есть несколько хостов для запуска контейнеров, управление ими вручную может быть сложным, и в целом лучше выбрать централизованный инструмент управления или решение для оркестрации.
Docker Compose – это базовый инструмент оркестрации контейнеров, используемый для запуска многоконтейнерных приложений Docker. Вы можете настроить один файл конфигурации Docker Compose в формате YAML (yml), чтобы определить многоконтейнерные приложения, вместо того чтобы настраивать отдельные файлы Dockerfiles для каждого контейнера вручную. После настройки одного файла YAML вы можете запустить все необходимые контейнеры одной командой в вашей консоли Linux. Использование Docker Compose – это один из способов оркестрировать ваши контейнеры Docker, но существует мощная альтернатива Docker Compose, называемая Kubernetes.
Что такое Kubernetes?
Kubernetes – это решение для оркестрации контейнеров с открытым исходным кодом, используемое для управления контейнеризированным программным обеспечением и услугами с высокой степенью автоматизации.
Kubernetes – это проект Google, предназначенный для автоматизации развертывания, масштабирования и обеспечения доступности приложений, работающих в контейнерах. Вы можете увеличить количество хостов, на которых работают контейнеры, до 11 или более хостов. Более того, вы можете создать кластер контейнеров Docker с помощью Kubernetes, чтобы обеспечить высокую доступность и балансировку нагрузки.
Хосты, используемые в кластере, называются узлами. Тип архитектуры Kubernetes – мастер-слейв: кластер состоит из узлов-мастеров и рабочих узлов. Минимальное рекомендуемое количество узлов, необходимых для Kubernetes, – четыре. Хотя вы можете создать кластер с одной машиной, для запуска всех примеров и тестов вам понадобится как минимум четыре узла. Кластер Kubernetes, обрабатывающий производственный трафик, должен иметь как минимум три рабочих узла. Использование двух узлов-мастеров обеспечивает защиту кластера от отказа одного узла-мастера. При необходимости можно использовать более двух узлов-мастеров.
- Узлы-мастеры используются для управления состоянием кластера, включая принятие запросов клиентов, планирование операций с контейнерами, выполнение контрольных циклов и т. д. На каждом узле-мастере должна выполняться копия базы данных etcd, которая хранит все данные кластера. Узел-мастер запускает набор из трех процессов: kube-apiserver, kube-controller-manager и kube-scheduler.
- Рабочие узлы используются для выполнения рабочих нагрузок приложений путем запуска контейнеров. На не-мастер-узле выполняются два процесса Kubernetes: kubelet (для связи с узлами-мастерами) и kube-proxy (для отражения сетевых служб Kubernetes на каждом узле).
- Контроллер репликации – это компонент, используемый для обеспечения того, чтобы реплики Pod, количество которых указано, всегда работали в любой момент времени. Таким образом, вы можете убедиться, что Pod всегда доступны, когда вам это нужно.
Если используется Kubernetes, для взаимодействия служб друг с другом используются различные CLI и API. Также существуют специфические термины, которые используются для именования объектов и ресурсов RESTful API, которые являются компонентами кластера, построенного с использованием Kubernetes. - Pod – это основная единица планирования в Kubernetes. Это группа ресурсов, в которой могут работать несколько контейнеров. Контейнеры, принадлежащие одному Pod, могут запускаться на одном и том же хосте и использовать одни и те же ресурсы и локальную сеть. Контейнеры в Pod изолированы, но могут легко общаться друг с другом. Таким образом, Pod обычно используются в Kubernetes, но если вы используете автономное приложение Docker, доступны только пулы контейнеров.
- Служба – это набор контейнеров, которые работают вместе, обеспечивая, например, функционирование многоуровневого приложения. Kubernetes поддерживает динамическое именование и балансировку нагрузки Pod, используя абстракции. Такой подход обеспечивает прозрачное соединение между службами по имени и позволяет отслеживать их текущее состояние.
- Метки – это пары ключ/значение, привязанные к Pod и другим объектам или службам, позволяющие легко группировать и назначать задачи.
- Пространства имен – это метод, который позволяет логически разделять объединенный кластер Kubernetes на несколько виртуальных кластеров. Каждый виртуальный кластер может существовать в виртуальной среде, ограниченной квотами, без влияния на другие виртуальные кластеры.
Kubernetes можно использовать с Docker, хотя Docker не единственная платформа контейнеров, с которой можно использовать Kubernetes. Kubernetes также может работать в сочетании с контейнерами Windows, контейнерами Linux, rkt и т. д. K8s – это название Kubernetes, которое иногда можно найти в технической документации.
Сравнение Kubernetes и Docker: сетевое сравнение
Давайте рассмотрим варианты сетевого взаимодействия для каждого решения.
Docker предоставляет три режима сети для сетевого взаимодействия между контейнерами.
Мост. Этот режим используется по умолчанию, создавая виртуальный мост уровня 3. Имя сети на вашем хосте для этой сети – docker0. Docker автоматически создает мост сети уровня 3 и настраивает правила маскарадинга для внешнего сетевого интерфейса, используя принцип сетевого адресного перевода (NAT), что позволяет контейнерам взаимодействовать друг с другом и подключаться к внешним сетям. Вы можете настроить перенаправление портов для сетевого интерфейса хост-машины, если хотите подключиться к контейнеру с других хостов и внешних сетей. Таким образом, подключаясь к соответствующему порту хост-машины, вы перенаправляетесь на необходимый порт контейнера Docker. Вы можете создать более одного сетевого интерфейса для контейнера Docker при необходимости.
Хост. В этом режиме драйвер сети хоста обеспечивает, чтобы контейнер не был изолирован от хоста Docker. Контейнер разделяет стек сети хоста, а имя хоста контейнера совпадает с именем хоста операционной системы хоста. Если вы запускаете контейнер, на котором прослушивается TCP-порт 8080, приложение контейнера доступно на TCP-порту 8080 IP-адреса хост-машины. Драйвер сети хоста доступен только для машин Linux.
Нет. Для сетевого интерфейса контейнера не настроены IP-адреса, кроме адреса 127.0.0.1 для интерфейса обратной связи. Нет доступа к внешним сетям, если установлен режим сети Нет.
Многохостовая сеть для контейнеров Docker. Если контейнеры работают на разных хостах, они могут взаимодействовать друг с другом после настройки наложения сетей. Для создания таких сетей должен быть настроен действительный сервис хранения пар ключ-значение (Consul, Etcd или ZooKeeper).
Кубернетес. Если вы используете автономные контейнеры Docker, каждый контейнер можно рассматривать как базовую единицу, которая взаимодействует через сеть, используя соответствующий сетевой интерфейс. Если вы используете Kubernetes, Поды являются базовыми единицами контейнерного кластера. У каждого пода есть свой собственный IP-адрес и состоит как минимум из одного контейнера. Под может состоять из нескольких контейнеров, которые используются для связанных задач. Контейнеры одного и того же Пода не могут одновременно открывать один и тот же порт. Этот тип ограничения используется, потому что Под, состоящий из нескольких контейнеров, все еще имеет один IP-адрес.
Кроме того, Kubernetes создает специальный контейнер pause container для каждого Пода. Этот специальный контейнер предназначен для предоставления сетевого интерфейса (для внутреннего и внешнего общения) для других контейнеров и обычно находится на паузе (в режиме сна). Эти контейнеры-паузы пробуждаются, когда Kubernetes отправляет сигнал «SIGTERM».
Flannel обычно используется в качестве сетевой ткани для подключения контейнеров в Kubernetes с использованием принципов сетевого оверлея. Оверлейное сетевое взаимодействие позволяет запускать контейнеры, обмениваясь логической сетью между различными физическими хостами кластера (которые называются узлами). Для сохранения соответствий между реальными IP-адресами, назначенными контейнерам хостами, на которых запущены контейнеры, и IP-адресами в оверлейной сети используется хранилище ключей/значений etcd с открытым исходным кодом.
Сетевое взаимодействие Kubernetes можно интегрировать с VMware NSX-T с помощью плагина контейнера NSX. Эта интеграция позволяет использовать многопользовательскую сетевую топологию, которая недоступна “из коробки” в Kubernetes.
Модель сетевого взаимодействия Kubernetes предоставляет следующие возможности:
- Все контейнеры могут обмениваться данными с любыми другими контейнерами внутри кластера без использования NAT.
- Все узлы кластера могут обмениваться данными со всеми контейнерами внутри кластера без использования NAT. Обратно, все контейнеры могут взаимодействовать со всеми узлами кластера.
- Контейнеры видят свои собственные IP-адреса, и эти IP-адреса видны другим компонентам Kubernetes.
Ингресс – это объект API Kubernetes, который используется для управления доступом к сервисам в кластере снаружи (в основном по протоколам HTTP и HTTPS). Вы можете настроить Ингресс для обеспечения внешнего доступа к контейнеризованным сервисам, для балансировки нагрузки, завершения SSL и виртуального хостинга на основе имен. Контроллер Ингресса должен быть развернут на главном узле, чтобы правила ингресса работали.
Сценарии использования
Использование Docker в качестве автономного программного обеспечения хорошо подходит для разработки приложений, поскольку разработчики могут запускать свои приложения в изолированных средах. Кроме того, тестировщики также могут использовать Docker для запуска приложений в песочнице. Если вы хотите использовать Docker для запуска большого количества контейнеров в производственной среде, вы можете столкнуться с некоторыми сложностями по пути. Например, некоторые контейнеры могут легко перегружаться или завершаться с ошибкой. Вы можете вручную перезапустить контейнер на соответствующей машине, но ручное управление может занимать много вашего ценного времени и энергии.
Кубернетес позволяет решать эти проблемы, предоставляя ключевые функции, такие как высокая доступность, балансировка нагрузки, инструменты оркестрации контейнеров и т. д. В результате Кубернетес наиболее подходит для высоконагруженных производственных сред с большим количеством контейнеров Docker. Развертывание Кубернетеса сложнее, чем установка автономного приложения Docker, поэтому Кубернетес не всегда используется для разработки и тестирования.
Кубернетес против Docker Swarm
Docker Swarm – это средство нативной кластеризации для Docker, которое может превратить пул хостов Docker в единый виртуальный хост. Docker Swarm полностью интегрирован с движком Docker и позволяет использовать стандартные API и процессы сетевого взаимодействия; его цель – развертывание, управление и масштабирование контейнеров Docker.
Swarm – это кластер хостов Docker, которые называются узлами. Рассмотрим следующие основные компоненты кластера при использовании Docker Swarm перед сравнением развертывания кластера с Kubernetes и Docker Swarm:
Управляющие узлы используются для оркестрации управления, управления кластером и распределения задач.
Рабочие узлы используются для запуска контейнеров, задачи которых назначаются управляющими узлами. Каждый узел может быть настроен как управляющий узел, рабочий узел или и то, и другое, чтобы выполнять функции как управляющего, так и рабочего узла. Обратите внимание, что рабочие узлы запускают службы Swarm.
Службы. Служба Docker Swarm определяет необходимое оптимальное состояние для каждой контейнеризованной службы. Служба контролирует такие параметры, как количество реплик, доступные для нее сетевые ресурсы, порты, которые должны быть доступны извне сетей, и т. Д. Конфигурацию службы, такую как сетевая конфигурация, можно изменить и применить к контейнеру, не требуя перезапуска службы с контейнером вручную.
Задачи. Задача – это слот, в котором запущен один контейнер. Задачи – это части службы Swarm.
Таким образом, Docker Swarm и Kubernetes – это две разные платформы, используемые для схожих целей. Теперь пришло время сравнить их в соответствующем наборе категорий.
Развертывание кластера
Docker Swarm. Стандартный API Docker позволяет развернуть кластер с помощью Swarm, используя стандартный интерфейс командной строки Docker (CLI), что упрощает развертывание, особенно при первом использовании. Удобство развертывания для Swarm по сравнению с Kubernetes также достигается способностью одного мастера Docker определять, как распределить службы. В Docker Swarm не используются поды.
Kubernetes требует использования определенных команд, отличных от стандартных команд Docker. В Kubernetes используются определенные API, что означает, что даже если вы знаете команды для управления Docker, вам также может потребоваться изучить дополнительный набор инструментов для развертывания Kubernetes. Узлы должны быть определены вручную в кластере Kubernetes – вы должны выбрать главный узел, определить контроллер, планировщик и т. д.
Масштабируемость
Docker Swarm. Благодаря простому API, предоставленному Docker, развертывание контейнеров и обновление служб в больших и малых кластерах можно выполнять быстрее. Интерфейс командной строки (CLI) довольно прост и понятен. В результате Swarm можно считать более масштабируемым решением по сравнению с Kubernetes.
Кубернетес предоставляет сравнительно унифицированные API и ряд функций, которые часто приводят к медленному процессу развертывания. Существует три типа компонентов, которые необходимо настроить: Под, Развертывание и Служба. Когда речь идет о автомасштабировании, Кубернетес предпочтителен из-за его способности анализировать нагрузку сервера, а также предоставлять возможность автоматического масштабирования в соответствии с данными требованиями. Кубернетес – оптимальный выбор для крупных распределенных сетей и сложных систем.
Высокая доступность
Обе варианты решения обладают схожими механизмами репликации службы и избыточности, и в обоих случаях система саморегулируется и не требует ручной перенастройки после восстановления отказавшего узла в кластере.
Docker Swarm. Управляющие узлы обрабатывают ресурсы рабочих узлов и весь кластер. Узлы кластера Swarm принимают участие в репликации служб.
Кубернетес. Неисправные узлы обнаруживаются службами балансировки нагрузки Kubernetes и удаляются из кластера. Все поды распределяются среди узлов, обеспечивая тем самым высокую доступность в случае отказа узла, на котором запущено контейнеризованное приложение.
Балансировка нагрузки
Docker Swarm. Балансировка нагрузки является встроенной функцией и может выполняться автоматически с использованием внутренней сети Swarm. Все запросы к кластеру распределяются и перенаправляются на узлы кластера; любой узел может подключаться к любому контейнеру. Docker Swarm использует элемент DNS для распределения входящих запросов по именам служб.
Кубернетес. Политики, определенные в Подах, используются для балансировки нагрузки в Kubernetes. В этом случае Поды контейнеров должны быть определены как сервисы. Настройки балансировки нагрузки необходимо настраивать вручную, в то время как для балансировки нагрузки можно использовать Ingress.
Создание и запуск контейнеров
Docker Swarm. Большинство команд, доступных для Docker CLI, могут быть использованы при использовании Docker Swarm благодаря стандартизированному API Docker Swarm. Docker Compose определяет работу с томами и используемыми сетями, а также определяет, какие контейнеры должны быть сгруппированы вместе. Точное количество реплик можно установить с помощью Docker Compose для Docker Swarm.
Кубернетес. У Kubernetes есть собственное API, клиент и требуется настройка YAML-файлов. Это одно из ключевых различий, так как Docker Compose и Docker CLI не могут использоваться для развертывания контейнеров в этом случае. В Kubernetes система определения сервисов следует тому же принципу работы, что и в Docker Compose, но более сложна. Функциональность Docker Compose выполняется с использованием Подов, Деплоев и Сервисов в Kubernetes, внутри которых каждый слой используется для своей собственной цели. Поды отвечают за взаимодействие контейнеров, деплои – за высокую доступность и сетевое взаимодействие для одного узла в кластере (аналогично Docker Compose для автономного приложения Docker без Swarm), а сервисы Kubernetes отвечают за конфигурацию работы сервиса внутри кластера, устойчивость к сбоям и т. д.
Сетевое взаимодействие
Docker Swarm. Существует одна основная внутренняя сеть для общения контейнеров внутри кластера, на которую можно добавить больше сетей при необходимости. Сети защищены сгенерированными сертификатами TLS. Поддерживается ручная генерация сертификатов для шифрования трафика данных контейнера.
Kubernetes. Сетевая модель Kubernetes довольно отличается и реализуется с использованием плагинов, одним из которых является Flannel, самый популярный вариант. Поды взаимодействуют друг с другом, и это взаимодействие может быть ограничено политиками. Существует внутренняя сеть, управляемая службой etcd. Также доступно TLS-шифрование, но его следует настраивать вручную. Модель сетевого взаимодействия Kubernetes предполагает настройку двух CIDR, Classless Inter-Domain Routing, который также известен как суперсети.
Мониторинг
Docker Swarm. Нет встроенных инструментов для мониторинга и журналирования, хотя вы можете вручную настроить инструменты мониторинга от третьих сторон. ELK или Reimann могут использоваться для этой цели.
Kubernetes. Kubernetes предоставляет встроенные инструменты для журналирования и мониторинга. Elasticsearch и Kibana (ELK) могут использоваться для мониторинга состояния всего кластера, в то время как для мониторинга сервисов контейнера поддерживаются Heapster, Grafana и Influx.
Графический интерфейс пользователя (GUI)
Docker Swarm. Графический интерфейс можно включить с помощью сторонних инструментов, таких как Portainer.io, который предоставляет удобный веб-интерфейс. Как альтернативу можно использовать Enterprise Edition Docker, который предоставляет графический интерфейс для управления кластером.
Кубернетес. Графический интерфейс, предоставленный Kubernetes, является надежной панелью управления, к которой можно получить доступ через веб-интерфейс, с помощью которого легко управлять вашим кластером. GUI может быть весьма ценным инструментом для пользователей с минимальным опытом управления Kubernetes с помощью CLI.
Вывод
Swarm Docker – это родное решение Docker, которое в основном использует API и CLI Docker. Kubernetes, в отличие от этого, является проектом Google, который используется для развертывания кластера, на котором работают контейнеры.
Обе платформы Docker Swarm и Kubernetes предоставляют функции высокой доступности, балансировки нагрузки, оверлейной сетевой инфраструктуры и масштабируемости. Swarm Docker – это более простое в развертывании решение из двух, так как большая часть его конфигурации функций автоматизирована, и оно потребляет небольшие аппаратные ресурсы. Однако функциональность ограничена API Docker, и отсутствуют средства нативного мониторинга.
Кубернетес, с другой стороны, является модульным решением с высоким уровнем гибкости, которое поддерживается большинством крупных корпоративных сущностей в течение многих лет. В Kubernetes доступны встроенные инструменты для мониторинга служб и всего кластера, хотя развертывание и настройка более сложны, что делает этот ресурс более требовательным решением. Kubernetes не совместим с Docker CLI и Docker Compose. Использование Kubernetes предпочтительно в больших средах, где запускаются высоконагруженные многоконтейнерные приложения.