Главная » Хабрахабр » [Перевод] Будущее Kubernetes — за виртуальными машинами

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

Гадания на кофейной гуще
В моей работе Kubernetes уже сыграл важную роль, а в будущем она станет ещё важнее. Но 2018 год подходит к концу, так что забудем о скромности и сделаем смелый прогноз:

Будущее Kubernetes — это виртуальные машины, а не контейнеры

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

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

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

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

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

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

Нужно было решить одну назойливую проблему, которую можно считать недостатком контейнеров… это мультиарендность (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 в сторону жёсткой мультиаренды. Она напряжённо работает над этой проблемой, и у них есть несколько моделей и предложений, как работать с каждой моделью. Уже образована рабочая группа по мультиаренде.

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

Контейнеры Kata — это проект с открытым исходным кодом и сообщество, работающее над созданием стандартной реализации облегчённых виртуальных машин, которые выглядят и работают как контейнеры, но обеспечивают изоляцию рабочей нагрузки и преимущества безопасности VM.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

«Под капотом» СХД Huawei: фирменные технологии, и чего нет у других

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

Slack планирует выйти на биржу в обход традиционного механизма IPO

При этом, компания склоняется к варианту, при котором не будет задействован традиционный механизм IPO. Согласно данным The Wall Street Journal, руководство Slack планирует выйти на биржу. Акции будут размещены напрямую, а оценка компании составит около $7 млрд. О том, почему ...