Mesos против Kubernetes

1. Обзор

В этом руководстве мы поймем основные потребности в системе оркестрации контейнеров.

Оценим желаемую характеристику такой системы. Исходя из этого, мы попытаемся сравнить две самые популярные системы оркестрации контейнеров, используемые сегодня, Apache Mesos и Kubernetes .

2. Контейнерная оркестровка

Прежде чем мы начнем сравнивать Mesos и Kubernetes, давайте потратим некоторое время на то, чтобы понять, что такое контейнеры и зачем нам все-таки нужна оркестрация контейнеров.

2.1. Контейнеры

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

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

Docker использует функции ядра Linux, такие как CGroups и пространства имен, для обеспечения изоляции различных процессов. Таким образом, несколько контейнеров могут работать независимо и безопасно.

Создать образы докеров довольно просто, все, что нам нужно, это Dockerfile:

FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY target/hello-world-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
EXPOSE 9001

Итак, этих нескольких строк достаточно, чтобы создать Docker-образ приложения Spring Boot с помощью Docker CLI:

docker build -t hello_world .

2.2. Оркестрация контейнеров

Итак, мы увидели, как контейнеры могут сделать развертывание приложений надежным и воспроизводимым. Но зачем нам оркестрация контейнеров?

Теперь, когда у нас есть несколько контейнеров для управления, с Docker CLI у нас все в порядке. Мы также можем автоматизировать некоторые простые операции. Но что происходит, когда нам приходится управлять сотнями контейнеров?

Например, представьте архитектуру с несколькими микрослужбами, каждая из которых имеет определенные требования к масштабируемости и доступности.

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

3. Краткий обзор Mesos

Apache Mesos — это менеджер кластеров с открытым исходным кодом, первоначально разработанный в Калифорнийском университете в Беркли . Он предоставляет приложениям API для управления ресурсами и планирования в кластере. Mesos дает нам возможность выполнять как контейнерные, так и неконтейнерные рабочие нагрузки распределенным образом.

3.1. Архитектура

Архитектура Mesos состоит из Mesos Master, Mesos Agent и Application Framework:

Давайте разберемся с компонентами архитектуры здесь:

• Фреймворки : это настоящие приложения, требующие распределенного выполнения задач или рабочей нагрузки. Типичными примерами являются Hadoop или Storm . Фреймворки в Mesos состоят из двух основных компонентов:

• Планировщик : отвечает за регистрацию на главном узле , чтобы мастер мог начать предлагать ресурсы.

• Executor : это процесс, который запускается на узлах агента для выполнения задач фреймворка.

• Агенты Mesos : они отвечают за фактическое выполнение задач . Каждый агент публикует свои доступные ресурсы, такие как ЦП и память, мастеру. При получении задач от мастера они выделяют необходимые ресурсы исполнителю фреймворка.

• Mesos Master : отвечает за планирование задач, полученных от фреймворков на одном из доступных узлов агента. Мастер делает предложения ресурсов фреймворкам. Планировщик Framework может запускать задачи на этих доступных ресурсах.

3.2. Марафон

Как мы только что видели, Mesos довольно гибок и позволяет фреймворкам планировать и выполнять задачи через четко определенные API. Однако напрямую реализовывать эти примитивы неудобно, особенно когда мы хотим запланировать пользовательские приложения. Например, оркестровка приложений, упакованных в виде контейнеров.

В этом нам может помочь такой фреймворк, как Marathon . Marathon — это среда оркестрации контейнеров, работающая на Mesos . В связи с этим Marathon выступает в качестве основы для кластера Mesos. Marathon предоставляет несколько преимуществ, которые мы обычно ожидаем от платформы оркестрации, таких как обнаружение сервисов, балансировка нагрузки, метрики и API-интерфейсы управления контейнерами.

Marathon рассматривает долго работающую службу как приложение , а экземпляр приложения — как задачу. Типичный сценарий может иметь несколько приложений с зависимостями, образующими так называемые группы приложений .

3.3. Пример

Итак, давайте посмотрим, как мы можем использовать Marathon для развертывания нашего простого образа Docker, который мы создали ранее. Обратите внимание, что установка кластера Mesos может быть несложной, поэтому мы можем использовать более простое решение, такое как Mesos Mini . Mesos Mini позволяет нам развернуть локальный кластер Mesos в среде Docker. Он включает в себя Mesos Master, одного Mesos Agent и Marathon.

