Virtualization
Cloud services
Comments 16
+6
За столько лет существования термина мультитенатность — первый раз его в переводе увидел. Иногда лучше не переводить.
-8
Возможно, вы очень давно и глубоко в этой теме. В первое время такие термины действительно не переводятся, вы правы, но с годами по мере распространения язык начинает их переваривать.
+3
В первое время такие термины действительно не переводятся, вы правы, но с годами по мере распространения язык начинает их переваривать.

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

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


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

Правда, из статьи все равно непонятно, как они собираются эту проблему решать. Если есть скажем главный Etcd, то какие у него будут взаимоотношения с Etcd внутри неймспейса? Можно ли будет из неймспейса посмотреть cluster-wide ресурсы, те же ноды или вольюмы? Из статьи это, к сожалению, непонятно.
+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
Или подсмотрели чьи-то сиськи в plain-text.

Спасибо за плейн-текст сиськи, вы сделали мне день!
Only logged in users are able to leave comments. , please.