Будущее Kubernetes — за виртуальными машинами

Original author: Paul Czarkowski
  • Translation
Гадания на кофейной гуще

В моей работе Kubernetes уже сыграл важную роль, а в будущем она станет ещё важнее. Но 2018 год подходит к концу, так что забудем о скромности и сделаем смелый прогноз:
Будущее Kubernetes — это виртуальные машины, а не контейнеры
По китайскому гороскопу 2018 год был годом собаки, но в технике это был год Kubernetes. Многие только сейчас узнают об этой революционной технологии, а IT-отделы повсеместно пытаются разработать «стратегию Kubernetes» [1]. Некоторые организации уже перевели на Kubernetes большие рабочие нагрузки.

[1] Если вы пытаетесь разработать стратегию Kubernetes, вы уже потерпели неудачу, но это тема для другой статьи.

Другими словами, на каждом этапе «цикла шумихи Gartner» для Kubernetes много людей. Некоторые застряли во впадине разочарования или утонули в яме отчаяния.


Jeremykemp, Википедия. Creative Commons CC BY-SA 3.0

Я большой фанат контейнеров и не буду говорить, что контейнеры мертвы. Docker в 2013 году дал нам оболочку для Linux Containers: удивительный новый способ создания, упаковки, совместного использования и развёртывания приложений. Он появился в нужное время, так как мы стали серьёзно относиться к непрерывной доставке. Их модель стала идеальной для цепочки доставки и способствовала появлению платформы PaaS, а затем CaaS.



Инженеры из Google увидели, что IT-сообщество наконец-то готово к контейнерам. Google очень давно использует контейнеры и в каком-то смысле их можно считать изобретателями контейнеризации. Они начали разрабатывать Kubernetes. Как сейчас известно, это свободная реинкарнация собственной платформы Borg от Google.

Вскоре поддержку Kubernetes обеспечили все большие облака (GKE, AKS, EKS). Сервисы On-premise тоже быстро подняли платформы на основе Kubernetes (Pivotal Container Service, Openshift и др.).

Мягкая мультиарендность


Нужно было решить одну назойливую проблему, которую можно считать недостатком контейнеров… это мультиарендность (multi-tenancy).

Контейнеры Linux не создавались как безопасные изолированные среды (вроде Solaris Zones или FreeBSD Jails). Вместо этого они строились на общей модели ядра, которая использует функции ядра для обеспечения базовой изоляции процессов. Как сказала бы Джесси Фразель, «контейнеры — это не настоящая вещь».


Это усугубляется фактом, что большинство компонентов Kubernetes не осведомлены об «арендаторах» (tenant). Конечно, у вас есть пространства имён и политики безопасности Pod, но в API нет такого понятия. Также как во внутренних компонентах, таких как kubelet или kube-proxy. Это приводит к тому, что в Kubernetes реализована модель «мягкой аренды» (soft tenancy).


Архитектура Kubernetes

Абстракции просачиваются дальше. Платформа поверх контейнеров наследует многие аспекты мягкой аренды. Платформы поверх виртуальных машин с жёсткой мультиарендой наследуют эту жёсткую аренду (VMware, Amazon Web Services, OpenStack и т. д.).

Модель мягкой аренды Kubernetes ставит поставщиков услуг и дистрибутивов в странное положение. Сам кластер Kubernetes становится линией «жёсткой аренды». Даже внутри одной организации есть много причин требовать жёсткой аренды между пользователями (или приложениями). Поскольку общедоступные облака предоставляют в качестве сервиса полностью управляемые Kubernetes, клиентам достаточно легко взять свой собственный кластер и использовать границу кластера в качестве точки изоляции.

Некоторые дистрибутивы Kubernetes, такие как Pivotal Container Service (PKS), хорошо знают об этой проблеме аренды и используют аналогичную модель, предоставляя те же самые Kubernetes в качестве службы, которую можно получить из общедоступного облака, но в собственном центре обработки данных.

