Как выбрать лучший оркестратор контейнера для себя

Как сказал Марк Андрисен: «ПО съедает мир» поэтому сейчас все компании независимо от возраста, размера или отрасли промышленности превращаются в компании по разработке ПО.

Когда эти компании по созданию ПО достигают зрелости, им необходимо пересмотреть видение своих архитектур ПО, свою команду и платформу, на которой работает их ПО.

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

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

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

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

Микросервисы замечательны

Существует много статей о том, что такое микросервисы, и почему вы должны применить их. Поэтому вместо долгих объяснений, почему они классные, мы выделим некоторые их лучшие характеристики:

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

Итак, вы решили, что вы будете заниматься микросервисами

Вы провели бета тестирование микросервисов, ваша команда внедрила их первый или второй микросервис в ваш центр обработки данных. И со временем вы понимаете, что эти внедрения не проходят так быстро, как вам бы хотелось.

Что замедляет внедрение микросервиса

Традиционный цикл предоставления занимает до 6 недель. Этот «Секретный» слайд взят из данной презентации

а. Необходимость работать с зависимостями и базовыми образами

Если вы хотите запустить сервис, то вам нужна машина, на которой он будет работать. Этой машине нужен доступ не только к коду, который она запускает, но и ко всей среде. Для машины нужны Java/Ruby/PHP среды, все пакеты/gems /модули и любые стационарные библиотеки, на которые полагается ваш код.

Хотя утилиты типа Packer упрощают создание этого базового образа, обслуживание множества разных образов может занять много времени для вашей организации.

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

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

Утилиты типа Terrafotm, Chef и Puppet упрощают процесс обновления инфраструктуры, но при этом они могут создать зависимость от вашего Cloud Provider (AWS, Azure, Google Cloud Engine и т.д.)

с. Нелегко иметь и обслуживать несколько зон доступа

Для гарантии времени работоспособности вашего приложения важно иметь резервные сервисы. В настоящее время для каждой компании ПО необходимы несколько зон доступа.  Но даже если инфраструктура выступает в качестве кода, это нелегко, а держать все зоны в синхронизации может быть невыносимо тяжело даже для лучших команд devops.

Контейнеры для восстановления

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

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

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

Использование планировщика для управления контейнерами вместо машин

Планировщики бывают разных цветов и размеров, от прославленного Kubernetes Ships, Nomad groups до облака Docker.

Наиболее известными планировщиками являются:

• Mesos(Mesosphere)
• Kubernetes(Google)
• Nomad(Hashicorp)
• DockerSwarm(Docker)
• CloudFoundry(Pivotal,HP,IBM,другие)
• OpenShift(Redhat)

Планировщик — это корабль, на котором ваше приложение (изображено в виде жирафа на картинке) живет.

Чем они отличаются?

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

Стратегии:

• Монолитные: Hadoop YARN, Docker swarms

Монолитная стратегия имеет единую точку координации, которая знает точную ситуацию всей системы и совершает разумные распределения. Это обычно статичные системы типа YARN, которые запускают что-то типа Hadoop и Spark на одном и том же оборудовании — поэтому там не много подвижных частей.

• двухуровневый (пессимистически параллельны): Mesos

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

• общее состояние (положительно параллельны): Nomad, Kubernetes.

Также существуют планировщики общего состояния, эти ребята запускают контейнеры быстрее всего. У Nomand есть контрольный показатель, согласно которому они запускают 1мм контейнеры на 5000 узлах за 5 минут. Довольно таки удивительно.

Для большинства приложений эта стратегия не важна, поэтому большинство из нас сфокусируется на характеристиках.

Характеристики:

Функции планировщика матрици

Поддержка предприятия

Поддержка предприятия в большинстве случаев доступна на всех провайдерах кроме Google. Поддержка Kubernetes доступна только для предложения GCE облака, но существует некая третья сторона провайдеров, которая предоставляет поддержку.

Мульти-центр обработки данных / поддержка доступности зон

Не все планировщики поддерживают зоны мульти доступности

Голый металл

Большинство планировщиков, с заметным исключением Cloud Foundry, могут быть установлены на «голом металле» или на физических машинах внутри вашего центра обработки данных. Таким образом можно сэкономить на лицензии гипервизора.

Громкость

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

 Управление секретами

Secrets Management — это большая часть конфигурации оркестровки, которая не просто исчезает, когда вы начинаете использовать планировщик. В Docker и Mesos нет встроенных решений, но у всех остальные на этом этапе есть.

Как сделать выбор?

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

 Особенности

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

Соответствие требованиям

У вас есть строгие требования к аудиту или соответствие требованиям? Только Cloud Foundry предоставляет любую модель пользователя / разрешения, и это может быть слишком базовым для ваших требований.

Момент / Поддержка

 Поскольку планировщики становятся все более популярными, больше вариантов продолжают появляться каждый день

Зрелость

• Cloud Foundry — 2011
• Mesosphere — 2013
• Kubernetes — 2014
• Nomad — 2015

Нужна помощь в выборе?

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