«Mesos против Kubernetes»

«1. Обзор

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

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

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

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

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

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

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

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

Создание образов Docker довольно тривиально, все, что нам нужно, это 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 Frameworks:

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

Frameworks: Это фактические приложения, требующие распределенного выполнения задач или рабочей нагрузки. Типичными примерами являются Hadoop или Storm. Фреймворки в Mesos состоят из двух основных компонентов: Планировщик: отвечает за регистрацию на главном узле, чтобы мастер мог начать предлагать ресурсы. Исполнитель: это процесс, который запускается на узлах агентов для выполнения задач фреймворка. Агенты Mesos: эти несут ответственность за фактическое выполнение задач. Каждый агент публикует свои доступные ресурсы, такие как ЦП и память, мастеру. При получении задач от мастера они выделяют необходимые ресурсы исполнителю фреймворка. Mesos Master: отвечает за планирование задач, полученных от фреймворков на одном из доступных агентских узлов. Мастер делает предложения ресурсов фреймворкам. Планировщик Framework может запускать задачи на этих доступных ресурсах.

3.2. Marathon

Как мы только что видели, 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: Мастер отвечает за поддержание желаемого состояния кластера. Он управляет всеми узлами в кластере. Как мы видим, мастер представляет собой набор из трех процессов: kube-apiserver: это служба, которая управляет всем кластером, включая обработку REST-операций, проверку и обновление объектов Kubernetes, выполнение аутентификации и авторизации kube-controller-manager: это — это демон, который внедряет основной цикл управления, поставляемый с Kubernetes, внося необходимые изменения, чтобы привести текущее состояние в соответствие с желаемым состоянием планировщика кластера: эта служба отслеживает незапланированные модули и привязывает их к узлам в зависимости от запрошенных ресурсов и других ограничения Узлы Kubernetes: узлы в кластере Kubernetes — это машины, на которых работают наши контейнеры. Каждый узел содержит необходимые службы для запуска контейнеров: kubelet: это основной агент узла, который гарантирует, что контейнеры, описанные в PodSpecs, предоставленных kube-apiserver, работают и работают исправно kube-proxy: это сетевой прокси, работающий на каждом узле и выполняет простую переадресацию потока TCP, UDP, SCTP или циклическую переадресацию через набор бэкэндов. Среда выполнения контейнера: это среда выполнения, в которой запускается контейнер внутри модулей. Существует несколько возможных сред выполнения контейнера для Kubernetes, включая наиболее широко используемую среду выполнения Docker.

4.2. Объекты Kubernetes

В предыдущем разделе мы видели несколько объектов 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

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

Мы определили развертывание с метками в selector Мы определяем количество реплик, необходимых для этого развертывания. Кроме того, мы предоставили сведения об образе контейнера в качестве шаблона для развертывания. Мы также определили службу с соответствующим селектором. Мы определили характер службы как LoadBalancer ~ ~~ Наконец, мы можем развернуть контейнер и создать все определенные объекты Kubernetes через kubectl:

5. Mesos против Kubernetes и Кубернет. Мы можем попытаться понять, какое место они занимают по сравнению друг с другом.

kubectl apply -f yaml/hello-kubernetes.yaml

Только одно предостережение: сравнивать 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 через службу, которая обеспечивает обнаружение службы. Служба в Kubernetes действует как диспетчер для модулей и, следовательно, также обеспечивает балансировку нагрузки.

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

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

Развертывание в Kubernetes поддерживает как обновление, так и откат. Мы можем предоставить стратегию развертывания при замене старых модулей на новые. Типичными стратегиями являются воссоздание или непрерывное обновление. История развертывания сохраняется в 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. Мы также сравнили эти системы по нескольким характеристикам. Наконец, мы увидели некоторые другие альтернативы в этом пространстве.

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

«

Before closing, we must understand that the purpose of such a comparison is to provide data and facts. This is in no way to declare one better than others, and that normally depends on the use-case. So, we must apply the context of our problem in determining the best solution for us.