Это привело к появлению модели «много кластеров», вместо «одного большого общего кластера». Нередко у клиентов сервиса GKE от Google десятки кластеров Kubernetes, развёрнутых для нескольких команд. Часто каждый разработчик получает свой кластер. Такое поведение порождает шокирующее количество инстансов (Kubesprawl).

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

Обычо самый маленький кластер — это четыре машины (или виртуальные машины). Один (или три для HA) для Kubernetes Master, три для Kubernetes Workers. Куча денег тратится на системы, которые по большей части сидят без дела.

Поэтому нужно как-то двигать Kubernetes в сторону жёсткой мультиаренды. Сообщество Kubernetes прекрасно осознаёт эту необходимость. Уже образована рабочая группа по мультиаренде. Она напряжённо работает над этой проблемой, и у них есть несколько моделей и предложений, как работать с каждой моделью.

Джесси Фразель написала на эту тему пост в блоге, и это здорово, потому что она намного умнее меня, так что могу сослаться на неё и спасти себя от десяти лет напряжённой учёбы, пытаясь достичь её уровня. Если вы не читали тот пост, почитайте прямо сейчас.

Просто очень маленькие VM, оптимизированные на скорость…


Контейнеры Kata — это проект с открытым исходным кодом и сообщество, работающее над созданием стандартной реализации облегчённых виртуальных машин, которые выглядят и работают как контейнеры, но обеспечивают изоляцию рабочей нагрузки и преимущества безопасности VM.
Джесси предлагает использовать технологию контейнеров VM, такую как контейнеры Kata. Они предлагают изоляцию уровня VM, но работают как контейнеры. Это позволяет Kubernetes дать каждому «арендатору» (мы предполагаем арендатора в пространстве имён) свой набор системных служб Kubernetes, работающих во вложенных контейнерах VM (контейнер VM внутри виртуальной машины, которую предоставляет инфраструктура IaaS).


Изображение Джесси Фрейзеля: жёсткая мультиарендность в Kubernetes

Это элегантное решение мультиаренды Kubernetes. Её предложение идёт ещё дальше, чтобы Kubernetes использовал вложенные контейнеры VM для рабочих нагрузок (Pod), работающих на Kubernetes, что обеспечивает значительное увеличение использования ресурсов.

У нас осталась ещё как минимум одна оптимизация. Создадим подходящий гипервизор для базового поставщика инфраструктуры или облачного провайдера. Если VM-контейнер является абстракцией первого уровня, предоставляемой IaaS, то мы ещё больше увеличим использование ресурсов. Минимальное количество VM для запуска кластера Kubernetes сокращается до одной машины (или трёх для HA), чтобы разместить систему управления Kubernetes, доступную для «суперпользователя».

Мультиаренда, оптимизированная на ресурсы (стоимость)


Развёртывание Kubernetes с двумя пространствами имён и несколькими запущенными приложениями будет выглядеть примерно так:


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

Суперпользователь запрашивает из облака кластер Kubernetes. Поставщик облачных услуг создаёт виртуальную машину с одним контейнером (или тремя для HA), на которой работают основные API и системные службы Kubernetes. Суперпользователь может развернуть модули в системном пространстве имён или создать новые пространства для делегирования доступа другим пользователям.

Суперпользователь создаёт два пространства имен foo и bar. Kubernetes запрашивает из облака два VM-контейнера для каждого уровня управления пространством имён (Kubernetes API и System Services). Суперпользователь делегирует некоторым пользователям доступ к этим пространствам имён, каждый из них запускает некоторые рабочие нагрузки (модули), а соответствующие уровни управления запрашивают VM-контейнеры для этих рабочих нагрузок.

На всех этапах суперпользователь платит только за фактически потреблённые ресурсы. Поставщик облачных услуг контролирует эти ресурсы, и они доступны любому пользователю облака.

Я на самом деле не говорю ничего нового…


Поставщики облачных услуг уже работают в этом направлении. Можете убедиться в этом, наблюдая за событиями в сообществах (возможно, Amazon уже втихую сделал это с Fargate).