Как только мы запустим и запустим кластер Mesos с Marathon, мы сможем развернуть наш контейнер в качестве долговременной службы приложений. Все, что нам нужно, это небольшое определение приложения JSON:

#hello-marathon.json
{
  "id": "marathon-demo-application",
  "cpus": 1,
  "mem": 128,
  "disk": 0,
  "instances": 1,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "hello_world:latest",
      "portMappings": [
        { "containerPort": 9001, "hostPort": 0 }
      ]
    }
  },
  "networks": [
    {
      "mode": "host"
    }
  ]
}

Давайте разберемся, что именно здесь происходит:

• Мы предоставили идентификатор для нашего приложения
• Затем мы определили требования к ресурсам для нашего приложения.
• Мы также определили, сколько экземпляров мы хотели бы запустить
• Затем мы предоставили сведения о контейнере для запуска приложения из
• Наконец, мы определили сетевой режим для доступа к приложению.

Мы можем запустить это приложение, используя REST API, предоставляемые Marathon:

curl -X POST \
  http://localhost:8080/v2/apps \
  -d @hello-marathon.json \
  -H "Content-type: application/json"

4. Краткий обзор Kubernetes

Kubernetes — это система оркестрации контейнеров с открытым исходным кодом, первоначально разработанная Google . Теперь он является частью Cloud Native Computing Foundation (CNCF). Он предоставляет платформу для автоматизации развертывания, масштабирования и работы контейнера приложений в кластере хостов.

4.1. Архитектура

Архитектура Kubernetes состоит из мастера Kubernetes и узлов Kubernetes:

Давайте рассмотрим основные части этой высокоуровневой архитектуры:

• Kubernetes Master : Мастер отвечает за поддержание желаемого состояния кластера . Он управляет всеми узлами в кластере. Как мы видим, мастер представляет собой совокупность трех процессов:

• kube-apiserver : это служба, которая управляет всем кластером , включая обработку REST-операций, проверку и обновление объектов Kubernetes, выполнение аутентификации и авторизации.

• kube-controller-manager : это демон, который внедряет основной цикл управления, поставляемый с Kubernetes, внося необходимые изменения, чтобы привести текущее состояние в соответствие с желаемым состоянием кластера.

• kube-scheduler : эта служба отслеживает незапланированные модули и привязывает их к узлам в зависимости от запрошенных ресурсов и других ограничений .

• Узлы Kubernetes : узлы в кластере Kubernetes — это машины, на которых работают наши контейнеры. Каждый узел содержит необходимые службы для запуска контейнеров:

• kubelet : это агент основного узла, который гарантирует, что контейнеры, описанные в PodSpecs, предоставленные kube-apiserver , работают и работают .

• kube-proxy : это сетевой прокси, работающий на каждом узле и выполняющий простую переадресацию потоков TCP, UDP, SCTP или циклическую переадресацию через набор серверных частей.

• среда выполнения контейнера : это среда выполнения, в которой запускается контейнер внутри модулей. Существует несколько возможных сред выполнения контейнера для Kubernetes, включая наиболее широко используемую среду выполнения Docker.

4.2. Объекты Кубернета

В последнем разделе мы видели несколько объектов Kubernetes, которые являются постоянными сущностями в системе Kubernetes. Они отражают состояние кластера в любой момент времени.

Давайте обсудим некоторые из часто используемых объектов Kubernetes:

• Поды: под — это базовая единица выполнения в Kubernetes, которая может состоять из одного или нескольких контейнеров, контейнеры внутри пода развертываются на одном хосте.
• Развертывание. Развертывание — рекомендуемый способ развертывания модулей в Kubernetes. Он предоставляет такие функции, как постоянное согласование текущего состояния модулей с желаемым состоянием.
• Сервисы: сервисы в Kubernetes предоставляют абстрактный способ предоставления группы модулей , где группировка основана на селекторах, нацеленных на метки модулей.

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

4.3. Пример

