kubernetes-хостинг

На фоне в любом случае разворачиваются машины. Многие провайдеры юзеру к ним доступа все равно не дают (если заявлено как managed), так что какая разница?

Должно быть дешевле. Зачем для сайта-визитки целый кластер?

Посмотри в сторону serverless

Зачем для сайта-визитки целый кластер?

Зачем для визитки вообще k8s?

…. А так, чтобы кластер был один на всех, а пользователю предоставлялся только namespace, и он мог разворачивать свои поды в рамках лимитов.

K8S-namespace не обеспечивает полной изоляции Pod-ов, поэтому сомнительно, чтобы кто-то предоставлял такие услуги - просто это никому не нужно. И как вы собираетесь обходиться без выделенного под свое приложение IP? Т.е. кто-то еще должен для вас и веб-сервер крутить один на всех? Облачные платформы просто предоставляют другие, более простые решения для использования контейнеров.

чтобы «вебмастеру» можно было знать только докер-кубер вместо асппхпвродпрездрупалджангонгинксжумлафласкнодежуесспринг

чтобы «вебмастеру» можно было знать только докер-кубер

Ты говоришь «только» как будто это так просто. «Вебмастеру» эффективнее дать ftp/ssh. Там ничего знать не надо.

«Вебмастеру» эффективнее дать ftp/ssh.

И двадцать русских рублей.

Виртуалка — слишком жирно, shared-хостинг — прошлый век, он не гендерноязыково-нейтральный. Какой-нибудь go вообще в бинарник компилируется.

И как вы собираетесь обходиться без выделенного под свое приложение IP? Т.е. кто-то еще должен для вас и веб-сервер крутить один на всех?

ingress, не?

существуют. это так называемый serverless hosting.

ingress, не?

А что вы под этим словом подразумеваете? Ingress - это по сути и есть выделенный IP-шник, входящий трафик с которого раскидывается по Pod-ам - например, по нескольким контейнерам с Nginx. Можно еще использовать более дорогое и менее гибкое «удовольствие» HTTPS-балансировщик, но это тоже не веб-сервер в чистом виде, а именно балансировщик, просто раскидывающий по Pod-aм не TCP-соединения, а HTTP-запросы. Все это не шибко рассчитано на shared-использование. Несколько доменов конечно можно поддерживать - но либо доменов одного хозяина, либо Pod-ы должны быть узко специализированными, чтобы пользователи гарантированно не мешали друг-другу работать.

K8S-namespace не обеспечивает полной изоляции Pod-ов

Если сверху Istio прикрутить, то обеспечивает (разве только интенсивный дисковый ввод-вывод остаётся).

Ingress - это по сути и есть выделенный IP-шник,

o.O ingress (или istio virtualservice) это полный аналог virtual host’ов Апача. На одном IP можно разместить сколько угодно web-сайтов.

Зачем для сайта-визитки целый кластер?

Кластер для нее вообще не нужен. Хватит самой дешевой ВДС, если там не PHP с базой. И по стоимости выйдет рублей 150 в месяц.

А если PHP с базой, то хватит обычного хостинга.

Если сверху Istio прикрутить, то обеспечивает …

И одновременно делает поды специализированными - а TC хочет сам быть полным хозяином namespacе-а и «творить» там все что угодно )

И одновременно делает поды специализированными

что вы имеете в виду?

Идея благодатная, но кубернетесу не хватате важной фичи: вложенных пространств имён для этого, чтобы я получил namespace/tenant1 и мог в нём создавать ns/tenant1/prod, ns/tenant1/dev, ns/tenant1/common etc.

o.O ingress (или istio virtualservice) это полный аналог virtual host’ов Апача. На одном IP можно разместить сколько угодно web-сайтов.

Да это можно сделать и без istio - у меня в одном кластере крутится несколько доменов с независимымми приложениями. Но… администрирую и конфигурирую все это хозяйство я сам - посторонние люди туда не лезут.

