Kubernetes: open source против вендорского

    Привет, меня зовут Дмитрий Краснов. Уже более пяти лет я занимаюсь администрированием кластеров Kubernetes и построением сложных микросервисных архитектур. В начале этого года мы запустили сервис по управлению кластерами Kubernetes на базе Containerum. Пользуясь поводом расскажу, что представляет собой этот самый Kubernetes и чем интеграция с вендором отличается от open source.

    Для начала, что такое Kubernetes. Это система для управления контейнерами на большом количестве хостов. С греческого, кстати, переводится как «пилот» или «рулевой». Изначально разработана Google, после чего в качестве технологического вклада передана Cloud Native Computing Foundation, международной некоммерческой организации, которая объединяет ведущих мировых разработчиков, конечных пользователей и поставщиков контейнерных технологий.



    Рулить большим числом контейнеров


    Теперь разберемся, что это еще за контейнеры. Это приложение со всем его окружением – в основном, библиотеками, от которых зависит работа программы. Все это запаковано в архивы и представлено в виде образа, который можно запускать вне зависимости от операционной системы, тестировать и не только. Но есть проблема — управлять контейнерами на большом количестве хостов очень сложно. Поэтому и был создан Kubernetes.

    Образ контейнера представляет собой приложение плюс его зависимости. Приложение, его зависимости и образ файловой системы ОС располагаются в разных частях образа, так называемых слоях. Слои могут переиспользоваться для разных контейнеров. Например, для всех приложений в компании может использоваться базовый слой Ubuntu. При запуске контейнеров нет нужды хранить на хосте множество копий одного базового слоя. Это позволяет оптимизировать хранение и доставку образов.

    Когда мы хотим запустить приложение из контейнера, нужные слои накладываются друг на друга и образуется оверлейная файловая система. Сверху накладывается слой для записи, который, при остановке контейнера, удаляется. Это гарантирует, что при запуске контейнера у приложения всегда будет одинаковое окружение, которое не может быть изменено. Это гарантирует воспроизводимость окружения на разных хостовых ОС. Будь то Ubuntu или CentOS, — окружение всегда будет одинаковым. К тому же контейнер изолирован от хоста при помощи встроенных в ядро Linux механизмов. Приложения в контейнере не видят файлы, процессы хоста и соседних контейнеров. Такая изоляция приложений от хостовой ОС даёт дополнительный слой безопасности.

    Для управления контейнерами на хосте есть множество инструментов. Самый популярный из них, — это Docker. Он позволяет обеспечить полный жизненный цикл работы контейнеров. Однако он работает только на одном хосте. При необходимости управления контейнерами на множестве хостов Docker может превратить жизнь инженеров в ад. Потому и был создан Kubernetes.

    Востребованность Kubernetes как раз и обусловлена возможностью рулить группами контейнеров на множестве хостов как некими едиными сущностями. Популярность системе обеспечивает возможность построить DevOps или Development Operations, в которых Kubernetes используется для запуска процессов этого самого DevOps.



    Рисунок 1. Схематичное изображение принципа работы Kubernetes

    Полная автоматизация


    DevOps, в принципе, представляет собой автоматизацию процесса разработки. Грубо говоря, разработчики пишут код, который заливается в репозиторий. Затем этот код может автоматически собираться сразу в контейнер со всеми библиотеками, тестироваться и «выкатываться» на следующую стадию – Staging, а затем сразу и на Production.

    Вместе с Kubernetes DevOps позволяет автоматизировать этот процесс, чтобы он протекал практически без участия самих разработчиков. За счет этого значительно ускоряется сборка, поскольку разработчику не приходится заниматься этим у себя на компьютере — он просто пишет кусок кода, пушит код в репозиторий, после чего запускается pipeline, который может включать в себя процесс сборки, тестирования, выкатки. И так происходит с каждым коммитом, поэтому тестирование происходит непрерывно.

    При этом использование контейнера позволяет быть уверенным в том, что все окружение этой программы выйдет в production именно в том виде, в котором тестировалось. То есть не возникнет проблем из разряда «на тесте были одни версии, в production – другие, а поставили – все упало». А поскольку сегодня мы имеем тренд на микросервисную архитектуру, когда вместо одного огромного приложения есть сотни маленьких, то для того чтобы администрировать их вручную, — потребуется огромный штат сотрудников. Поэтому мы и используем Kubernetes.

    Плюсы, плюсы, плюсы


    Если говорить о достоинствах Kubernetes как платформы, то у него существенные плюсы с точки зрения управления микросервисной архитектурой.

    • Управление множеством реплик. Самое главное — это управление контейнерами на множестве хостов. И что более важно, — управление множеством реплик приложений в контейнерах как единой сущностью. Благодаря этому инженерам не нужно заботиться о каждом отдельном контейнере. Если один из контейнеров упадёт, то Kubernetes увидит это и перезапустит его снова.
    • Кластерная сеть. Также у Kubernetes есть так называемая кластерная сеть с собственным адресным пространством. Благодаря этому каждый под имеет свой адрес. Под подом понимается минимальная структурная единица кластера, в которой непосредственно запускаются контейнеры. К тому же у Kubernetes есть функционал, который совмещает в себе балансировщик нагрузки и Service Discovery. Это позволяет избавиться от ручного управления IP-адресами и возложить эту задачу на плечи Kubernetes. А автоматические health check`и помогут обнаружить проблемы и перенаправить трафик на рабочие поды.
    • Управление конфигурациями. При управлении большим количеством приложений становится сложно управлять конфигурацией приложений. Для этого в Kubernetes есть специальные ресурсы ConfigMap`ы. Они позволяют централизованно хранить конфигурации и подставлять их в поды при запуске приложений. Такой механизм позволяет гарантировать консистентность конфигурации хоть в десяти, хоть в сотне реплик приложений.
    • Persistent Volumes. Контейнеры по своей сути иммутабельны и при остановке контейнера все данные, записанные на файловую систему, будут уничтожены. Но некоторые приложения хранят данные прямо на диске. Для решения этой проблемы в Kubernetes есть функционал управления дисковым хранилищем — Persistent Volumes. Этот механизм использует внешнее хранилище для данных, может прокидывать в контейнеры постоянное хранилище, блочное или файловое. Такое решение позволяет хранить данные отдельно от воркеров, что спасает их при поломке этих самых воркеров.
    • Load Balancer. Несмотря на то, что в Kubernetes мы управляем абстрактными сущностями типа Deployment, StatefulSet и т.д., в конечном счёте контейнеры запускаются на обычных виртуальных машинах или железных серверах. Они не идеальны и могут упасть в любой момент. Kubernetes это увидит и перенаправит внутренний трафик на другие реплики. Но что делать с трафиком, который приходит извне? Если просто направить трафик на один из воркеров, что в случае его падения сервис станет недоступен. Для решения этой проблемы в Kubernetes есть сервисы типа Load Balancer. Они предназначены для автоматической настройки внешнего облачного балансировшика на все воркеры в кластере. Этот внешний балансировщик направляет внешний трафик на воркеры и сам следит за их статусом. Если один или несколько воркеров становятся недоступны, то трафик перенаправляется на другие. Это позволяет создавать высокодоступные сервисы с помощью Kubernetes.

    Лучше всего Kubernetes себя проявляет именно при запуске микросервисных архитектур. Внедрять систему в классическую архитектуру можно, но бессмысленно. Если приложение не может работать в нескольких репликах, то какая суть разница – в Kubernetes или нет?

    Open source Kubernetes


    Open source Kubernetes – отличная вещь: поставил и работает. Можно развернуть на своих железных серверах, на своей инфраструктуре, поставить мастера и воркеры, на которых будут запускаться все приложения. А главное — все это бесплатно. Однако есть нюансы.

    • Первый – требовательность к знаниям и опыту администраторов и инженеров, которые будут все это разворачивать и сопровождать. Поскольку клиент получает полную свободу действий в кластере, то ответственность за работоспособность кластера он несет сам. А сломать здесь все очень просто.
    • Второй – отсутствие интеграций. Если запускать Kubernetes, не имея какой-то популярной платформы виртуализации, то не получите всех преимуществ программы. Таких как использование Persistent Volumes и сервисов Load balancer.



    Рисунок 2. Архитектура k8s

    Kubernetes от вендора


    Интеграция с облачным провайдером дает две возможности:

    • Во-первых, человек может просто нажать на кнопку «создать кластер» и получить уже настроенный и готовый к работе кластер.
    • Во-вторых, вендор сам ставит кластер и настраивает интеграцию с облаком.

    Как это происходит у нас. Инженер, который запускает кластер, указывает, сколько ему нужно воркеров и с какими параметрами (например, 5 воркеров, каждый на 10 ЦПУ, 16 ГБ оперативной памяти и, скажем, 100 ГБ диска). После чего получает доступ в уже сформированный кластер. При этом воркеры, на которых запускается нагрузка, полностью отдаются клиенту, но весь management plane остается в зоне ответственности вендора (в случае, если сервис предоставляется по модели managed service).

    Однако такая схема имеет свои недостатки. Из-за того, что management plane остаётся у вендора, то вендор не дает полный доступ клиенту, и это снижает гибкость в работе с Kubernetes. Иногда бывает, что клиент хочет прикрутить к Kubernetes какой-то специфичный функционал, например, аутентификацию через LDAP, а конфигурация management plane этого не позволяет.



    Рисунок 3. Пример кластера Kubernetes от облачного провайдера

    Что выбрать: open source или вендорский


    Итак, open source Kubernetes или вендорский? Если брать open source Kubernetes, то пользователь что хочет, то с ним и делает. Но велик шанс самому себе выстрелить в ногу. С вендорским это сложнее, потому как за компанию все продумано и настроено. Самым большим недостатком опенсорсного Kubernetes является требование к специалистам. С вендорским компания от этой головной боли избавлена, но ей придется решать: платить своим специалистам или вендору.





    Ну что, плюсы очевидны, минусы тоже известны. Неизменно одно: Kubernetes решает массу проблем, автоматизируя управление множеством контейнеров. А какой выбрать, open source или вендорский, — каждый принимает решение сам.

    Статью подготовил Дмитрий Краснов, ведущий архитектор сервиса Containerum провайдера #CloudMTS
    МТС
    Компания

    Комментарии 19

      0
      И так в статье описали что такое kubernetes, написали что есть платформы от поставщика услуг или можно самим. Но не написали кое что еще. Хотелось бы дополнить:
      — Вне зависимости от того, какой у вас кубер (вендорский или опенсорс). Вам в любом случае надо иметь грамотного специалиста, который поможет разработчикам деплоить, мониторить, логировать и кастомизировать приложения для работы в кубере.
      — Если у предприятия нет на это средств, то данному опыту учатся разработчики в зависимости от желания\времени\или свободные от пиления новых фич (а как мы знаем, разработчиков именно для этого и нанимают, отвлекаться на изучение инфраструктуры и как работает весь комбайн нет времени).
      — Если организация все таки внедрила кубернетес и использует его. То со временем приходит понимание, что самый лучший плюс от платформы — это быстрая переносимость, следовательно «мы можем быстро задеплоить прод в любой кластер у любого поставщика услуг и как становится пофиг на своих железяках или от вендора».

      И финал, иногда оказывается не пофиг где запускается ваш кластер. И в 99% случаев клиенту надо переплачивать +20% к стоимости виртуалок, если они работают как «manage service». И с учетом специфики работы приложения выбирается то решение, которое выбирается (на своих мощностях, если нужно много процессоров и ОЗУ или от облачного поставщика, если «и так хватает»).
        0
        Не одного, а команду грамотных специалистов. Реализовать прекрасную переносимость и развертываемость всего прода завязавшись на одном человеке так себе решение.
        +1
        Если запускать Kubernetes, не имея какой-то популярной платформы виртуализации, то не получите всех преимуществ программы

        WAT?


        Мне кажется не совсем корректно поставлено противопоставление. Что такое вендорский кубернетес? Что такое опен-сурс?
        Я бы разбил на несколько другие категории
        измерение 1 — облако vs bare-metal
        измерение 2 — managed k8s vs собственное развертывание
        измерение 3 — вендорский k8s (openshift, rancher, managed в принципе сюда тоже можно засунуть) vs vanilla/open-source


        При этом не все комбинации жизненноспособны. Но вот тот Amazon и Azure как "обломок" облака уже вроде можно втащить в свой контур — первый предлагает форпост, второй AzureStack (и, да, вроде ведь в МТС предлагают такую услугу?)


        Насчет интеграций — там все сложно в первую очередь при развертывании в своем контуре на baremetal — действительно приходится городить всяческие костыли и подгонять остальную инфру. Но в целом то же PV© можно сделать. LB — если очень надо — тоже. Поэтому пассаж про виртуалки не понял. Или речь про то, что нужно строить кластер поверх какого-нибудь vmware или нутаникса? Ну, да — тоже вариант
        В недостатках опенсурсного — отсутствие автоскейлинга. Ну, е-мае… Это больше от нижележащей платформы зависит...

          +1
          Добавлю 5 копеек про новые сервисы. Вот взять «облака», которые МТС и другие российские «гиганты хостинга» (которые рассчитывают на бизнес-покупателей) спешно представили в минувшем году: все, что «облачное», продается только после оформления договора (или допника к существущему договору), с прописыванием в договоре оплачиваемых ресурсов. Еще раз: облако от Vmware, но оплата идет, по сути, как за VPS, а не как за облако (per-use оплата? Увы, не увидите — платите за квту ресурсов, которую заказали).

          Это и неплохо, может быть (потому что oversell в принципе невозможен, но облака овеселом и не славятся. А вот масштабированием на лету — да, славятся, но только какое тут масштабирование, когда ты должен допник полнедели согласовывать? Менеджеры идут навстречу, включая (как в России любят говорить, «в ручном режиме») ресурсы в квоту, и прося допник подписать как можно скорее, но это — не API, это вручную, и, хотя это и надежнее просто VPS-ок на нерезервированном хосте, по факту не так приятно, как «облако» (притом, что продается именно как облако).

          С кубером в МТС не знаю, но если речь о том, чтобы (как в посте изложено)

          Инженер, который запускает кластер, указывает, сколько ему нужно воркеров и с какими параметрами (например, 5 воркеров, каждый на 10 ЦПУ, 16 ГБ оперативной памяти и, скажем, 100 ГБ диска). После чего получает доступ в уже сформированный кластер. При этом воркеры, на которых запускается нагрузка, полностью отдаются клиенту, но весь management plane остается в зоне ответственности вендора (в случае, если сервис предоставляется по модели managed service).


          то управление, что, вручную работает?! Через тикеты и с реализацией масштабирования через часы, а то и дни? А если нет, то как можно средствами кубера же настроить масштабирование сервиса от нагрузки без того, чтобы заранее ресурсы не оплатить (и не получить, снова, схему с облакомVPS-ками?

          Справедливости ради уточню: у других игроков российского рынка ситуация, бывает, что и еще печальнее. Получается, издержки модели бизнеса, когда «облако» запускается не чтобы привлечь юзеров низкими ценами, а затем привязать удобством и числом сервисов, а для того, чтобы и у себя в портфолио иметь что-то, что называется «облако», и его продать тем, кто и там готов потратиться.

          Хочу увидеть «российский AWS», но, боюсь, по ряду понятных хабравчанам причин, не увижу.
            +1

            Хм. У меня есть договора с Yandex, Datafort, GCE. Везде per-use, хотя Datafort за это цену заломил на уровне GCE. Есть обратная схема. У того же Яндекс, можно выкупить квоту, за нормальную скидку. У Google скидка, если виртуалка работает большую часть месяца (у AWS вроде тоже?). Продажей VPS развлекаются разные околораспильные места, но зачем о них говорить.

              0

              М1 в рамках услуги M1Cloud automate — оплата per-use. Это пример. Но можно легко упереться в лимиты (т.е. это не ОМОЗОН, где можно масштабироваться на все деньги).

                +2
                Почему-то МТС говорит, что раз, скажем, диск нарезали, то уж нарезали — не умеют они незанятое пространство блочного устройства отзывать в общий пул — так что платите за всё, уважаемые.

                Более того, мне объяснили, что в оплату за проц в машине сразу зааложена оплата лицензии винды на ней. И, если я, условно говоря, нарежу, в рамках своих лимитов, две машины, одну с виндой, другую с centos, то цена за проц будет одинаковой, хотя в линуксовой машине за виндовую лицензию как бы платить незачем.

                А все потому, что а) маркетологи посчитали, что такой биллинг будет понятнее суровым энтерпрайз-покупателям и б) потому что они сами за всё заплатили по полной, и надо же эти деньги отбивать без всяких реверансов на «неиспользование».

                Грубо, построили они кластер, запустили на нем VMware (с оплатой, понятно, «за всё»), затем MS-у заплатили за право крутить винду — и вот MS не умеет (точнее, конечно, не видит для себя финансового смысла) брать за кусок, когда можно взять бабки за всё, так что продаёт винду сразу на все процы кластера (известная засада HA от MS).

                И вот тут смех-смехом, а получается, что рядовые юзеры оплачивают любые влажные финансовые фантазии правообладателей — потому что хостер на это подписался, а юзеру просто протранслировали цену.

                Так что, да, в России как-то невольно задумаешься, нужно ли такое «необлачное облако». Повторюсь, не только к МТС это относится.
                  0
                  не умеют они незанятое пространство блочного устройства отзывать в общий пул
                  а многие ли умеют? сжатие тонких дисков без выключения виртуалки или миграции на другой датастор.
                    0
                    Про многих не знаю, я про VMware в облаке. Собственно, ОС (гостевая) освобождает незанятые более блоки (trim/unmap), а уж хранилище (внешнее) разбирается, что хранить, а что — только «держать в уме».
                      0
                      Хранилище не знает чего там гостевые системы делают у себя, её дело шуршать блоками данных. А вот хост и хранилище друг друга знают не по наслышке. Но даже на текущий момент для высвобождения блоков занятых гостевой системой требуется либо миграция на другой датастор, либо прыжок со снапшота в прод. Нету такого что бы прям вот так в легкую и без выключения виртуалки вернуть место на хранилище.

                      Ну или я не знаю об этом.
                    0
                    скажем, диск нарезали, то уж нарезали — не умеют они незанятое пространство блочного устройства отзывать в общий пул — так что платите за всё, уважаемые.

                    в общем-то я не на стороне провайдеров, но это не является проблемой. Обычно же необходимость в месте только увеличивается. Если есть ресайз в большую сторону (а обычно он есть), то проблем нет. А шринкать диски — ну, такое себе. Тогда действительно можно и пересоздать ВМ с переналивкой данных. Хотя иногда и очень хочется сделать это на лету...

                      0
                      Давайте мух от котлет отделим: я был бы рад платить только за хранимые данные, а не за квоту, которая меняется допсоглашением и в течении дней. Как при этом хранилище относится к вопросу — мне не очень важно, но вот эта «резиновость» биллинга как бы является свойством зеркала.

                      Иначе — это надежная (за счет резервирования нижележащего железа), но VPS-ка.
                        0

                        так храните данные на объектном хранилище (типа HotBox, ColdBox и пр) с биллингом по объему и количеству запросов API. Причем тут блочное хранилище вообще?


                        Иначе — это надежная (за счет резервирования нижележащего железа), но VPS-ка.

                        нет, точно так же работает любое частное или публичное облако...

                      0
                      «Более того, мне объяснили, что в оплату за проц в машине сразу зааложена оплата лицензии винды на ней. И, если я, условно говоря, нарежу, в рамках своих лимитов, две машины, одну с виндой, другую с centos, то цена за проц будет одинаковой, хотя в линуксовой машине за виндовую лицензию как бы платить незачем.»
                       
                      У нас в стоимость виртуального процессора не включена оплата лицензии Windows. Она взимается отдельно только для тех виртуальных машин, для которых требуется Windows. Если вам нужно две машины, одна с Windows, а другая с Centos, то машина c Windows будет чуть дороже, чем с Centos. Всегда можно самостоятельно сделать расчеты виртуальной инфраструктуры в калькуляторе на сайте cloud.mts.ru/services/elastic, чтобы убедиться в этом.
                        0
                        Не в обиду, но инженера из МТС, который мне это рассказывал, я знаю лично, а вас — только по довольно безликому нику.

                        Хотя, конечно, это повод переспросить у него ещё раз *смайлик*.
                    0
                    «все, что «облачное», продается только после оформления договора (или допника к существущему договору), с прописыванием в договоре оплачиваемых ресурсов. Еще раз: облако от Vmware, но оплата идет, по сути, как за VPS, а не как за облако (per-use оплата? Увы, не увидите — платите за квту ресурсов, которую заказали).»
                    У нас есть возможность оплаты ресурсов по факту использования — не за квоту. В течение месяца можете свободно использовать ресурсы столько времени, сколько вам надо, можете самостоятельно за минуты создавать новые виртуальные машины – масштабирование на лету, к менеджеру в этом случае обращаться не требуется, платите только за фактическое время использования ресурсов. Оплата за квоту тоже остается, так как ряд клиентов запрашивает именно такой способ тарификации. Поэтому окончательный выбор за вами.
                    0
                    del, промах веткой
                      0
                      Второй – отсутствие интеграций. Если запускать Kubernetes, не имея какой-то популярной платформы виртуализации, то не получите всех преимуществ программы. Таких как использование Persistent Volumes

                      А причем тут платформа виртуализации и PV? Есть достаточно бесплатных сторадж решений для кубера, работающих на нодах, тот же Rook CEPH
                        0

                        Все так, но я бы с осторожностью думал про Rook Ceph, тем более — если ноды не железные, а какие-нибудь споты/preemptible где-нибудь в облаке

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

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