Первая наводка — Virtual Kubelet, инструмент с открытым исходным кодом, предназначенный для маскировки под kubelet. Он соединяет Kubernetes с другими API, что позволяет Kubernetes запрашивать VM-контейнеры из стандартного планировщика в облаке.

Другие наводки — большое количество новых технологий для VM-контейнеризации, как уже упомянутые контейнеры Kata, а также Firecracker от Amazon и gvisor от Google.

Вывод


Если грамотно реализовать улучшения в модели жёсткой аренды, то вы найдёте чашу святого Грааля виртуализации Kubernetes. Полная изоляция рабочих нагрузок и никаких лишних затрат.

Если не пользоваться публичным облаком, вы всё равно получаетете преимущества более высокого использования ресурсов, что окупается более низкими требованиями к аппаратному обеспечению.

Будем надеяться, что VMware и OpenStack обратят внимание и выпустят гипервизоры на основе легковесных VM-контейнеров и соответствующих реализаций Virtual Kubelet.
Support the author
Share post

Similar posts

Comments 17

    +1
    2018: год свидетелей Xiaomi
    2019: год свидетелей Kubernetes
      +6
      За столько лет существования термина мультитенатность — первый раз его в переводе увидел. Иногда лучше не переводить.
        –8
        Возможно, вы очень давно и глубоко в этой теме. В первое время такие термины действительно не переводятся, вы правы, но с годами по мере распространения язык начинает их переваривать.
          +3
          В первое время такие термины действительно не переводятся, вы правы, но с годами по мере распространения язык начинает их переваривать.

          Совершенно верно, язык начинает их переваривать. Именно так слово мультитенантность становится нормальным словом из русского языка. Первое время те, кто не использует это слово часто и не очень хорошо понимают что оно означает, пытаются использовать вместо него какое-нибудь другое слово, но потом, когда выясняется, что этих людей не понимает никто, кроме них самих — всё устаканивается. Так в русский язык пришли такие слова, как компьютер, кастомизация, интерфейс, индекс и многие другие.

          0
          Да воотще последнее время заметил тенденцию переводить все подряд термины, которые не стоит переводить. Получаются фразы типа: «клиентам достаточно легко взять свой собственный кластер и использовать границу кластера в качестве точки изоляции.» из которых ничего не понятно. ИМХО не стоит переводить большинство устоявшихся терминов, ведь кто с этим работает итак знает английский и эти термины, а кто не знает, тому оно и не надо. Сложно представить devops инженера (да и любого инженера) не умеющего читать по английски, статьи на русском его не спасут.
          +8
          Это усугубляется фактом, что большинство компонентов Kubernetes не осведомлены об «арендаторах» (tenant).


          Приведите, пожалуйста, конкретный пример, где это «стреляет в ногу»… А то не совсем понятно, в чем проблема и с чем боремся.
            0
            Насколько я смог понять из статьи, проблема в том, что если мы выделяем разным тенантам разные неймспейсы, то они не имеют доступа к мастерам и в неймспейс kube-system, и соответственно не могут потюнить параметры того же apiserver или controller-manager. Например там активировать какие-то экзотические FeatureGates и так далее. Такая проблема есть и она порой довольно ощутима, если ты заперт в своем изолированном неймспейсе и не можешь посмотреть kubectl describe nodes или почитать логи системных сервисов.

            Правда, из статьи все равно непонятно, как они собираются эту проблему решать. Если есть скажем главный Etcd, то какие у него будут взаимоотношения с Etcd внутри неймспейса? Можно ли будет из неймспейса посмотреть cluster-wide ресурсы, те же ноды или вольюмы? Из статьи это, к сожалению, непонятно.
            +2

            А чем PhotonOS от VMware не подходит под концепт?

              +4

              надуманная проблема, похоже будто производители VM хотят впихнуть свои технологии под соусом k8s

                +1
                Ну там VM постепенно вытесняют контейнеры, вот и они суетятся
                  +1

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

                    +4
                    With Intra-Kernel Isolation, the namespace would still be the security boundary. However, instead of all sharing the main Kubernetes system services, each namespace would have it’s own “nested” Kubernetes system services. Meaning the api-server, kube-proxy, etc would all be running individually in a pod in that namespace.

                    Их не устраивает, что неймспейсы в кластере шарят один контролплейн. При компрометации контролплейна весь кластер будет скомпрометирован. Чтобы не перепиливать cgroups и namespaces предлагается добавить еще один уровень изоляции — собственно вмку с katacontainers и подложить туда каждому по своему куску контролплейна.
                    Также есть момент, что из-за нерешенной проблемы «hard-tenancy», все предпочитают делать не один большой кластер, а кучу мелких, генерируя кучу контролплейнов, которые полезной нагрузки не несут и жрут зря ресурсы.
                    Поэтому (неожиданно) надо всем выдать по своему маленькому кубернетесу в вмке и не париться про «hard-tenancy», что они смело называют «будущее».
                    Я в итоге ничего не понял сам и пойду уже праздновать.
                  +9

                  Позвольте, я попробую объяснить простым языком. Точнее приведу аналогию с жильем.
                  Представьте, что сервер — это жилой дом.
                  Виртуальная машина — это квартира. Она неплохо изолирует ресурсы. Причем, изолирует в обе стороны — никто снаружи не может залезть внутрь, и никто внутри не может "вырасти" наружу. А ещё никто не видит, что там внутри — стены не прозрачные.
                  Контейнер — это койко-место с табуреткой. Ресурсы делятся по принципу "Братан, я одолжил у тебя табуретку, ко мне друзья пришли". А безопасность на уровне "отвернись, пока я переодеваюсь".
                  Так что, проблема с ресурсами в контейнерах — это борьба за табуретки и перегородки.


                  Один клиент (single tenancy) — это когда у квартиры один владелец. Он один сдает в ней койко-места. Ему не нужно ни с кем делить ресурсы и можно не париться насчет безопасности. Это не его проблема — это проблема арендаторов.
                  Мультиарендность (multitenancy) — это когда у одной квартиры два владельца. И оба они хотят сдавать там койко-места. И вот тут начинаются проблемы. Например, арендаторы одного владельца взяли табуретку арендаторов другого владельца. Или подсмотрели чьи-то сиськи в plain-text. Ругаются арендаторы, ругаются владельцы. От такая фигня, малята.


                  Теперь по существу решения.
                  Решение предлагают простое. А давайте мы в квартире, вместо койко-мест, сделаем маленькие квартирки! Койко-места, как квартики, только койко-места. Другие, уже существующие подходы, которые уже годами работают, даже не рассматриваются.
                  Технологии chroot, jail, lxc, разные юзеры и т.д.? Нет, я хочу контейнеры и виртуалки.
                  Так что проблема и решение напоминают поговорку "когда ты молоток, тебе все кажется гвоздями".

                    +1
                    Технологии chroot, jail, lxc, разные юзеры и т.д.? Нет, я хочу контейнеры и виртуалки

                    Справедливости ради,


                    chroot

                    это изоляция только фс. никак не защищает от того что процесс отъест например больше памяти чем положено


                    jail

                    это freebsd


                    lxc

                    основан на том же механизме что и контейнеры — cgroups. О недостатках изоляции контейнеров выше по ссылке было


                    разные юзеры

                    требуют общее пространство имен. В отличие от контейнеров где можно запустить рядом 10 постгресов из одного образа и они будут более-менее независимы в разными пользователями надо для каждого заводить уникальный UID и как-то их еще менеджить: для бекапов, например, или общей сетевой ФС на нескольких машинах.

                      0

                      Справедливо

                      0
                      Или подсмотрели чьи-то сиськи в plain-text.

                      Спасибо за плейн-текст сиськи, вы сделали мне день!
                      0
                      И ни единого упоминания kubevirt/CNV. А ведь очень зря

                      Only users with full accounts can post comments. Log in, please.