Что будет в Rancher 2.0 и почему он переходит на Kubernetes?

Неделю назад разработчики Rancher представили ^[1] предварительный релиз своей будущей крупной версии — 2.0, — попутно объявив о переходе на Kubernetes в качестве единой основы для оркестровки контейнеров. Что побудило разработчиков пойти таким путём?

Предыстория: Cattle

Rancher 1.0 вышел в марте прошлого года, и на сегодняшний день в мире, по данным компании Rancher Labs, насчитывается более 10 тысяч его действующих инсталляций и более 100 коммерческих пользователей. Первая версия Rancher включала в себя Cattle ^[2], который, будучи «высокоуровневым компонентом, написанным на Java», назывался «базовым движком оркестровки» и «основным циклом всей системы». В сущности же Cattle был даже не фреймворком для оркестровки контейнеров, а специальной прослойкой, управляющей метаданными (+ ресурсами, взаимосвязями, состояниями и т.п.) и передающей все реальные задачи на исполнение внешним системам.

Cattle поддерживала множество доступных на рынке решений: Docker Swarm, Apache Mesos, Kubernetes, — потому что, как пишут сами авторы, «пользователям Rancher нравилась идея внедрения платформы управления, дающей им свободу выбора фреймворка для оркестровки контейнеров».

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

Kubernetes: вчера, сегодня, завтра

В 2015 году, когда в Rancher Labs начинали работать с Kubernetes, т.е. добавлять её поддержку в свою платформу, основной проблемой в K8s, со слов разработчиков, была установка и первичная настройка системы. Поэтому гордость анонса ^[3] первичной поддержки Kubernetes в релизе Rancher v0.63 (17 марта 2016) звучала так: «Теперь вы можете запустить окружение Kubernetes в один клик и через 5—10 минут получить доступ к полностью развёрнутому кластеру».

Время шло, и следующим главным препятствием в применении Kubernetes, по мнению главы Rancher Labs, стала продолжающаяся эксплуатация и обновление кластеров. К концу прошлого года и эта проблема перестала быть серьёзной — благодаря активному развитию утилит вроде kops ^[4] и наметившейся тенденции предлагать Kubernetes как услугу (Kubernetes-as-a-Service). Это подтверждало размышления ^[5] Джо Беды (Joe Beda), основателя проекта Kubernetes в Google, а ныне — руководителя компании Heptio, о том, что следующей платформой для запуска современных приложений будет Kubernetes, а точнее — «Kubernetes станет ключевой частью этой платформы, но история на этом определённо не закончится».

А другим и более объективным подтверждением могут послужить совсем недавние события, такие как поддержка Kubernetes ^[6] в DC/OS от Mesosphere и официальное подключение к экосистеме Kubernetes ИТ-гигантов вроде Microsoft ^[7] и Oracle ^[8]. Одно только последнее присоединение к CNCF побудило онлайн-издание ARCHITECHT заявить ^[9], что «теперь, с Oracle на корабле, Kubernetes должен стать стандартом де-факто для оркестровки контейнеров».

В Rancher Labs «ставят» на то, что дальнейшим шагом на пути Kubernetes станет его превращение в «универсальный стандарт для инфраструктуры», что произойдёт в тот момент, когда пресловутый Kubernetes-as-a-Service станет типовой услугой у большинства поставщиков инфраструктуры:

«Команде DevOps больше не потребуется самостоятельно управлять кластерами Kubernetes. Единственная сложность, которая останется, — управлять доступными отовсюду кластерами Kubernetes и использовать их».

С мыслями об этом и взялись инженеры компании за крупное обновление Rancher — версию 2.0.

Rancher 2.0

Как и в Rancher 1.0, в версии 2.0 платформу составляют сервер (для управления всей инсталляцией) и агенты (устанавливаются на все обслуживаемые хосты). Основное отличие Rancher 2.0 от 1.0 заключается в том, что теперь в сервер встроен Kubernetes. Это означает, что при запуске Docker-образа rancher/server стартует кластер Kubernetes, и каждый новый добавляемый хост становится его частью (имеет kubelet). Кроме того, можно создавать дополнительные кластеры в дополнение к этому мастеру, а также импортировать уже существующие кластеры с помощью kops или от внешних поставщиков вроде Google (GKE). Агент Rancher запускается на всех встроенных и импортированных кластерах.

Надо всем этим множеством Kubernetes-кластеров в Rancher реализованы общие прослойки для централизованного управления ими (аутентификация и RBAC, provisioning, обновления, мониторинг, бэкапы) и взаимодействия с ними (веб-интерфейс для пользователя, API, CLI):

Более детально (до уровня хоста) архитектура Rancher 2.0 выглядит так:

Из прочих особенностей этого решения выделю следующие:

