Неделю назад разработчики Rancher представили предварительный релиз своей будущей крупной версии — 2.0, — попутно объявив о переходе на Kubernetes в качестве единой основы для оркестровки контейнеров. Что побудило разработчиков пойти таким путём?
Предыстория: Cattle
Rancher 1.0 вышел в марте прошлого года, и на сегодняшний день в мире, по данным компании Rancher Labs, насчитывается более 10 тысяч его действующих инсталляций и более 100 коммерческих пользователей. Первая версия Rancher включала в себя Cattle, который, будучи «высокоуровневым компонентом, написанным на Java», назывался «базовым движком оркестровки» и «основным циклом всей системы». В сущности же Cattle был даже не фреймворком для оркестровки контейнеров, а специальной прослойкой, управляющей метаданными (+ ресурсами, взаимосвязями, состояниями и т.п.) и передающей все реальные задачи на исполнение внешним системам.
Cattle поддерживала множество доступных на рынке решений: Docker Swarm, Apache Mesos, Kubernetes, — потому что, как пишут сами авторы, «пользователям Rancher нравилась идея внедрения платформы управления, дающей им свободу выбора фреймворка для оркестровки контейнеров».
Однако растущая популярность Kubernetes способствовала появлению всё новых и новых требований, предъявляемых пользователями Rancher к возможностям и удобству взаимодействия именно с этой системой. В то же время менялся и взгляд руководства Rancher Labs на актуальные проблемы Kubernetes и его перспективы.
Kubernetes: вчера, сегодня, завтра
В 2015 году, когда в Rancher Labs начинали работать с Kubernetes, т.е. добавлять её поддержку в свою платформу, основной проблемой в K8s, со слов разработчиков, была установка и первичная настройка системы. Поэтому гордость анонса первичной поддержки Kubernetes в релизе Rancher v0.63 (17 марта 2016) звучала так: «Теперь вы можете запустить окружение Kubernetes в один клик и через 5—10 минут получить доступ к полностью развёрнутому кластеру».
Время шло, и следующим главным препятствием в применении Kubernetes, по мнению главы Rancher Labs, стала продолжающаяся эксплуатация и обновление кластеров. К концу прошлого года и эта проблема перестала быть серьёзной — благодаря активному развитию утилит вроде kops и наметившейся тенденции предлагать Kubernetes как услугу (Kubernetes-as-a-Service). Это подтверждало размышления Джо Беды (Joe Beda), основателя проекта Kubernetes в Google, а ныне — руководителя компании Heptio, о том, что следующей платформой для запуска современных приложений будет Kubernetes, а точнее — «Kubernetes станет ключевой частью этой платформы, но история на этом определённо не закончится».
А другим и более объективным подтверждением могут послужить совсем недавние события, такие как поддержка Kubernetes в DC/OS от Mesosphere и официальное подключение к экосистеме Kubernetes ИТ-гигантов вроде Microsoft и Oracle. Одно только последнее присоединение к CNCF побудило онлайн-издание ARCHITECHT заявить, что «теперь, с 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 (PVC). Предусмотрено три типа томов, отличающихся своим жизненным циклом: Container scoped (создаются при создании контейнера, удаляются — при удалении контейнера), Service scoped (аналогично для сервисов), Environment scoped (существуют, пока есть окружение).
- Для сети поддерживаются решения Rancher IPSec или VXLAN overlay (было и раньше), а также сторонние плагины CNI для встроенных кластеров. Для запуска контейнеров в изолированном пространстве также предлагаются два новых сетевых режима: «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).
Подробности о техническом устройстве Rancher 2.0 доступны в этом PDF-документе.
Кроме того, конечно, разработчики позаботились и об улучшениях в интерфейсе для конечного пользователя, сделав Rancher UI (и каталог приложений) ещё более простым и оставив продвинутым пользователям доступ к kubectl и Kubernetes dashboard. На YouTube выложена 15-минутная презентация Rancher 2.0, демонстрирующая и внутренние изменения, и внешние.
Текущая версия Rancher 2.0, позиционируемая как tech preview и выпущенная неделю назад, — это v2.0.0-alpha6. Финальный релиз запланирован на 4-й квартал 2017 года.
CoreOS и fleet
Завершу рассказ о Rancher 2.0 совершенно другим примером — от CoreOS. Дело в том, что с их fleet — довольно известным в DevOps-мире Open Source-продуктом — произошла похожая история, если смотреть на неё в контексте повсеместной адаптации Kubernetes. Характеризуемый как «распределённая init-система», fleet связывал systemd и etcd с целью использования systemd в масштабах кластера (вместо одной машины). Его создали для того, чтобы стать «основой для оркестровки более высокого уровня».
В конце прошлого года у проекта fleet сменили статус с «проверен в production» до «более не разрабатывается и не поддерживается», а в начале этого года — уточнили, что образ с fleet перестанет быть частью Container Linux с 1 февраля 2018 года. Почему?
Вместо этого для всех кластерных потребностей CoreOS рекомендует установить Kubernetes.
В посвящённой этой теме заметке в блоге CoreOS (от февраля 2017 года) уточняется, что Kubernetes «становится стандартом де-факто для оркестровки Open Source-контейнеров». Авторы также утверждают: «По ряду техническим и рыночных причин, Kubernetes — лучший инструмент для управления контейнерной инфраструктурой и её автоматизации в крупных масштабах».
P.S.
Читайте также в нашем блоге:
- Цикл про истории успеха Kubernetes в production: «№1: 4200 подов и TessMaster у eBay», «№2: Concur и SAP», «№3: GitHub»;
- «Kubernetes 1.8: обзор основных новшеств»;
- «Наш опыт с Kubernetes в небольших проектах» (видео доклада, включающего в себя знакомство с техническим устройством Kubernetes);
- «Зачем нужен Kubernetes и почему он больше, чем PaaS?».
Автор: shurup
