Kubernetes теперь называют стандартом оркестрации контейнеров.
Он лежит в основе многих платформ облачной контейнеризации: например, мы разрабатываем Кубернетес как услуга на платформе «Облачные решения Mail.ru».
Однако Kubernetes — далеко не первый подобный инструмент на рынке: некоторые системы-предшественницы продолжают активно использоваться и, похоже, даже успешны.
Почему так происходит, несмотря на то, что Kubernetes, можно сказать, победил в своем классе и мы видим множество примеров, когда он заменяет другие решения? Например, недавно разработчики Mesphere DC/OS, основанной на Apache Mesos, прекратили ее развитие и сосредоточились на другой своей платформе — D2iQ Kubernetes (DKP).
Думаю, стоит разобраться, всегда ли Kubernetes хорош, когда оправдано использование других оркестраторов и о каких подводных камнях следует знать.
Я Дмитрий Лазаренко, директор по продукту облачной платформы Mail.ru Cloud Solutions (MCS).
В этой статье я расскажу о конструкции ряда оркестраторов-предшественников, сравню их с Kubernetes и рассмотрю его преимущества и недостатки по сравнению с ними.
- Критерии сравнения
- I. Docker Swarm против Kubernetes
- II. Кочевник против Кубернетеса
- III. Apache Mesos (+ Maraphon, Aurora) против Kubernetes
- IV. Флот против Кубернетеса
- V. Преимущества и недостатки систем оркестрации
- Как перейти на Kubernetes с других оркестраторов
- Контрольный список: на что обратить внимание при выборе провайдера Kubernetes
- Выводы: сравнительный анализ систем оркестровки
Критерии сравнения
В этой статье я сравню Kubernetes с наиболее известными и часто используемыми системами оркестрации: Docker Swarm, Nomad, Apache Mesos и Fleet. Для сравнения я использую следующие критерии:- Типы рабочей нагрузки: предназначен ли оркестратор для управления контейнерами Docker, другими контейнерами и неконтейнеризованными приложениями.
- Простота управления: насколько легко установить и настроить оркестратор.
- Требования к платформе для развертывания: является ли решение платформо-независимым или существуют определенные требования к ОС и другие ограничения.
- Производительность: среднее время обработки вызовов API, запуска контейнеров и других важных операций.
- Ограничения на количество узлов и контейнеров в кластере: какие ограничения на количество управляемых компонентов.
- Конфигурация как код: можно ли загружать схемы приложений из файлов YAML или JSON.
- Шаблоны: доступны ли пользовательские шаблоны для настройки.
- Сети: как устроена сеть, есть ли у вас собственное сетевое решение или нужно использовать сторонние сетевые плагины.
- Возможность обнаружения служб: поддерживается ли динамическое обнаружение служб с помощью DNS, прокси-сервера и т. д.
- Автомасштабирование: возможно ли автомасштабирование в зависимости от изменения нагрузки.
- Выполнение обновлений и откатов: какие стратегии обновления поддерживаются.
Есть ли возможность последовательного обновления (Rolling Update), когда старые экземпляры приложения постепенно заменяются новыми.
Насколько легко откатиться назад?
- Отказоустойчивость: как обрабатываются сбои, что происходит при выходе из строя одного из узлов.
- Мониторинг: есть ли встроенные механизмы или необходимо использовать внешние инструменты и какие.
- Безопасность: есть ли встроенное решение для управления конфиденциальной информацией (логинами и паролями).
I. Docker Swarm против Kubernetes
Docker Swarm — это встроенное в сам Docker решение для управления контейнерами на физических или виртуальных машинах.Когда несколько хостов Docker используют режим Swarm, некоторые из них можно настроить как узлы управления или менеджеры, а остальные — как рабочие узлы.
Задача менеджеров — управлять кластером и делегировать задачи рабочим узлам.
1. Виды рабочих нагрузок
Хотя Docker Swarm предназначен для работы исключительно с контейнерами Docker, Kubernetes поддерживает несколько типов контейнеров: Docker,Containerd, CRI-O и любые решения, соответствующие стандарту CRI (Container Runtime Interface).
2. Простота управления
По сравнению с Kubernetes, Docker Swarm гораздо проще установить вручную.Swarm работает поверх Docker, использует интерфейс командной строки и легко интегрируется с Docker Compose. Kubernetes также может работать поверх Docker, но в этом случае вам придется взаимодействовать с инфраструктурой с помощью двух разных утилит: Docker CLI и kubectl CLI. Kubernetes на порядок сложнее.
Он включает в себя множество компонентов: kube-api-server, kube-scheduler, kube-controller-manager, kube-proxy, kubelet — и поддерживает несколько типов установщиков для разных типов инфраструктур и задач: Kubeadm, Kops, Kubespray и так далее.
Все это требует дополнительной подготовки.
То есть барьер входа в Kubernetes выше по сравнению с Docker Swarm. Но все, что напрямую связано с администрированием контейнеров: развертывания, приведение кластера в нужное состояние, добавление новых узлов — в K8s можно сделать проще и быстрее.
Также многие, поработав с обоими оркестраторами, отмечают, что Kubernetes более стабилен.
3. Требования к платформе для развертывания
Docker Swarm, как и Kubernetes, можно использовать в различных операционных системах: Windows, macOS, Linux. Однако Kubernetes использует разные настройки для каждой ОС.Если требуемые конфигурации выходят за рамки стандартной реализации, настройка Kubernetes самостоятельно может стать гигантской задачей.
В этом плане выигрывает Docker Swarm.
4. Производительность
По сравнению с Kubernetes Docker Swarm работает быстрее.Kubernetes сложнее из-за большого количества дополнительных слоев в архитектуре (планировщик и т. д.), что замедляет работу, но обеспечивает стабильность кластера в целом.
5. Ограничения на количество узлов и контейнеров в кластере
Kubernetes v1.20 поддерживает конфигурации, соответствующие следующим критериям:- не более 110 подов на одну ноду, при этом параметр можно настроить,
- не более 5000 узлов,
- всего не более 150 000 модулей,
- всего не более 300 000 контейнеров.
Максимальное количество контейнеров, скорее всего, будет определяться ограничениями ОС, но пользователи Swarm советуют придерживаться аналогичных рекомендаций: 100 контейнеров на узел.
6. Конфигурация как код
Оба оркестратора могут использовать файлы YAML для определения конфигураций.JSON также доступен в Kubernetes, но YAML предпочтительнее.
7. Шаблоны
Docker Swarm не имеет механизма шаблонов, подобного Helm в Kubernetes. Некий механизм шаблонов приложений был анонсирован в Docker Desktop Enterprise 3.0 , но это решение в настоящее время не поддерживается.
8. Сети
С точки зрения сетевой модели Kubernetes выглядит предпочтительнее.Он работает с виртуальными сетями и поддерживает гораздо больше различных сетевых решений по сравнению с Swarm. Каждый модуль получает свой собственный IP-адрес, а это означает, что нет необходимости сопоставлять порты контейнера с портами хоста.
Kubernetes может работать с любым CNI-совместимым сетевым решением.
В Docker Swarm вы можете указать оверлейную сеть для своих сервисов.
Менеджер автоматически назначит адреса контейнерам в оверлейной сети при инициализации или обновлении приложения.
Однако некоторые пользователи жаловались на производительность собственной сети, советуя использовать сетевые плагины, такие как Calico.
9. Возможность обнаружения услуг
Реализовано в обоих оркестраторах с использованием встроенного DNS-сервера.
10. Автомасштабирование
Автомасштабирование недоступно в Docker Swarm. Для каждого сервиса вы можете вручную указать количество задач, которые хотите запустить.По мере увеличения или уменьшения этого числа узел Менеджер автоматически адаптируется, добавляя или удаляя задачи для поддержания желаемого состояния.
Kubernetes поддерживает автоматическое масштабирование на основе наблюдаемого использования ЦП, использования памяти и множества других пользовательских показателей.
При этом масштабирование доступно на нескольких уровнях:
- Автомасштабирование кластера с помощью Cluster Autoscaler, отвечающего за изменение количества узлов в кластере.
- Horizontal Pod Autoscaler (HPA), который автоматически меняет количество подов в зависимости от значений выбранных показателей.
- Вертикальное автомасштабирование модулей (VPA), которое автоматически изменяет количество ресурсов, выделяемых существующим модулям.
11. Выполнение обновлений и откатов
И Kubernetes, и Docker Swarm поддерживают чередующиеся обновления: во время развертывания вы можете постепенно применять сервисные обновления к узлам.В случае неудачи вы можете вернуться к предыдущей версии сервиса.
Однако Kubernetes допускает более гибкую настройку.
Swarm Manager позволяет вам контролировать задержку между развертыванием службы на разных наборах узлов, возможность одновременного обновления нескольких задач и действия в случае сбоя обновления.
В Kubernetes гораздо больше настраиваемых параметров: максимальное количество недоступных подов, разрешенное увеличение количества подов, минимальное время, в течение которого под должен стать доступным, максимальная длительность задач.
12. Отказоустойчивость
Оба оркестратора поддерживают высокую доступность приложений.В Docker Swarm узел Manager постоянно отслеживает состояние кластера и согласовывает любые различия между фактическим состоянием и желаемым состоянием, которое вы настраиваете.
В Kubernetes балансировщики нагрузки обнаруживают неисправные модули и удаляют их.
Используются проверки здоровья.
13. Мониторинг
Использование решений для ведения журналов и мониторинга (ELK, Prometheus) в Docker Swarm возможно, как и в Kubernetes, но требует большего количества пользовательских настроек или использования дополнительных наборов инструментов, таких как Swarmprom.14. Безопасность
С точки зрения безопасности в Swarm до недавнего времени практически ничего не было.Мне пришлось использовать Vault для хранения секретов.
В настоящее время каждый узел в Swarm использует взаимную аутентификацию и шифрование TLS для защиты связи внутри себя и с другими узлами.
Также можно использовать самозаверяющие корневые сертификаты или сертификаты собственного корневого центра сертификации.
Это также встроенное решение для управления секретами .
Однако Kubernetes по-прежнему на шаг впереди, предлагая гибкую настройку сетевых политик, использование пространств имен и другие преимущества.
II. Кочевник против Кубернетеса
Nomad — оркестратор от HashiCorp для управления контейнерами и неконтейнеризованными приложениями.Его архитектура основана на клиентах (Client), на которых могут выполняться задачи, и серверах (Server), которые управляют клиентами и задачами.
Серверы выбирают лидера для обеспечения высокой доступности.
Рабочая нагрузка в Nomad определяется Job, который описывает желаемое состояние кластера и состоит из одной или нескольких групп задач.
Задача — это наименьшая единица работы, выполняемая драйверами (Docker, QEMU, Java и т. д.).
В обязанности Nomad входит поддержание соответствия между желаемым состоянием, описанным в задании, и реальным состоянием кластера.
Отдельное спасибо за советы по работе Номада манефест .
1. Виды рабочих нагрузок
В то время как Kubernetes ориентирован на контейнеры, Nomad работает с разными типами рабочих нагрузок.Он поддерживает виртуализированные, контейнерные и автономные микросервисы и пакетные приложения, включая Docker, Java, Qemu и другие, полный список можно найти.
Это позволяет вам организовывать работу не только с контейнерами/виртуальными машинами, но и запускать приложения на узлах.
Например, вы можете запускать на узлах тяжелые приложения Java.
2. Простота управления
Установить Nomad значительно проще, чем Kubernetes. Nomad доступен в виде предварительно скомпилированного двоичного файла (один для клиентов и серверов), а также в виде пакетов для различных операционных систем.Вы также можете собрать Nomad из исходного кода.
Минимальный тестовый стенд можно установить на хост без использования сторонних утилит, таких как Minikube. Достаточно запустить Nomad в режиме разработки, и он будет выступать в роли сервера/агента, чего вполне достаточно для локального тестирования.
Однако в то время как Kubernetes стремится предоставить все функции, необходимые для запуска контейнерных приложений (включая управление кластером, автоматическое обнаружение сервисов, безопасность и т. д.), Nomad фокусируется только на управлении кластером и планировании.
K8s считается основой для построения кластера, тогда как подход HashiCorp более близок к UNIX-способу.
Вы можете настроить кластер Nomad под свои требования с помощью внешних инструментов: Consul для обнаружения сервисов, Vault для управления конфиденциальной информацией и другие.
До определенного момента у Nomad не было возможности использовать внешнее хранилище, сети кроме хоста и Bridge, но теперь есть поддержка плагинов CSI, CNI, и теперь можно использовать сети и хранилище так же, как K8s. делает. В любом случае использовать Nomad несложно: по сути, вам нужно просто скопировать бинарный файл и создать сервис Systemd, работающий совместно с Consul как Service Discovery.
3. Требования к платформе для развертывания
И Kubernetes, и Nomad можно развернуть в различных операционных системах: Linux, macOS, Windows. Однако Kubernetes требует разных настроек в зависимости от ОС, что затрудняет установку вручную.
4. Производительность
По производительности оба решения находятся примерно на одном уровне, но Nomad все равно впереди благодаря своей архитектурной простоте.
5. Ограничения на количество узлов и контейнеров в кластере
Kubernetes поддерживает кластеры до 5000 узлов и 300 000 контейнеров.В документации Nomad указано, что он масштабируется до размеров кластера, превышающих 10 000 узлов в реальных производственных средах.
Nomad также успешно принял участие в ряде интенсивных тестов масштабируемости: 1 миллион контейнеров в 2016 году и 2 миллиона контейнеров в 2020 году.
Однако на практике вероятность использования столь масштабных кластеров невелика.
6. Конфигурация как код
Kubernetes поддерживает декларативное развертывание на основе файлов YAML. Nomad использует собственный язык конфигурации HashiCorp — HCL. Это означает, что при использовании Nomad вам потребуется дополнительное обучение HCL. Но стоит отметить, что Nomad содержит стандартные инструменты и команды для преобразования описаний из YAML и JSON в HCL (и наоборот): Ямленкод / Ямлдекод , jsonencode / jsondecode .Правда, они работают с определёнными ограничениями, а некоторые находятся в тестовом режиме.
7. Шаблоны
У Nomad нет инструмента создания шаблонов, подобного Helm для Kubernetes.8. Сети
С точки зрения сети Kubernetes выглядит более лаконичным и стабильным.Первоначально он представил абстракцию Pod, позволяющую запускать несколько контейнеров в одном и том же сетевом пространстве, и использовал CNI (сетевой интерфейс контейнера).
Nomad же развивался от меньшего к большему и долгое время использовал исключительно хост-сети без дополнительных уровней абстракции.
Вместо Pods он использовал Джобса без возможности объединения контейнеров внутри них в единое сетевое пространство.
В Nomad начали развиваться мультиинтерфейсные сети и возможности подключения CNI. недавно .
Вы можете подключить плагин CNI, чтобы использовать Calico, Cilium, Weave.
9. Возможность обнаружения услуг
В отличие от Kubernetes, Nomad не имеет автообнаружения на основе DNS. Чтобы обнаружить сервисы, вам необходимо использовать дополнительный инструмент Consul. В этом Nomad сильно уступает Kubernetes. И многие считают, что это одна из главных причин, почему Nomad в то время был менее востребован.
10. Автомасштабирование
Общей чертой двух оркестраторов является поддержка следующих типов автомасштабирования:- горизонтальное автомасштабирование приложений в Nomad и подов в Kubernetes,
- автомасштабирование кластера.
Аналогичное решение в Nomad, заключающееся в построении рекомендаций по ЦП и памяти на основе анализа исторических данных, доступно исключительно в версии Enterprise.
11. Выполнение обновлений и откатов
Оба оркестратора предоставляют гибкие возможности управления обновлениями, включая стратегии чередующихся обновлений, стратегии Blue и Green и Canary. Для настройки доступен ряд индикаторов, влияющих на ход обновлений, включая временные интервалы проверок работоспособности и многое другое.И K8s, и Nomad поддерживают автоматический возврат к последней стабильной версии в случае сбоя развертывания.
История развертываний сохраняется в обоих случаях.
12. Отказоустойчивость
По умолчанию поведение обеих систем аналогично.Kubernetes позволяет за минуту выявить вышедший из строя узел и за пять минут выселить поды на другой узел.
У Nomad примерно такие же ставки по умолчанию.
Но в Kubernetes с помощью опций kubelet и Control Manager можно добиться того, чтобы в течение 10 секунд поды были переброшены на другую рабочую ноду.
13. Мониторинг
Оба оркестратора совместимы с популярными инструментами ведения журналов и мониторинга: ELK, Prometheus/Grafana и другими.Собираются метрики, которые впоследствии можно получить через API или настроив автоматическую пересылку стороннему провайдеру.
14. Безопасность
Главное, в чем Nomad проигрывает с точки зрения безопасности, — это необходимость использования сторонней системы Vault для управления конфиденциальной информацией (логинами и паролями).Хотя на современном рынке Open Source, пожалуй, не существует более безопасного решения, чем Vault, его настройка и использование совместно с Nomad — довольно непростая задача.
Коробочный Kubernetes в этом отношении проще, поскольку может предложить встроенное решение.
Kubernetes по умолчанию поддерживает пространства имен, которые можно эффективно использовать для разделения сред разработки.
В Nomad этот функционал ранее был доступен только в версии Enterprise, а в версии Open Source он доступен в Nomad 1.0.
III. Apache Mesos (+ Maraphon, Aurora) против Kubernetes
Apache Mesos — это менеджер кластера, поддерживающий различные рабочие нагрузки.Основой архитектуры Mesos являются мастер (Mesos Master), агенты (Mesos Agent), работающие на каждом узле кластера и управляемые мастером, и фреймворки (Mesos Frameworks), выполняющие задачи на агентах.
Обычно развертывается несколько мастеров резервного копирования, готовых взять на себя управление в случае сбоя, и ZooKeeper отвечает за выбор лидера среди них.
Фреймворк состоит из двух компонентов: планировщика (Scheduler), зарегистрированного на главном сервере, которому будут предлагаться ресурсы, и исполнителя (Executor), который запускается на агентских узлах для выполнения задач фреймворка.
Мастер предлагает платформам ресурсы агентов, а планировщики выбирают, какие из предложенных ресурсов использовать для выполнения своих задач на агентах.
Кластер Mesos может запускать несколько платформ для разных типов задач.
То есть сам Apache Mesos является лишь своего рода диспетчером, а конечный функционал будет определяться используемым фреймворком.
Поэтому при описании метрик мы иногда будем ссылаться на два конкретных фреймворка: Maraphon для управления контейнерными приложениями и Apache Aurora для планирования заданий Cron и долго выполняющихся сервисов.
Aurora больше не поддерживается, но когда-то была довольно распространена и могла также использоваться для контейнерных приложений.
Также мы иногда будем упоминать Mesphere DC/OS — операционную систему, основанную на Apache Mesos, Maraphon и предлагающую ряд дополнительных функций (хотя некоторые из них доступны в платной версии).
1. Виды рабочих нагрузок
Apache Mesos предназначен для обработки различных типов рабочих нагрузок, которые могут быть как контейнерными, так и неконтейнеризованными.Например, в качестве планировщика задач (Scheduler) можно использовать Hadoop (Big Data), MPI (обмен сообщениями), Jenkins (система непрерывной интеграции).
Вы даже можете разработать собственный планировщик с помощью Apache Mesos. Kubernetes ориентирован исключительно на контейнерные приложения.
2. Простота управления
Apache Mesos проще развернуть, чем Kubernetes, если мы говорим об установке вручную.Однако дальнейшее администрирование Apache Mesos сложнее по сравнению с K8s, так как нужно работать с ZooKeeper, уметь администрировать Java и быть готовым к связанным с этим трудностям: утечкам памяти, Xmx, лимитам и так далее.
Kubernetes с Golang в этом отношении проще.
3. Требования к платформе для развертывания
Mesos работает на Linux и macOS. Агенты также можно установить в Windows. Kubernetes также поддерживает все операционные системы.
4. Производительность
Mesos изначально был ориентирован на работу с большими данными, поэтому по производительности он опережает Kubernetes.5. Ограничения на количество узлов и контейнеров в кластере
По масштабируемости Apache Mesos превосходит Kubernetes, поскольку способен поддерживать десятки тысяч узлов (K8s рассчитан максимум на 5000).Когда Mesos объединяется с Mesphere DC/OS, в результате получается платформа, предлагающая практически неограниченную масштабируемость, идеальную для больших систем.
Разработчики заявили, что остановил свое развитие , но существующие клиенты продолжают поддерживаться.
Еще в 2015 году Mesos успешно выдержала тест масштабирования до 50 000 узлов .
6. Конфигурация как код
В Apache Mesos в сочетании с Maraphon вы можете использовать определения JSON (для указания репозиториев, ресурсов, количества экземпляров и команд для выполнения).Для этой цели Kubernetes поддерживает декларативное развертывание как в YAML, так и в JSON (первый предпочтителен).
7. Шаблоны
Если вы используете Mesphere DC/OS, вы можете использовать шаблоны конфигурации (с помощью Maraphon-LB).В Apache Aurora при настройке сервисов в DSL также были доступны шаблоны, позволяющие избежать дублирования конфигураций.
А вот Helm, используемый в K8s, будет более мощным и удобным инструментом.
8. Сети
Долгое время Apache Mesos отставал от Kubernetes с точки зрения сетевой реализации, поскольку по умолчанию он не назначал контейнерам IP-адреса, требовал сопоставления портов контейнера с портами хоста, что является ограниченным ресурсом.Впоследствии была добавлена поддержка CNI (Container Networking Interface) и появилась возможность использовать виртуальные сети, такие как Calico, Cilium, Weave. Но Kubernetes в настоящее время поддерживает больше сетевых решений .
9. Возможность обнаружения услуг
Присутствует в обеих системах.Mesos-DNS обеспечивает обнаружение сервисов и базовую балансировку нагрузки для приложений.
При использовании совместно с Marathon Marathon-LB дополнительно доступен для обнаружения на основе портов с использованием HAProxy. Aurora также представила экспериментальную поддержку Mesos DiscoveryInfo — для создания собственной системы обнаружения без использования ZooKeeper. В Kubernetes доступен встроенный DNS-сервер.
10. Автомасштабирование
В Kubernetes реализация автомасштабирования лучше.Как отмечалось выше, доступны три стратегии: масштабирование кластера, горизонтальное масштабирование модулей и вертикальное масштабирование модулей.
В качестве триггеров можно настроить ЦП, память и пользовательские метрики.
В Apache Mesos автомасштабирование доступно в сочетании с Maraphon (в Mesphere DC/OS) — на основе значений ЦП, памяти и количества запросов в секунду.
11. Выполнение обновлений и откатов
Поддерживается в обеих системах.Развертывание Blue и Green доступно в Apache Mesos, а также может быть реализовано в Kubernetes с использованием встроенных механизмов.
12. Отказоустойчивость
Обе системы отказоустойчивы.В Apache Mesos экземпляры приложений распределяются между агентами, обеспечивая высокую доступность.
Кроме того, ZooKeeper поддерживает доступность кластера посредством выборов кворума и лидера.
Аналогично, модули в Kubernetes реплицируются на нескольких узлах.
Обычно кластер Kubernetes состоит из нескольких рабочих узлов.
У него также может быть несколько мастеров.
Кроме того, оба оркестратора проводят проверки работоспособности.
Для Mesos они доступны при использовании Mesphere DC/OS.
13. Мониторинг
И Mesos, и Kubernetes предоставляют показатели работоспособности и другие показатели.Данные можно запрашивать и агрегировать с помощью внешних инструментов.
Типичная практика — развертывание ELK и Prometheus + Grafana. А вот подключить мониторинг в Kubernetes проще, так как многое строится на готовых решениях благодаря поддержке большого сообщества и богатых инструментов.
В Mesos вам придется многое делать самому, в результате чего неизбежно увеличивается время выхода на рынок.
14. Безопасность
Трудно отдать кому-то предпочтение.Если говорить об Apache Mesos в связке с Maraphon или Aurora вне Mesphere DC/OS, то Kubernetes выглядит лучше.
Долгое время Месосу практически нечего было предложить в плане безопасности.
Таким образом, встроенное решение для работы с секретами не имело в себе должной реализации, и пользователи предпочитали использовать сторонние инструменты, такие как Vault. Но если мы обратимся к ОС DC/OS Enterprise — сегодня он предлагает богатый функционал с точки зрения корпоративной безопасности, возможно, даже лучший, чем Kubernetes. Однако данная версия системы является платной, кроме того, ее развитие свернуто разработчиками в пользу новой платформы на базе Kubernetes.
IV. Флот против Кубернетеса
Fleet — это механизм низкоуровневой кластеризации из CoreOS, похожий на распределенную систему инициализации.На данный момент не поддерживается, так как компания начала активно продвигать Кубернетес .
Флот был основан на systemd. В то время как systemd обеспечивал инициализацию системы и служб на уровне одной машины, Fleet распространил этот процесс на кластер.
В архитектуре Fleet на каждой машине запускался демон флота, выполнявший две роли: движок (Engine) и агент (Agent).
Движок принимал решения по планированию, а агент обрабатывал файлы Systemd Unit (Unit).
Эта обработка чаще всего сводилась к запуску контейнера.
В любой момент времени в кластере был активен только один механизм, но все агенты работали.
Новые файлы были назначены агентам с наименьшей нагрузкой.
etcd выступал в качестве хранилища данных в кластере и средства связи между движком и агентами.
В нем хранились файлы Unit, данные об их состоянии, состоянии кластера и так далее.
1. Виды рабочих нагрузок
Хотя Kubernetes поддерживает контейнерные приложения, Флит использовал модули systemd для запуска контейнеров или любых других процессов на узлах кластера.
2. Простота управления
Установка Флита была проведена намного проще и быстрее за счет Теги: #Kubernetes #Облачные вычисления #контейнеризация #DevOps #облачные решения vk #облачные решения vk #облачные решения mail.ru #k8s-
Оргия Потребления
19 Oct, 24 -
Macos + Windows 10 На Внешнем Диске
19 Oct, 24 -
Google Закрывает Notebook И Другие Сервисы
19 Oct, 24 -
Windows Vista Будет Разрешена Для Загрузки
19 Oct, 24
