Comments 17
2019: год свидетелей Kubernetes
В первое время такие термины действительно не переводятся, вы правы, но с годами по мере распространения язык начинает их переваривать.
Совершенно верно, язык начинает их переваривать. Именно так слово мультитенантность становится нормальным словом из русского языка. Первое время те, кто не использует это слово часто и не очень хорошо понимают что оно означает, пытаются использовать вместо него какое-нибудь другое слово, но потом, когда выясняется, что этих людей не понимает никто, кроме них самих — всё устаканивается. Так в русский язык пришли такие слова, как компьютер, кастомизация, интерфейс, индекс и многие другие.
Это усугубляется фактом, что большинство компонентов Kubernetes не осведомлены об «арендаторах» (tenant).
Приведите, пожалуйста, конкретный пример, где это «стреляет в ногу»… А то не совсем понятно, в чем проблема и с чем боремся.
Правда, из статьи все равно непонятно, как они собираются эту проблему решать. Если есть скажем главный Etcd, то какие у него будут взаимоотношения с Etcd внутри неймспейса? Можно ли будет из неймспейса посмотреть cluster-wide ресурсы, те же ноды или вольюмы? Из статьи это, к сожалению, непонятно.
А чем PhotonOS от VMware не подходит под концепт?
надуманная проблема, похоже будто производители VM хотят впихнуть свои технологии под соусом k8s
Тоже не понял, чем вдруг контейнеры не угодили. Из статьи неясно, в чем конкретно проблема.
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», что они смело называют «будущее».
Я в итоге ничего не понял сам и пойду уже праздновать.
Позвольте, я попробую объяснить простым языком. Точнее приведу аналогию с жильем.
Представьте, что сервер — это жилой дом.
Виртуальная машина — это квартира. Она неплохо изолирует ресурсы. Причем, изолирует в обе стороны — никто снаружи не может залезть внутрь, и никто внутри не может "вырасти" наружу. А ещё никто не видит, что там внутри — стены не прозрачные.
Контейнер — это койко-место с табуреткой. Ресурсы делятся по принципу "Братан, я одолжил у тебя табуретку, ко мне друзья пришли". А безопасность на уровне "отвернись, пока я переодеваюсь".
Так что, проблема с ресурсами в контейнерах — это борьба за табуретки и перегородки.
Один клиент (single tenancy) — это когда у квартиры один владелец. Он один сдает в ней койко-места. Ему не нужно ни с кем делить ресурсы и можно не париться насчет безопасности. Это не его проблема — это проблема арендаторов.
Мультиарендность (multitenancy) — это когда у одной квартиры два владельца. И оба они хотят сдавать там койко-места. И вот тут начинаются проблемы. Например, арендаторы одного владельца взяли табуретку арендаторов другого владельца. Или подсмотрели чьи-то сиськи в plain-text. Ругаются арендаторы, ругаются владельцы. От такая фигня, малята.
Теперь по существу решения.
Решение предлагают простое. А давайте мы в квартире, вместо койко-мест, сделаем маленькие квартирки! Койко-места, как квартики, только койко-места. Другие, уже существующие подходы, которые уже годами работают, даже не рассматриваются.
Технологии chroot, jail, lxc, разные юзеры и т.д.? Нет, я хочу контейнеры и виртуалки.
Так что проблема и решение напоминают поговорку "когда ты молоток, тебе все кажется гвоздями".
Технологии chroot, jail, lxc, разные юзеры и т.д.? Нет, я хочу контейнеры и виртуалки
Справедливости ради,
chroot
это изоляция только фс. никак не защищает от того что процесс отъест например больше памяти чем положено
jail
это freebsd
lxc
основан на том же механизме что и контейнеры — cgroups. О недостатках изоляции контейнеров выше по ссылке было
разные юзеры
требуют общее пространство имен. В отличие от контейнеров где можно запустить рядом 10 постгресов из одного образа и они будут более-менее независимы в разными пользователями надо для каждого заводить уникальный UID и как-то их еще менеджить: для бекапов, например, или общей сетевой ФС на нескольких машинах.
Или подсмотрели чьи-то сиськи в plain-text.
Спасибо за плейн-текст сиськи, вы сделали мне день!
Будущее Kubernetes — за виртуальными машинами