• Представленный на схеме Netes-agent — компонент, который отвечает за то, чтобы реализовывать в подах Kubernetes определения контейнеров Rancher. Этот агент подключается ко всем кластерам Kubernetes, делая их управляемыми.
• Встроенный в Rancher 2.0 мастер Kubernetes — это свой дистрибутив, включающий в себя API Server, Scheduler, Controller Manager. Эти три компонента объединены в единый процесс, запущенный в одном контейнере. По умолчанию бэкенд с БД всех кластеров помещается в одну базу данных («это значительно упрощает управление встроенными кластерами в Rancher»).
• В Rancher остался всего один компонент, написанный на Java (все остальные написаны на языке Go), — это Core controller. Он реализует в подах Kubernetes службы Rancher: сервисы, балансировщики нагрузки, DNS-записи. Наряду с Websocket proxy и Compose executor он входит в состав Rancher Controller, запускаемый на сервере Rancher (см. схему выше).
• Тома Rancher — это PersistentVolumeClaims ^[10] (PVC). Предусмотрено три типа томов, отличающихся своим жизненным циклом: Container scoped (создаются при создании контейнера, удаляются — при удалении контейнера), Service scoped (аналогично для сервисов), Environment scoped (существуют, пока есть окружение).
• Для сети поддерживаются решения Rancher IPSec или VXLAN overlay (было и раньше), а также сторонние плагины CNI ^[11] для встроенных кластеров. Для запуска контейнеров в изолированном пространстве также предлагаются два новых сетевых режима: «layer 3 routed» (на подсеть хоста) и «layer 2 flat».
• Rancher 2.0 позиционируется как решение, работающее со «стандартными SQL-СУБД, такими как MySQL». Для этого предлагается как пользоваться готовыми решениями Database-as-a-Service (например, RDS от AWS), так и настраивать их самостоятельно с помощью Galera Cluster для MySQL или MySQL NDB Cluster.
• Запланированные ограничения по масштабируемости: 1000 кластеров, 1000 хостов на кластер (и 10 тысяч хостов на все кластеры), 30 тысяч контейнеров на кластер (и 300 тысяч контейнеров на все кластеры).
• Поддерживаемые на данный момент версии Docker: 1.12.6, 1.13.1, 17.03-ce, 17.06-ce (что близко к списку совместимости вышедшего на днях Kubernetes 1.8 ^[12]).

Подробности о техническом устройстве Rancher 2.0 доступны в этом PDF-документе ^[13].

Кроме того, конечно, разработчики позаботились и об улучшениях в интерфейсе для конечного пользователя, сделав Rancher UI (и каталог приложений) ещё более простым и оставив продвинутым пользователям доступ к kubectl и Kubernetes dashboard. На YouTube выложена 15-минутная презентация Rancher 2.0 ^[14], демонстрирующая и внутренние изменения, и внешние.

Текущая версия Rancher 2.0, позиционируемая как tech preview и выпущенная неделю назад, — это v2.0.0-alpha6 ^[15]. Финальный релиз запланирован на 4-й квартал 2017 года.

CoreOS и fleet

Завершу рассказ о Rancher 2.0 совершенно другим примером — от CoreOS. Дело в том, что с их fleet ^[16] — довольно известным в DevOps-мире Open Source-продуктом — произошла похожая история, если смотреть на неё в контексте повсеместной адаптации Kubernetes. Характеризуемый как «распределённая init-система», fleet связывал systemd и etcd с целью использования systemd в масштабах кластера (вместо одной машины). Его создали для того, чтобы стать «основой для оркестровки более высокого уровня».

В конце прошлого года у проекта fleet сменили ^[17] статус с «проверен в production» до «более не разрабатывается и не поддерживается», а в начале этого года — уточнили, что образ с fleet перестанет быть частью Container Linux с 1 февраля 2018 года. Почему?

Вместо этого для всех кластерных потребностей CoreOS рекомендует установить Kubernetes.

В посвящённой этой теме заметке ^[18] в блоге CoreOS (от февраля 2017 года) уточняется, что Kubernetes «становится стандартом де-факто для оркестровки Open Source-контейнеров». Авторы также утверждают: «По ряду техническим и рыночных причин, Kubernetes — лучший инструмент для управления контейнерной инфраструктурой и её автоматизации в крупных масштабах».

P.S.

Читайте также в нашем блоге:

• Цикл про истории успеха Kubernetes в production: «№1: 4200 подов и TessMaster у eBay ^[19]», «№2: Concur и SAP ^[20]», «№3: GitHub ^[21]»;
• «Kubernetes 1.8: обзор основных новшеств ^[12]»;
• «Наш опыт с Kubernetes в небольших проектах ^[22]» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
• «Зачем нужен Kubernetes и почему он больше, чем PaaS? ^[23]».

Автор: shurup

Источник ^[24]