Итак, теперь мы можем попробовать запустить наш контейнер Docker в кластер Kubernetes. Kubernetes предоставляет Minikube , инструмент, который запускает кластер Kubernetes с одним узлом на виртуальной машине. Нам также понадобится kubectl — интерфейс командной строки Kubernetes для работы с кластером Kubernetes.

После установки kubectl и Minikube мы можем развернуть наш контейнер в кластере Kubernetes с одним узлом внутри Minikube. Нам нужно определить основные объекты Kubernetes в файле YAML:

# hello-kubernetes.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: hello-world:latest
        ports:
        - containerPort: 9001
---
apiVersion: v1
kind: Service
metadata:
  name: hello-world-service
spec:
  selector:
    app: hello-world
  type: LoadBalancer
  ports:
  - port: 9001
    targetPort: 9001

Подробный анализ этого файла определения здесь невозможен, но давайте рассмотрим основные моменты:

• Мы определили развертывание с метками в селекторе.
• Мы определяем количество реплик, необходимых для этого развертывания.
• Кроме того, мы предоставили сведения об образе контейнера в качестве шаблона для развертывания.
• Мы также определили службу с соответствующим селектором
• Мы определили природу службы как LoadBalancer.

Наконец, мы можем развернуть контейнер и создать все определенные объекты Kubernetes через kubectl:

kubectl apply -f yaml/hello-kubernetes.yaml

5. Месос против Кубернетес

Теперь мы рассмотрели достаточно контекста, а также выполнили базовое развертывание как в Marathon, так и в Kubernetes. Мы можем попытаться понять, какое место они занимают по сравнению друг с другом.

Только одно предостережение: сравнивать Kubernetes с Mesos напрямую не совсем честно . Большинство функций оркестровки контейнеров, которые мы ищем, предоставляются одной из платформ Mesos, такой как Marathon. Следовательно, чтобы все было в правильном свете, мы попытаемся сравнить Kubernetes с Marathon , а не напрямую с Mesos.

Мы сравним эти системы оркестровки на основе некоторых желаемых свойств такой системы.

5.1. Поддерживаемые рабочие нагрузки

Mesos предназначен для обработки различных типов рабочих нагрузок , которые могут быть контейнерными или даже неконтейнерными. Это зависит от фреймворка, который мы используем. Как мы видели, поддерживать контейнерные рабочие нагрузки в Mesos довольно просто с помощью такой инфраструктуры, как Marathon.

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

5.2. Поддержка масштабируемости

Marathon поддерживает масштабирование с помощью определения приложения или пользовательского интерфейса . Автомасштабирование также поддерживается в Marathon. Мы также можем масштабировать группы приложений, которые автоматически масштабируют все зависимости.

Как мы видели ранее, Pod — это основная исполнительная единица в Kubernetes. Поды можно масштабировать, когда ими управляет Deployment , поэтому поды всегда определяются как развертывание. Масштабирование может быть ручным или автоматическим.

5.3. Работа с высокой доступностью

Экземпляры приложений в Marathon распределяются между агентами Mesos, обеспечивая высокую доступность . Обычно кластер Mesos состоит из нескольких агентов. Кроме того, ZooKeeper обеспечивает высокую доступность кластера Mesos за счет кворума и выбора лидера.

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

5.4. Обнаружение сервисов и балансировка нагрузки

Mesos-DNS может обеспечить обнаружение сервисов и базовую балансировку нагрузки для приложений. Mesos-DNS создает запись SRV для каждой задачи Mesos и преобразует ее в IP-адрес и порт машины, на которой выполняется задача. Для приложений Marathon мы также можем использовать Marathon-lb для обеспечения обнаружения на основе портов с помощью HAProxy.

Развертывание в Kubernetes динамически создает и уничтожает модули. Следовательно, мы обычно предоставляем модули в Kubernetes через Service, который обеспечивает обнаружение служб . Служба в Kubernetes действует как диспетчер для модулей и, следовательно, также обеспечивает балансировку нагрузки.

5.5. Выполнение обновлений и откат

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

Развертывание в Kubernetes поддерживает как обновление, так и откат . Мы можем предоставить стратегию развертывания при замене старых модулей на новые. Типичными стратегиями являются Recreate или Rolling Update . История развертывания сохраняется в Kubernetes по умолчанию, что упрощает откат к предыдущей версии.

