- PVSM.RU - http://www.pvsm.ru -

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

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

Неделю назад разработчики 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 и почему он переходит на Kubernetes? - 2

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

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

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

  • Представленный на схеме 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.

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

Автор: shurup

Источник [24]


Сайт-источник PVSM.RU: http://www.pvsm.ru

Путь до страницы источника: http://www.pvsm.ru/sistemnoe-administrirovanie/264817

Ссылки в тексте:

[1] представили: http://rancher.com/announcing-rancher-2-0/

[2] Cattle: https://github.com/rancher/rancher/wiki/Overview%3A-What-is-Cattle

[3] анонса: http://rancher.com/rancher-now-supports-kubernetes/

[4] kops: https://github.com/kubernetes/kops

[5] размышления: https://www.nextplatform.com/2015/10/16/stacking-up-a-modern-platform/

[6] поддержка Kubernetes: https://mesosphere.com/blog/kubernetes-dcos/

[7] Microsoft: https://azure.microsoft.com/en-us/blog/announcing-cncf/

[8] Oracle: https://blogs.oracle.com/developers/oracle-joins-cncf-doubles-down-further-on-kubernetes

[9] заявить: http://news.architecht.io/issues/with-oracle-on-board-kubernetes-has-to-be-the-de-facto-standard-for-container-orchestration-73880

[10] PersistentVolumeClaims: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims

[11] плагины CNI: https://habrahabr.ru/company/flant/blog/329830/

[12] Kubernetes 1.8: https://habrahabr.ru/company/flant/blog/338230/

[13] этом PDF-документе: https://cdn2.hubspot.net/hubfs/468859/Whitepapers/Rancher%202.0%20Technical%20Architecture%20-%20Sept%202017.pdf

[14] презентация Rancher 2.0: https://www.youtube.com/watch?v=Ma6FsuWI2Nc

[15] v2.0.0-alpha6: https://github.com/rancher/rancher/releases/tag/v2.0.0-alpha6

[16] fleet: https://github.com/coreos/fleet

[17] сменили: https://github.com/coreos/fleet/commit/9635dbb7333e0c5bcd5ce70dc15052cac0b1463f#diff-04c6e90faac2675aa89e2176d2eec7d8

[18] заметке: https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html

[19] №1: 4200 подов и TessMaster у eBay: https://habrahabr.ru/company/flant/blog/334140/

[20] №2: Concur и SAP: https://habrahabr.ru/company/flant/blog/334770/

[21] №3: GitHub: https://habrahabr.ru/company/flant/blog/335814/

[22] Наш опыт с Kubernetes в небольших проектах: https://habrahabr.ru/company/flant/blog/331188/

[23] Зачем нужен Kubernetes и почему он больше, чем PaaS?: https://habrahabr.ru/company/flant/blog/327338/

[24] Источник: https://habrahabr.ru/post/339120/