В большой production пришёл не только Docker, но и Kubernetes. И если даже с контейнерами далеко не всегда всё достаточно просто, то уж «кормчий» и подавно остаётся за гранью правильного понимания среди многих системных администраторов, DevOps-инженеров, разработчиков. В этой небольшой статье предпринята попытка ответить на один из вечных вопросов (в контексте Kubernetes) с помощью наглядного объяснения идеи и особенностей данного проекта. Возможно, именно этого вам не хватало для того, чтобы начать плотное знакомство с Kubernetes или даже его эксплуатацию?
Соучредитель и архитектор крупного онлайн-сервиса Box (около 1400 сотрудников) Sam Ghods в своём прошлогоднем выступлении на KubeCon указал на типовую ошибку восприятия Kubernetes. Многие рассматривают этот продукт как очередной фреймворк для оркестровки контейнеров. Но если бы всё действительно было так, то зачем его разработчики неустанно напоминают про «корни Kubernetes API, уходящие в архитектуру*, создаваемую более 10 лет в рамках проекта Google Borg»?..
Google Borg — это менеджер кластеров, предназначенный для параллельного запуска тысяч задач, распределённых по тысячам приложений, запускаемых на многочисленных кластерах. Именно эту архитектуру и унаследовал Kubernetes, перенося кластерные идеи на современную почву контейнеров. Чем же это отличается от многочисленных облачных платформ, существующих сегодня? Начнём с самого понятия платформы.
* Архитектура Kubernetes создана таким образом, что позволяет расширять эту платформу, но разработчиков при этом просят следовать основополагающим принципам.
Kubernetes как платформа
Архитектор Box даёт такой вариант определения: «Платформа предоставляет уровень абстракции, забирающий у вас какую-либо проблему, чтобы вы могли творить поверх неё [не думая о ней]». Примеры: платформа Linux даёт возможность исполнять системные вызовы вне зависимости от аппаратного обеспечения компьютера, а платформа Java — исполнять приложения вне зависимости от операционной системы. Какова же должна быть платформа для запуска приложений, созданных по принципам микросервисной архитектуры?
Ключевые характеристики такой платформы — портируемость и расширяемость. Каждая облачная платформа предлагает свои варианты для достижения этих целей. Например, для автоматического масштабирования у AWS имеются Auto Scaling Groups, у Google Cloud Platform — Autoscaler, у Microsoft Azure — Scale Set, у OpenStack — autoscaling API в Heat. Всё это само по себе неплохо, т.к. потребности выполняются, однако у конечного пользователя начинаются сложности. Чтобы разместить приложение, для каждого сервисного провайдера необходимо поддерживать его механизмы: добавлять поддержку API, учитывать специфику работы используемой реализации и т.п. Вдобавок, всем этим решениям не хватает системы обнаружения сервисов для по-настоящему удобного и автоматизированного развёртывания микросервисов. А если вам нужно быть гибким и иметь возможность размещать приложения в разных окружениях (в публичном облаке, в своём дата-центре, на серверах клиента…)?
В этом заключается первый плюс и суть Kubernetes как платформы, то есть по-настоящему универсальной системы для развёртывания приложений, физическое размещение которых может производиться где и как угодно: на голом железе, в публичных или частных облаках вне зависимости от их разработчиков и специфичных API. Но здорово в Kubernetes не только то, где запускать, но и что: ведь это могут приложения на разных языках и под разные ОС, они могут быть stateless и stateful. Поддерживается принцип «если приложение может запускаться в контейнере, оно должно отлично запускаться в Kubernetes».
Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.
Kubernetes и PaaS
О том, что Kubernetes не является традиционной PaaS, рассказывается в документации проекта, где поясняется, что авторы стремятся сохранить возможность пользовательского выбора в местах, где это важно. В частности, поэтому:
- Kubernetes не предлагает никаких встроенных служб для обмена сообщениями, обработки данных, СУБД и т.п.
- Kubernetes не имеет своего магазина с готовыми сервисами для деплоя в один клик.
- Kubernetes не деплоит исходный код и не собирает приложения. Процессы непрерывной интеграции (CI) поддерживаются, но их реализация оставлена для других инструментов.
- Аналогично для систем журналирования и мониторинга.
Таким образом, если в PaaS обычно делается акцент на предоставление функциональных возможностей, то в Kubernetes первичен универсальный, абстрактный подход. Несмотря на то, что Kubernetes предлагает ряд функций, которые традиционно присущи PaaS: развёртывание приложений, масштабирование, балансировка нагрузок, журналирование и т.п., — платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач. Такой подход сделал Kubernetes базой для таких PaaS, как OpenShift от Red Hat и Deis.
Заключение
Kubernetes следует принципу, к которому обычно (впрочем, не всегда) стремятся в стандартах. Его хорошо проиллюстрировал Бьёрн Страуструп в своей классической книге «The C++ Programming Language»:
Что должно быть в стандартной библиотеке C++? Идеалом для программиста является возможность найти каждый интересный, значимый и разумно обобщённый класс, функцию, шаблон и т.п. в библиотеке. Однако вопрос не в том, «что должно быть в какой-то библиотеке», а в том, «что должно быть в стандартной библиотеке». И ответ «Всё!» — первое разумное приближение к ответу на первый вопрос, но не последний. Стандартная библиотека — то, что должен предоставлять каждый автор и делать это так, чтобы каждый программист мог на это положиться [т.е. действительно нуждался в этом — прим. перев.].
Применительно к Kubernetes можно сказать, что эта система — фундамент, та самая «стандартная библиотека» для построения PaaS и других подобных решений.
P.S. Если хотите разобраться в техническом устройстве и практике применения Kubernetes — смотрите видео из моего недавнего доклада «Наш опыт с Kubernetes в небольших проектах». Для более подробного и глубокого погружения мы готовим цикл статей по Kubernetes — подписывайтесь на хаб и ожидайте их уже в ближайшее время.
Комментарии (22)
Caravus
26.06.2017 15:23+1Зачем нужен Kubernetes и почему он больше, чем PaaS?
Так зачем же он нужен, и почему он больше чем PaaS, особенно при том что:
Kubernetes не предлагает никаких встроенных служб для обмена сообщениями, обработки данных, СУБД и т.п.
Kubernetes не имеет своего магазина с готовыми сервисами для деплоя в один клик.
Kubernetes не деплоит исходный код и не собирает приложения. Процессы непрерывной интеграции (CI) поддерживаются, но их реализация оставлена для других инструментов.
Аналогично для систем журналирования и мониторинга.
Из вашей статьи не понятно.
shurup
26.06.2017 16:42Вы точно всё прочитали? Жирным даже выделено:
Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.
Или вот: «в Kubernetes первичен универсальный, абстрактный подход». И вот: «платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач». И в конце пример со стандартной библиотекой и фундаментом…Caravus
26.06.2017 16:47+2Да, точно. Более того — уже пару лет использую Kubernetes в проде, но тем не менее ничего не понял.
shurup
26.06.2017 17:01+1Краткая суть, которую хотели здесь донести: основное предназначение k8s — предоставить всё необходимое для построения/обеспечения функций PaaS на её основе (а не только то, что нужно в каком-то одном конкретном или нескольких применениях — уж для этого существуют разные PaaS с более специализированным набором фич).
Если у вас есть реальный опыт и ваш вопрос не был самоцелью, поделитесь, пожалуйста, личным видением этого вопроса — тем более, если он сильно отличается или сильно более понятен. Всем на пользу пойдёт.
aml
26.06.2017 19:00+4Блин, люди, Kubernetes — это game changer. Но статья с таким названием обязана хоть что-то рассказать про то, какие реальные преимущества получат пользователи, а не просто общие слова из презентации для бизнес-менеджеров.
Новизна Kubernetes в том, что можно взять любое обычное приложение, которое никто никогда в жизни не планировал для жизни в облаке, которое представления не имеет о том, что такое service discovery, failover, high availability, балансировка нагрузки, изоляция, мониторинг, облачные логи, zero-downtime system maintenance, canarying, rollbacks, и без всякой модификации, при помощи одного только манифеста получить все эти свойства разом.
Если использовать Google Container Engine (это Kubernetes, который мы предоставляем как сервис), то запуск сервисов вообще превращается в fire and forget. Машины умирают, диски отказывают, обновляется системный софт, а ваши приложения остаются железобетонно доступными. И для этого вообще ничего не надо делать (счета оплачивать разве что). Что очень важно, у вас при этом не образуется vendor lock. В любой момент можно переехать на инфраструктуру другого облака или на своё железо.
Я потихоньку перетаскиваю все свои личные проекты в GKE. И по опыту могу сказать, что один раз пишешь Dockerfile, манифест, и всё — можно вообще забыть про их существование.
g0dlike
26.06.2017 22:49+1Знаете, это плохо советовать людям использовать сырую, постоянно меняющуюся среду.
Kubernetes сначала необходимо вырасти, решить детские проблемы(например, хотя бы реализовать квоты для write-layer, логов, при чем по нормальному, а не с помощью du), написать нормальную документацию(честно, раздражают эти инструкции с kubeadm, вы серьезно считаете, что k8s нужно продвигать как черный ящик с кнопочками для обезьян?). Я еле нашел https://github.com/kelseyhightower/kubernetes-the-hard-way в свое время.
Вы серьезно думаете, что kubernets решает все проблемы? Неужели вы никогда не встречали умирающего, но все еще живого жесткого диска(при чем мониторинг у вас показывает, что все ОК), который убивает все IO на сервере? И будете очень долго дебажить, что же у вас происходит. Или уменьшение mtu на транзитном оборудовании, где еще и все ICMP порезали. K8s — это не простая платформа, а сложный большой комок компонентов.
Или взять тот же LoadBalancing. Кому пришло в голову назвать «высокопроизводительным» Userspace-решение Kube-Proxy, которое еще и трафик наверное отдает через точку входа? Вы в Google уже отказались от IPVS?
Более того, взяли Docker (ну или rkt, неважно) — завязались на чужого вендора — зачем? Почему не сделали на Cgroups + Namespaces + CNI + ...?
Зато теперь имеете изменение политики лицензирования Docker и черт знает что еще взбредет в голову в будущем этому вендору…
В общем, кучу спорных решений.
ИМХО, до стабилизации k8s еще минимум 2 года.aml
27.06.2017 06:44+2Смотрите, никто не говорит, что Kubernetes — само совершенство и решает все проблемы в мире. Ему ещё развиваться и развиваться — спору нет. Однако тех фич, которые уже есть, достаточно, чтобы строить надёжные сервисы из обычного софта.
Точнее так. Те проблемы, которые сейчас Kubernetes не решает (такие, как диагностика сбойного железа), в мире без Kubernetes всё равно вам как-то решать надо — дополнительный софт для мониторинга ставить, скажем. Вы их можете точно так же и в мире с Kubernetes решать. Тот же самый дополнительный софт будет обнаруживать умирающие диски, а дальше вам надо просто сказать Kubernetes drain node и отправить машину в ремонт. Какую-то часть задач (и очень большую) Kubernetes успешно решает.
Kube proxy давно уже не юзер-спейс — он настраивает iptables на машине для проброса трафика напрямую на бэкенды. Точнее, он до сих пор умеет юзер-спейс делать, но его надо явно просить об этом. По умолчанию — iptables. Там с сетью другая история — поскольку на каждый под выделяется отдельный IP, то нужна маршрутизация для этих адресов. Если у вас своя физическая сеть и адресов до фига и не жалко, то можно просто выделить на каждую ноду свою подсеть, из которой будут IP выделяться, и использовать обычную маршрутизацию, а если нет, то надо IPVS городить. Что именно и как в GCE/GKE устроено — я не знаю.
Про Docker я не в курсе, что там с лицензиями. Будет совсем плохо, реализуют поддержку чего-нибудь другого. Не вижу архитектурных препятствий.
На самом деле, если использовать GKE, вся эта сложность от вас скрывается платформой. И сеть, и диски просто работают. Я вообще за Kubernetes сейчас топлю не потому что в гугле работаю, а потому что как пользователь реально перенёс свои проекты и вообще забыл как страшный сон про дыры в безопасности, плановые остановки для накатывания обновлений, отказывающее железо и прочую боль.g0dlike
27.06.2017 09:48Спасибо за развернутый коментарий!
Да, по набору фич, Kubernetes сейчас #1, тут спору нет.
И пользоваться им удобно(это я с точки зрения пользователя говорю).
Я про эту сторону вообще не спорю и полностью согласен.
Но вот с точки зрения поддержки — это кошмар. Может нужно просто привыкнуть жить в такой, кхм, «сильно меняющейся среде», но выглядит пока сильно нестабильным.
Пока из моих замечаний:
Крупные компании(Apple, Twitter, LinkedIn, Uber, etc) сидят на Mesos
Мелкие/стартапы — Docker Swarm, Kubernetes.
Наверное, стартапам рисковать можно :)shurup
27.06.2017 10:16Про крупных пользователей не могу с вами согласиться. Разве уже упомянутый Google с GCE — не пример крупной компании? Red Hat с OpenShift? Huawei? eBay?
Совсем недавно было про Oracle.g0dlike
27.06.2017 10:27Я все же подозреваю, что внутри Google используется Borg, а не k8s.
По другим компаниям — довольно занимательные новости, спасибо!
Кстати, по eBay, не все так однозначно:
https://github.com/apache/mesos/blob/master/docs/powered-by-mesos.md
shurup
27.06.2017 10:47Про eBay я находил упоминания Mesos от 2014 года, а с 2015 гуглится уже Kubernetes. Здесь пишут так (кстати, прямо в пику утверждений о зрелости проектов :-)):
At the time eBay started searching for an answer, Docker Swarm had yet to emerge, Mesos was a young open source code project (later supported and productized through the firm Mesosphere) and Kubernetes was just emerging from Google's halls. Early in 2016, having played the field, eBay settled on Kubernetes as the most mature option.
А вот достаточно свежее (2017 год), что всё-таки k8s.g0dlike
27.06.2017 12:35Ну, в eBay про зрелость все же не совсем правы :)
Mesos:
commit 9bc36de05a9542a319d348505a1838f9190a6c21
Author: Benjamin Hindman <benh@apache.org>
Date: Sun Jun 5 03:04:24 2011 +0000
Initial commit.
Kubernetes:
commit 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56
Author: Joe Beda <joe.github@bedafamily.com>
Date: Fri Jun 6 16:40:48 2014 -0700
First commit
Вообще интересно было бы послушать их опыт перехода постфактум, на какие грабли пришлось наступить и т.д.
Я же не зашоренный человек, открыт к будущему, просто рационально отношусь к вещам :)
Caravus
27.06.2017 10:36Kubernetes это уже скорее средний бизнес, мелкому/стартапам это оверкилл. Вот прямо в данный момент, например, думаю о том чтоб переезжать с docker cloud на kubernetes, из-за роста компании/софта.
Наверное, стартапам рисковать можно :)
Не подскажите где можно найти Mesos как сервис?g0dlike
27.06.2017 12:32Если нужен деплоймент плаформы as a service на вашем железе(или виртуальной среде), то можете взглянуть на
https://rancher.com/
https://mesosphere.com/
Возможно, есть и другие, эти вспомнил навскидкуCaravus
27.06.2017 13:25Не обязательно на моём железе, любое подойдёт. Тут скорее вопрос про то чтоб ничего не ставить и не настраивать/поддерживать. Как например docker cloud или kubernetes на GCE.
g0dlike
Я почему-то с жалостью смотрю на тех, кто рискует админить такое:
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#server-binaries-16
(смотреть начиная с WARNING: etcd backup strongly recommended)
Особый вкус:
Мечта ops-команды
KIVagant
Любой апгрейд чего-либо требует резервной копии в продакшене. И что?
g0dlike
А вы кроме
остальное читали?Например, про невозможность безостановочного обновления при HA инсталляции?
Или про невозможность отката?
aml
Кроме шуток, это действительно мечта ops-команды. Архитектура Kubernetes позволяет обновлять вот такие ключевые компоненты инфраструктуры вообще без даунтайма.
Даже если у вас очень дешёвый сетап и нет резервного кластера, на который можно переключить нагрузку на время обслуживания, проблемы при обновлении Kubernetes не фатальны. Можно даже пристрелить все управляющие компоненты Kubernetes разом, а ваши приложения продолжат работать. Даже если новая версия etcd+kubernetes не встанет по какой-то причине, можно опять всё потушить, восстановить etcd из бэкапа, вернуть предыдущие версии и продолжить работу с того же места, как было до апдейта.
g0dlike
Вы знаете, мне и с Mesos хорошо живется :)
Абсолютно беспроблемное ПО.
Да и разработка и документация не в пример лучгше, чем у k8s.
Пока лично у меня впечатления по k8s — это бардак.
Бардак в API, бардак в документации, бардак в https://github.com/kubernetes/kubernetes/issues — серьезно, ребят, 4200 незакрытых исью?
g0dlike
А еще знаете, как профессиональные разработчики Kubernetes советуют решить зависимости внутри POD?
https://github.com/kubernetes/kubernetes/issues/12526#issuecomment-280262668
Вы знаете, после года использования Mesos в продакшене я очень рад, что остановился на нем, когда выбирал технологию…