5.6. Регистрация и мониторинг

У Mesos есть диагностическая утилита, которая сканирует все компоненты кластера и делает доступными данные, связанные с работоспособностью и другими показателями. Данные можно запрашивать и агрегировать через доступные API. Большую часть этих данных мы можем собрать с помощью внешнего инструмента, такого как Prometheus.

Kubernetes публикует подробную информацию, связанную с различными объектами , в виде метрик ресурсов или полных пайплайнов метрик. Типичной практикой является развертывание внешнего инструмента, такого как ELK или Prometheus+Grafana, в кластере Kubernetes. Такие инструменты могут принимать метрики кластера и представлять их в удобном для пользователя виде.

5.7. Хранилище

Mesos имеет постоянные локальные тома для приложений с отслеживанием состояния . Мы можем создавать постоянные тома только из зарезервированных ресурсов. Он также может поддерживать внешнее хранилище с некоторыми ограничениями. Mesos имеет экспериментальную поддержку Container Storage Interface (CSI), общий набор API-интерфейсов между поставщиками хранилищ и платформой оркестрации контейнеров.

Kubernetes предлагает несколько типов постоянных томов для контейнеров с отслеживанием состояния . Это включает в себя хранилище, такое как iSCSI, NFS. Кроме того, он также поддерживает внешнее хранилище, такое как AWS, GCP. Объект Volume в Kubernetes поддерживает эту концепцию и бывает разных типов, включая CSI.

5.8. Сеть

Среда выполнения контейнеров в Mesos предлагает два типа сетевой поддержки: IP-контейнер и сопоставление сетевых портов . Mesos определяет общий интерфейс для указания и получения сетевой информации для контейнера. Приложения Marathon могут определять сеть в режиме хоста или в режиме моста.

Сеть в Kubernetes назначает уникальный IP-адрес каждому поду. Это устраняет необходимость сопоставлять порты контейнера с портом хоста. Кроме того, он определяет, как эти модули могут общаться друг с другом через узлы. Это реализовано в Kubernetes с помощью сетевых плагинов, таких как Cilium, Contiv.

6. Когда что использовать?

Наконец, в сравнении мы обычно ожидаем четкого вердикта! Однако не совсем справедливо объявлять одну технологию лучше другой, несмотря ни на что. Как мы видели, и Kubernetes, и Mesos являются мощными системами и предлагают весьма конкурирующие функции.

Однако производительность является весьма важным аспектом. Кластер Kubernetes может масштабироваться до 5000 узлов, в то время как кластер Marathon на Mesos, как известно, поддерживает до 10 000 агентов. В большинстве практических случаев мы не будем иметь дело с такими большими кластерами.

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

7. Другие альтернативы

Kubernetes и Apache Mesos довольно мощные, но они не единственные системы в этом пространстве. У нас есть довольно много многообещающих альтернатив. Хотя мы не будем вдаваться в их детали, давайте быстро перечислим некоторые из них:

• Docker Swarm : Docker Swarm — это инструмент кластеризации и планирования с открытым исходным кодом для контейнеров Docker . Он поставляется с утилитой командной строки для управления кластером хостов Docker. Он ограничен контейнерами Docker, в отличие от Kubernetes и Mesos.
• Nomad : Nomad — это гибкий оркестратор рабочих нагрузок от HashiCorp для управления любым контейнерным или неконтейнерным приложением. Nomad обеспечивает декларативную инфраструктуру как код для развертывания приложений, таких как контейнер Docker.
• OpenShift : OpenShift — это контейнерная платформа от Red Hat , организованная и управляемая Kubernetes. OpenShift предлагает множество функций в дополнение к тому, что предоставляет Kubernetes, например, интегрированный реестр образов, сборку из исходного кода в образ, собственное сетевое решение и многие другие.

8. Заключение

Подводя итог, в этом руководстве мы обсудили контейнеры и системы оркестрации контейнеров. Мы кратко рассмотрели две наиболее широко используемые системы оркестровки контейнеров — Kubernetes и Apache Mesos. Мы также сравнили эти системы по нескольким характеристикам. Наконец, мы увидели некоторые другие альтернативы в этом пространстве.

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