Это означает наложение ограничений на допустимую конфигурацию подов. Что-то сомнительно, что это решение можно практично использовать именно для shared-хостинга

Нужно ещё политики прописать, чтобы pods из ns/tenant1 не имели доступка к pods из ns/tenant2. Можно, конечно, наколхозить и так, но в чём смысл писать свою service mesh, когда уже есть готовая, отлаженная и документированная?

Это означает наложение ограничений на допустимую конфигурацию подов

Честно говоря, не помню, что именно istio запрещает. Я, впрочем, кроме mtls и virtualservice istio и не использую, так что могу многого и не знать.

Честно говоря, не помню, что именно istio запрещает

Так проблема не в том, что он что-то запрещает или разрешает - проблема в том, что никто из посторонних хозяев конкретного кластера не пустит вас в свой кластер предоставив вам в полное распоряжение конкретный namespace - даже если вы побожитесь, что будете использовать исключительно istio и будете вести себя хорошо)

Это, извините, лирика. Если вы не используете istio, то это ваш ns открыт всем ветрам. Ваше право, ваша ответственность, ваши проблемы. Остальным это никак не вредит.

Это, извините, лирика … Остальным это никак не вредит.

Да нет - не лирика. И остальным ваше разгильдяйство может сильно навредить. Здесь вообще все всем могут очень сильно навредить - поэтому идея предоставления namespace в полное распоряжение кому попало изначально дохлая.

И остальным ваше разгильдяйство может сильно навредить

Например, как?

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

Виртуалка — слишком жирно

А docker не жирно? Та же виртуалка, вид сбоку.

Та же виртуалка, вид сбоку.

Но ведь нет.

Всё же хотелось бы конкретики, тема-то интересная. А что ты умрёшь, и твоя семья умрёт, и все в твоём доме умрут, то можно долго болтать.

Всё же хотелось бы конкретики …

Ну представьте себе начинающего разработчика, который разместил на таком «шаринге» простое трехконтейнерное приложение Nginx + PHP-FPM + СУБД наивно считая, что вся из себя правильная конфигурация Nginx защитит его от всякого взлома. А тут - о чудо! - сбоку из соседнего namespacе к нему вламываются прямо по FastCgi или начинают пароли к базе данных подбирать ))

1. И в чём разница с виртуальной машиной/отдельным k8s кластером?

2. Для изоляции от отдельного ns есть service mesh. Для отключения которого нужно ещё узнать что это такое, зачем нужно и как, собственно, выключается. Если уж после этого оный разработчик сознательно отключил защиту, то, что ж. Это его решение. Главное, что он не сможет таким образом подставить других пользователей того же класетра.

https://www.unison.cloud кажется чем то похожим, но не кубернетес. Скорее всего никто не смог решить проблему РЕШЕТО в таком масштабе, чтобы туда можно было пускать рандома из интернета.

для изоляции от отдельного ns есть NetworkPolicy, которая работает на уровне сетевого плагина k8s и не инжектит свой бинарь в чужие контейнеры как istio

не инжектит свой бинарь в чужие контейнеры

Это не баг, это фича. Таким образом мы разделяем слои функциональности. Прикладной код знает как зарегистрировать пользователя, как добавить предмет в корзину заказа, как сделать выгрузку из базы данных, а service mesh знает как работает сеть и как с ней бороться.

для простого разделения доступа хватит и более простых инструментов :)

Действительно, я что-то увлёкся и меня в enterprise занесло.

Amazon Fargate немного похож

Для визитки хватит webflow в облаке. Да блин, для визитки хватит статики, которая лежит на s3 и к которой протянуты пути через cloudflare с кешем везде и всюду

Я не совсем понял, вам как клиенту такое хочется или наоборот, хотите предоставлять такую услугу, подняв свой Кубер? Если первый вариант, то как пример - Serverless Containers от Яндекса. Если же предоставлять услугу, то это требует серьёзного допиливания кубера и каждый облачный провайдер реализует это по-своему.