Зачем нужен Kubernetes и почему он больше, чем PaaS?



    В большой 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 — подписывайтесь на хаб и ожидайте их уже в ближайшее время.
    Флант 330,80
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поделиться публикацией
    Комментарии 37
      +2
      Я почему-то с жалостью смотрю на тех, кто рискует админить такое:
      https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#server-binaries-16
      (смотреть начиная с WARNING: etcd backup strongly recommended)
      Особый вкус:
      HA installations cannot be migrated at the current time using the official Kubernetes procedure

      This change is irreversible

      Мечта ops-команды
        +1
        Любой апгрейд чего-либо требует резервной копии в продакшене. И что?
          0
          А вы кроме
          WARNING: etcd backup strongly recommended
          остальное читали?
          Например, про невозможность безостановочного обновления при HA инсталляции?
          Или про невозможность отката?
          +2
          Кроме шуток, это действительно мечта ops-команды. Архитектура Kubernetes позволяет обновлять вот такие ключевые компоненты инфраструктуры вообще без даунтайма.

          Даже если у вас очень дешёвый сетап и нет резервного кластера, на который можно переключить нагрузку на время обслуживания, проблемы при обновлении Kubernetes не фатальны. Можно даже пристрелить все управляющие компоненты Kubernetes разом, а ваши приложения продолжат работать. Даже если новая версия etcd+kubernetes не встанет по какой-то причине, можно опять всё потушить, восстановить etcd из бэкапа, вернуть предыдущие версии и продолжить работу с того же места, как было до апдейта.
            +1
            Вы знаете, мне и с Mesos хорошо живется :)
            Абсолютно беспроблемное ПО.
            Да и разработка и документация не в пример лучгше, чем у k8s.
            Пока лично у меня впечатления по k8s — это бардак.
            Бардак в API, бардак в документации, бардак в https://github.com/kubernetes/kubernetes/issues — серьезно, ребят, 4200 незакрытых исью?
              0
              Вы еще не видели Cloud Foundry.

              Вообще Mesos/Marathon постабильней проект, но Кубернетис рветься вперед как по мне. Потому и куча изменений и нестабильностей.
                +1
                Ну вот как дорвется, тогда и буду использовать, я ж не против :)
                Пока же есть потребность решать задачи, а не заниматься ура-дебаггингом, то
                куча изменений и нестабильностей
                — это не то, что нужно бизнесу.
                  0
                  Согласен, это не то. Исходя из количества фич, частоты релизов, изменения терминологии и концептов, проект к стабильности только идет.
              +1
              А еще знаете, как профессиональные разработчики Kubernetes советуют решить зависимости внутри POD?
              https://github.com/kubernetes/kubernetes/issues/12526#issuecomment-280262668
              Wrap it in a `while true; do` loop?

              Вы знаете, после года использования Mesos в продакшене я очень рад, что остановился на нем, когда выбирал технологию…
                0
                Как вы умудряетесь выбирать между Mesos и K8S? Они ж для разных целей. Более того, они совместимы и можно запускать K8S поверх Mesos.
              0
              Миграция мажорных версий во многих приложениях непростая и сложная процедура. А если вы бэкапы не делает при миграциях, то это только пока.
                0
                Не нужно транслировать качество k8s на другие системы — в Mesos взаимная совместимость как минимум +-3 мажорных версии.
                Вы провидец, что говорите есть у меня бекапы или нет? У меня несколько уровней резервирования — каждый со своим RTO.
                  0
                  в Mesos взаимная совместимость как минимум +-3 мажорных версии.

                  Они выпустили только 1.4.0, или вы каждую минорную в 0.x.y считаете за мажорную, когда оно нестабильно в рамках semantic versioning? http://mesos.apache.org/documentation/latest/upgrades/ смотрели? Там про совместимость есть хорошая табличка.


                  Да, и что такое "взаимная совместимость"? Forward+Backward?

                    0
                    Да, в x.y.z в Mesos я говорил об y, как мажорной, в чем я конечно же, не совсем прав.
                    Если судить по k8s, то у них даже между минорными версиями интересное:
                    github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.6.md
                    поищите строку «WARNING: etcd backup strongly recommended»

                    Про табличку — я знаю ее прекрасно и «removed» там только незначительные вещи.
                    Что до совместимости, до версии 1.3, Mesos masters поддерживал Slaves 0.23+.
                    Теперь же, 1.X имеет полную прямую и обратную совместимость.
                      0

                      Совместимость в рамках 1.x — это абсолютно нормально с точки зрения semantic versioning.


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

                        0
                        Вы слишком формально подходите к semver в Mesos. Дело в том, что 1.0.0 релизнулся тогда, когда проект достиг достаточной стабильности и между 0.28.0 и 1.0.0 вообще нет несовместимых изменений/удалений и т.д. Это был просто очередной релиз.

                        Да, но делать в рамках минорной версии irreversible change — это, как минимум, странно и я уверен, что можно было сделать это бесшовно, но, почему-то, не захотели. Кстати, etcd3->etcd2 спокойно поддерживается.
              +1
              Зачем нужен Kubernetes и почему он больше, чем PaaS?

              Так зачем же он нужен, и почему он больше чем PaaS, особенно при том что:
              Kubernetes не предлагает никаких встроенных служб для обмена сообщениями, обработки данных, СУБД и т.п.
              Kubernetes не имеет своего магазина с готовыми сервисами для деплоя в один клик.
              Kubernetes не деплоит исходный код и не собирает приложения. Процессы непрерывной интеграции (CI) поддерживаются, но их реализация оставлена для других инструментов.
              Аналогично для систем журналирования и мониторинга.

              Из вашей статьи не понятно.
                0
                Вы точно всё прочитали? Жирным даже выделено:
                Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.

                Или вот: «в Kubernetes первичен универсальный, абстрактный подход». И вот: «платформа является модульной и предлагает пользователям самим выбирать конкретные решения для тех или иных задач». И в конце пример со стандартной библиотекой и фундаментом…
                  +2
                  Да, точно. Более того — уже пару лет использую Kubernetes в проде, но тем не менее ничего не понял.
                    +1
                    Краткая суть, которую хотели здесь донести: основное предназначение k8s — предоставить всё необходимое для построения/обеспечения функций PaaS на её основе (а не только то, что нужно в каком-то одном конкретном или нескольких применениях — уж для этого существуют разные PaaS с более специализированным набором фич).

                    Если у вас есть реальный опыт и ваш вопрос не был самоцелью, поделитесь, пожалуйста, личным видением этого вопроса — тем более, если он сильно отличается или сильно более понятен. Всем на пользу пойдёт.
                +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, манифест, и всё — можно вообще забыть про их существование.
                  +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 года.
                    +2
                    Смотрите, никто не говорит, что Kubernetes — само совершенство и решает все проблемы в мире. Ему ещё развиваться и развиваться — спору нет. Однако тех фич, которые уже есть, достаточно, чтобы строить надёжные сервисы из обычного софта.

                    Точнее так. Те проблемы, которые сейчас Kubernetes не решает (такие, как диагностика сбойного железа), в мире без Kubernetes всё равно вам как-то решать надо — дополнительный софт для мониторинга ставить, скажем. Вы их можете точно так же и в мире с Kubernetes решать. Тот же самый дополнительный софт будет обнаруживать умирающие диски, а дальше вам надо просто сказать Kubernetes drain node и отправить машину в ремонт. Какую-то часть задач (и очень большую) Kubernetes успешно решает.

                    Kube proxy давно уже не юзер-спейс — он настраивает iptables на машине для проброса трафика напрямую на бэкенды. Точнее, он до сих пор умеет юзер-спейс делать, но его надо явно просить об этом. По умолчанию — iptables. Там с сетью другая история — поскольку на каждый под выделяется отдельный IP, то нужна маршрутизация для этих адресов. Если у вас своя физическая сеть и адресов до фига и не жалко, то можно просто выделить на каждую ноду свою подсеть, из которой будут IP выделяться, и использовать обычную маршрутизацию, а если нет, то надо IPVS городить. Что именно и как в GCE/GKE устроено — я не знаю.

                    Про Docker я не в курсе, что там с лицензиями. Будет совсем плохо, реализуют поддержку чего-нибудь другого. Не вижу архитектурных препятствий.

                    На самом деле, если использовать GKE, вся эта сложность от вас скрывается платформой. И сеть, и диски просто работают. Я вообще за Kubernetes сейчас топлю не потому что в гугле работаю, а потому что как пользователь реально перенёс свои проекты и вообще забыл как страшный сон про дыры в безопасности, плановые остановки для накатывания обновлений, отказывающее железо и прочую боль.
                      0
                      Спасибо за развернутый коментарий!
                      Да, по набору фич, Kubernetes сейчас #1, тут спору нет.
                      И пользоваться им удобно(это я с точки зрения пользователя говорю).
                      Я про эту сторону вообще не спорю и полностью согласен.
                      Но вот с точки зрения поддержки — это кошмар. Может нужно просто привыкнуть жить в такой, кхм, «сильно меняющейся среде», но выглядит пока сильно нестабильным.
                      Пока из моих замечаний:
                      Крупные компании(Apple, Twitter, LinkedIn, Uber, etc) сидят на Mesos
                      Мелкие/стартапы — Docker Swarm, Kubernetes.
                      Наверное, стартапам рисковать можно :)
                        0
                        Про крупных пользователей не могу с вами согласиться. Разве уже упомянутый Google с GCE ­— не пример крупной компании? Red Hat с OpenShift? Huawei? eBay?

                        Совсем недавно было про Oracle.
                          0
                          Я все же подозреваю, что внутри Google используется Borg, а не k8s.
                          По другим компаниям — довольно занимательные новости, спасибо!
                          Кстати, по eBay, не все так однозначно:
                          https://github.com/apache/mesos/blob/master/docs/powered-by-mesos.md

                            0
                            Про 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.
                              0
                              Ну, в 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


                              Вообще интересно было бы послушать их опыт перехода постфактум, на какие грабли пришлось наступить и т.д.
                              Я же не зашоренный человек, открыт к будущему, просто рационально отношусь к вещам :)
                              0
                              > Кстати, по eBay, не все так однозначно:
                              github.com/apache/mesos/blob/master/docs/powered-by-mesos.md

                              mesos или mesos/marathon? Если же говорить исключительно о первом — то это ж ведь не то же самое, что и кубернетис.
                                0
                                В том и его прелесть, одна платформа и для контейнеров(кстати, ну почему сразу Marathon, у нас, например и Aurora используется), и для Spark, и еще куча всего
                            0
                            Kubernetes это уже скорее средний бизнес, мелкому/стартапам это оверкилл. Вот прямо в данный момент, например, думаю о том чтоб переезжать с docker cloud на kubernetes, из-за роста компании/софта.

                            Наверное, стартапам рисковать можно :)

                            Не подскажите где можно найти Mesos как сервис?
                              0
                              Если нужен деплоймент плаформы as a service на вашем железе(или виртуальной среде), то можете взглянуть на
                              https://rancher.com/
                              https://mesosphere.com/

                              Возможно, есть и другие, эти вспомнил навскидку
                                0
                                Не обязательно на моём железе, любое подойдёт. Тут скорее вопрос про то чтоб ничего не ставить и не настраивать/поддерживать. Как например docker cloud или kubernetes на GCE.
                        0
                        Спасибо за полезный комментарий. Конкретные фичи, которые предлагает k8s, очень кратко описаны в докладе (на него ссылка в конце статьи). А для больших подробностей планируем цикл, потому что в одну статью это не уложишь.
                          0
                          > Новизна Kubernetes в том, что можно взять любое обычное приложение, которое никто никогда в жизни не планировал для жизни в облаке

                          Нет. В контейнерах должно работать одно приложение, стейтлесс, да еще и по размеру не большое. Если же у вас контейнеры с приложением по 2ГБ — то это уже совсем не то. Да еще и нормальное АПИ должно быть у компонентов. Т.е. контейнеры и Кубернетис в принципе не для таких гигантов как Друпал и т.п.
                            0
                            Вообще, я бы не был так категоричен — есть разные мнения на этот счёт. Хотя и я лично тоже считаю, что новые приложения нужно разрабатывать так, как вы говорите (микросервисы, по максимуму стейтлесс, нормальные API), но… Если у вас уже есть легаси-приложения, которые уже работают на обычных серверах, то даже ради одного только self-recovery их имеет смысл запихать в контейнеры и положить в облако.
                              0
                              Легаси апликейшен пусть работает там где работает. 20 ГБ контейнеры с какими-то Маджентами — это не разговор вообще.

                              > то даже ради одного только self-recovery их имеет смысл запихать в контейнеры и положить в облако.

                              Может нужно посмотреть какой-то селф рекавери на чем-то традиционном? Ну в плане зачем Кубернетис, если можно пересоздавать виртуалку или какой-нибудь контейнер LXC/OpenVZ в чем-то типа Proxmox?

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое