Помогите найти ответ альфы Спуфингу про админство и системд

а доступ к другим mounts (ну скажем /mnt/my_secrets), полный что ли останется?

Проверил. Да.

ProtectSystem=full

Это не защищает другой mount point. Все mount-ы копируются в новый нэймспэйс, и если у пользователя есть туда доступ (chmod), то и всё, всё есть, даже на запись..

К слову о важности чтения этих системд-простыней, которые никто не читает. И потом путаются. Ты ведь думал что «со всем требуемым сендбоксингом»? :)

В каком-то смысле это должно бы быть дефолтом для многих сервисов.

Да ерунда такой дефолт, см. выше мой пост про другие mount points. Дефолтом должно быть ничего, и разработчик пишет что ему нужно для работы его программы.

А у нас есть какие-то третьи альтернативы годные по состоянию на 2026?

Контейнеры и их оркестраторы со своими декларативными настройками ресурсов?

со всем требуемым сендбоксингом

Ок, если есть быстрый ответ, то подскажи пожалуйста (немного в продолжение этой подтемки).

Есть ли простой способ ограничить доступ сервисов к некоторым mount points? Знаю про InaccessiblePaths из systemd.exec, это то что надо. Но его не применить system-wide в systemd-system.conf, чтобы стало для всех сервисов.

Моё решение – написать «башговно» (издеваюсь над тобой; конечно баш это супер-клей) которое будет проходить по всем service юнитам и добавлять/менять в них эти строки. А как сделать по уму, по-системд-эшному?

Контейнеры и их оркестраторы со своими декларативными настройками ресурсов?

Ты udev и crond в Docker Swarm предлагаешь запускать? К сожалению, в тесно интегрированных системах контейнера создают больше проблем, чем решают.

Ты udev и crond

Простые сервисы в Alpine Linux на хосте.

в Docker Swarm предлагаешь запускать?

А что, systemd уже стал распределённым?

Почему не просто Docker или Podman?

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

Каких проблем?

в Docker Swarm предлагаешь запускать?

А что, systemd уже стал распределённым?
Почему не просто Docker или Podman?

Podman создаёт сервисы systemd — по итогу ты используешь systemd или systemd.

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

Каких проблем?

Докер изначально был создан не для управления ресурсами и доступами — ресурсами и доступами управавляли прекрасно без докеров десять лет до этого, cgroups тоже не Docker Inc. создал.

Основная фишка докера заключалась в том, что он создавал виртуальную систему, независимую от хоста, что позволяло делать всякие безобразия, вроде биндинга на 80 порт, установки любого софта в /usr и любых конфигов в /etc. Тут как бы больше вопрос «а какого чёрта софту под линуксом нужно обязательно нужно устанавливаться так, будто он единственная программа в системе» — и это как бы вопрос к олдам, почему они запустили инфру до такого состояния и ничего с этим не делали. Больнее всего это было для всяких там Python, PHP, Perl.

Если же тебе нужно просто запустить какой-то более-менее адекватный независимый сервис или, наоборот, уже тесно интегрированный в систему, то с докером ты сначала потеряешь всю интеграцию с системой, а потом тебе нужно будет долго и мучительно её обратно выстраивать — ради чего? Просто чтобы был докер?

Podman создаёт сервисы systemd — по итогу ты используешь systemd или systemd.

Это обязательное его поведение?

Докер изначально был создан не для управления ресурсами и доступами

На что это влияет в контексте нашей дискуссии? Разве это аргумент против контейнеров?

ресурсами и доступами управавляли прекрасно без докеров десять лет до этого,

и без systemd?

cgroups тоже не Docker Inc. создал.

и не Лёня?

Основная фишка докера заключалась в том, что он создавал виртуальную систему, независимую от хоста

И что в этом плохого? :)

Если же тебе нужно просто запустить какой-то более-менее адекватный независимый сервис

Независимый от чего?

или, наоборот, уже тесно интегрированный в систему, то с докером ты сначала потеряешь всю интеграцию с системой, а потом тебе нужно будет долго и мучительно её обратно выстраивать — ради чего?

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

Podman создаёт сервисы systemd — по итогу ты используешь systemd или systemd.

Это обязательное его поведение?

Кратко, суть в том, что докер-подман — это не инструмент оркестрации сервисов на локальной машине. Когда подману нужно оркестрировать, он берёт тот же системд.

На что это влияет в контексте нашей дискуссии? Разве это аргумент против контейнеров?

Докер — это инструмент для узкой задачи. Ну вот когда я llama.cpp собирал на старой убунте — я брал официальный образ от nvidia, потому что они каждые два года ломающие изменения вносят. Если мне нужно запустить сервис под свою текущую платформу — зачем мне докер?

ресурсами и доступами управавляли прекрасно без докеров десять лет до этого,

и без systemd?

cgroups тоже не Docker Inc. создал.

и не Лёня?

Ресурсами управляли на башескриптах. Считай, что системд ­— это докеровы декларативные сервисы, только без докеровых неймспейсов. В системд каждый сервис в своей cgroup и эти группы используются по прямому назначению — для контроля ресурсов, а не для изоляции рута дебильному софту на питоне.

Основная фишка докера заключалась в том, что он создавал виртуальную систему, независимую от хоста

И что в этом плохого?

В том, что мягко говоря не всем сервисам нужно существовать в вакууме. Веб-серверу нужно связываться с сервисами логики, сервисам логики нужно связываться с БД.

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

Ну с этого можно было начинать. Кубернет тебе тоже не нравится, я правильно понимаю?

Кратко, суть в том, что докер-подман — это не инструмент оркестрации сервисов на локальной машине. Когда подману нужно оркестрировать, он берёт тот же системд.

docker/podman compose тоже не инструмент оркестрации?

Если мне нужно запустить сервис под свою текущую платформу — зачем мне докер?

Независимость иммутабельного сервиса от изменений в системе, меньше вероятность изломать сервис или систему конфликтами версий либ и т.п.

Считай, что системд ­— это докеровы декларативные сервисы, только без докеровых неймспейсов.

Хорошо, есть сходство?

В системд каждый сервис в своей cgroup и эти группы используются по прямому назначению — для контроля ресурсов, а не для изоляции рута дебильному софту на питоне.

В докере контроль ресурсов не хуже? А где гарантия, что твой сервис окажется «недебильным» (c)? Мало тебе CVE?

В том, что мягко говоря не всем сервисам нужно существовать в вакууме. Веб-серверу нужно связываться с сервисами логики, сервисам логики нужно связываться с БД.

А в docker-compose и даже в обычном докере сеть отсутствует?

Кубернет тебе тоже не нравится, я правильно понимаю?

По твоему Kubernetes тесно интегрирует сервисы? Что там про это написано в 12 заповедях?

Независимость иммутабельного сервиса от изменений в системе, меньше вероятность изломать сервис или систему конфликтами версий либ и т.п.

Это в обе стороны можно крутить — как насчёт «держать на сервере софт с уязвимостями, исправленными два года назад»?

Считай, что системд ­— это докеровы декларативные сервисы, только без докеровых неймспейсов.

Хорошо, есть сходство?

Ты к чему? Я это писал к тому, что и у systemd, и у докера, и у того же docker compose декларативные файлы.

В докере контроль ресурсов не хуже? А где гарантия, что твой сервис окажется «недебильным» (c)?

Если сервис окажется дебильным, то запускаешь его в контейнере через системд. У меня вот оллама крутится в snap контейнере:

  ├─snap.ollama.listener.service 
  │ ├─170688 /bin/bash /snap/ollama/101/bin/snap_launcher.sh serve
  │ └─170750 /snap/ollama/101/bin/ollama serve

А в docker-compose и даже в обычном докере сеть отсутствует?

Зачем «удобно настраивать» докер, если можно вообще его не иметь и ничего не настраивать? Чисто теоретически можно в контейнер прокинуть корень ФС и все неймспейсы с хоста, но зачем тогда докер?

По твоему Kubernetes тесно интегрирует сервисы? Что там про это написано в 12 заповедях?

Что-то там про «чем больше страдает девопс — тем больше ему воздастся на небесах». Я убежал из конторы, которая начала вводить кубернет. Там как бы дело не про интеграцию сервисов на уровне одного хоста, а про создание сплошного комка сервисов на уровне кластера.

Это в обе стороны можно крутить — как насчёт «держать на сервере софт с уязвимостями, исправленными два года назад»?

Ведь если постоянно апдейтить дистрибутив, то это получается latest из стабильной ветки? Что мешает аналогично указать тег latest при наличии стабильного канала образов контейнеров или просто major версию при поддержке semver?

   Считай, что системд ­— это докеровы декларативные сервисы, только без докеровых неймспейсов.

Если бы только это, там ещё 100500 разного ненужноД, и может сломаться в любой момент.

Ты к чему? Я это писал к тому, что и у systemd, и у докера, и у того же docker compose декларативные файлы.

К тому, что docker-compose прекрасно оркестрирует сервисы на одноноде.

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

Зачем контейнер портить снаружи системдой?

крутится в snap контейнере:

А он этот снэп сам не того самого в твоей терминологии?

Зачем «удобно настраивать» докер, если можно вообще его не иметь и ничего не настраивать?

Чтобы была изоляция и иммутабельность окружения процесса сервиса очевидно.

Что-то там про «чем больше страдает девопс — тем больше ему воздастся на небесах».

А девопсы страдают?

Я убежал из конторы, которая начала вводить кубернет.

Сбежал от прогресса?

Там как бы дело не про интеграцию сервисов на уровне одного хоста, а про создание сплошного комка сервисов на уровне кластера.

Это же твоё любимое, когда много инстансов с консенсусом? А как их деплоить без Кубера? Ансиблой?

Ведь если постоянно апдейтить дистрибутив, то это получается latest из стабильной ветки? Что мешает аналогично указать тег latest при наличии стабильного канала образов контейнеров или просто major версию при поддержке semver?

Я напоминаю, что для этого кому-то нужно собирать образы со стабильной веткой базового дистрибутива. Далеко не каждый апстрим так делает. Особенно пет проекты-переростки на гитхабах любят собираться с последним мусором, который они успеши натаскать в репу. Дистрибутивы аля Debian или RHEL служат как раз для того, чтобы подобрать стабильные конфигурации и поддерживать их после того, как апстрим забил болт на эту поддержку.

Для сборки софта из сорцов на хостовом стабильном дистре докер является просто лишним звеном. Он нужен как раз для моего случая с llama.cpp — когда нужно собраться не для той системы, которая хост.

Если бы только это, там ещё 100500 разного ненужноД, и может сломаться в любой момент.

Офигенная история, а на докере логирование-мониторинг резко не нужны становятся? Я просто из-за одного того факта, что в докере нет своего удобного логирования, готов отказаться от докера.

К тому, что docker-compose прекрасно оркестрирует сервисы на одноноде.

Ну, кому-то и баш оркестрирует сервисы на одноноде. Правда, я не уверен, что docker-compose даст что-то большее при условии, что нам не нужна глубокая изоляция докера.

Вот на моей последней работе был деплой через docker+docker-compose, и при этом система была приколочена гвоздями к железу — я честно не понимаю такого прикола.

А он этот снэп сам не того самого в твоей терминологии?

Да, и подман тоже. Я об этом и писал. Systemd и Docker совершенно разные функции выполняют, потому говорить «я использую докер вместо systemd» просто неграмотно. Я же писал про то, что зачем использовать докер, когда всё то же самое можно сделать без докера? Элементарная бритва Оккама.

Чтобы была изоляция и иммутабельность окружения процесса сервиса очевидно.

Чтобы была изоляция и иммутабельность нужно Firecracker, если уже на то пошло. А докер — это ни рыба, ни мясо. Я ещё раз повторюсь, что докер прежде всего нужен деплойщикам всякого мусора на питоне и PHP — для людей со статично линкованными бинарями вся иммутабельность окружения заключается в том, что байты бинаря не поменялись.

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

docker run --rm -v $(pwd):/app -v /home/user/.cache/llama.cpp/:/root/.cache/llama.cpp/ \
        --cap-add=SYS_PTRACE --security-opt seccomp=unconfined \
        --device /dev/nvidia0:/dev/nvidia0 --device /dev/nvidiactl:/dev/nvidiactl \
        --device /dev/nvidia-uvm:/dev/nvidia-uvm  -it localhost/llama-builder

Что-то там про «чем больше страдает девопс — тем больше ему воздастся на небесах».

А девопсы страдают?

Как грил один мой коллега «любой каприз за ваши деньги. Весь WhatsApp разрабатывался и обслуживался командой из 11 человек, от начала и до конца — как ты думаешь, какую версию кубернетеса они использовали?

Там как бы дело не про интеграцию сервисов на уровне одного хоста, а про создание сплошного комка сервисов на уровне кластера.

Это же твоё любимое, когда много инстансов с консенсусом? А как их деплоить без Кубера? Ансиблой?

Я ХЗ, в какой момент ты решил, что это моё любимое. Я щитаю себя экспертом по распределёнке, но именно по этой причине я щитаю, что консенсусы должны быть исключительной мерой, а не „первое, за что хватаюсь“.

Скажем так: когда компания дорастает до масштаба гугла, то она проходит много этапов перед тем, как у неё возникает вопрос „у нас больше десятка хостов и мы уже не можем руками запускать-тушить сервера — как нам масштабироваться?“. Кластер кафок кубернетесом не соркестрируешь так-то — хотя есть и такие извращенцы, м-м-м, вкусные операторы, а особенно миграция CRD, отвал хуков, и вставший колом кластер — господи, как же я мечтаю поработать с такой системой.

Я напоминаю, что для этого кому-то нужно собирать образы со стабильной веткой базового дистрибутива. Дистрибутивы аля Debian или RHEL служат как раз для того, чтобы подобрать стабильные конфигурации и поддерживать их после того, как апстрим забил болт на эту поддержку.

Для популярного софта нет постоянно обновляемых готовых образов из тех же самых дистрибутивов?

LinuxServer.io

Docker Hardened Images (с 2025–2026) — ещё лучше для тех, кто параноит: distroless-подход, near-zero CVE, non-root по умолчанию, SBOM. Каталог огромный, и они бесплатны/OSS.

https://hub.docker.com/hardened-images/catalog

При привязке к правильным semver-тегам получаешь предсказуемые security-обновления, очень близкие к политике Debian stable.

Для сборки софта из сорцов на хостовом стабильном дистре докер является просто лишним звеном.

Открою страшную тайну. Большинство современных CI (GitLab, Woodpecker, и даже Jenkins K8s operator) систем построено на контейнерах.

Офигенная история, а на докере логирование-мониторинг резко не нужны становятся? Я просто из-за одного того факта, что в докере нет своего удобного логирования, готов отказаться от докера.

https://docs.docker.com/engine/logging/configure

local	Logs are stored in a custom format designed for minimal overhead.
json-file	The logs are formatted as JSON. The default logging driver for Docker.
syslog	Writes logging messages to the syslog facility. The syslog daemon must be running on the host machine.
journald	Writes log messages to journald. The journald daemon must be running on the host machine.
gelf	Writes log messages to a Graylog Extended Log Format (GELF) endpoint such as Graylog or Logstash.
fluentd	Writes log messages to fluentd (forward input). The fluentd daemon must be running on the host machine.
awslogs	Writes log messages to Amazon CloudWatch Logs.
splunk	Writes log messages to splunk using the HTTP Event Collector.
etwlogs	Writes log messages as Event Tracing for Windows (ETW) events. Only available on Windows platforms.
gcplogs	Writes log messages to Google Cloud Platform (GCP) Logging.

Через vector.dev оно интегрируется с любым ингестом логов

Ну, кому-то и баш оркестрирует сервисы на одноноде. Правда, я не уверен, что docker-compose даст что-то большее при условии, что нам не нужна глубокая изоляция докера.

Портируемость и иммутабельность — образ гарантированно запустится одинаково везде (с теми же зависимостями). Никогда не сталкивался с невозможностью установить или обновить пакет даже из Debian stable, потому что он ломал те или иные зависимости?

Вот на моей последней работе был деплой через docker+docker-compose, и при этом система была приколочена гвоздями к железу — я честно не понимаю такого прикола.

Это особенность и вина докера? Надеюсь, ты заметил, что большинство моих вопросов риторические?

Systemd и Docker совершенно разные функции выполняют, потому говорить «я использую докер вместо systemd» просто неграмотно.

Заметь, я упоминал Alpine Linux, т.е. OpenRC + Docker вместо systemd.

Чтобы была изоляция и иммутабельность нужно Firecracker, если уже на то пошло.

А ещё лучше по отдельной железке с OpenBSD под каждый несистемный сервис?

А докер — это ни рыба, ни мясо.

Докер покрывает потребности большинства пользователей одноноды.

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

Это лишь показывает то, что при желании точечно можно интегрировать и докер, но при этом остальные несистемные сервисы изолировать по умолчанию?

Как грил один мой коллега «любой каприз за ваши деньги. Весь WhatsApp разрабатывался и обслуживался командой из 11 человек, от начала и до конца — как ты думаешь, какую версию кубернетеса они использовали?

Как ты думаешь, сколько на рынке таких специалистов, и сколько они стоят? Сколько компаний пишут на Erlang/Elixir? Меньше 1% ? Кто потом будет поддерживать их велосипед? Традиционный вопрос, почему не на асме или в машкодах.

Я ХЗ, в какой момент ты решил, что это моё любимое.

Много твоих постов, где ты с удовольствием рассказывал про консенсусы в самых разных проявлениях?

Я щитаю себя экспертом по распределёнке

Спешите видеть, эксперт по распределёнке предлагает непрофильным компаниям (которых большая часть), деплоить распределёнку на велосипедных самодельных аналогах Кубера.

Скажем так: когда компания дорастает до масштаба гугла, то она проходит много этапов перед тем, как у неё возникает вопрос „у нас больше десятка хостов и мы уже не можем руками запускать-тушить сервера — как нам масштабироваться?“.

Managed K8s, нет не слышали, ведь мы же иксперд по распределёнке! :)

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

Дооо, Strimzi Kafka и Redpanda смеётся над твоими «гениальными» мыслями.

Docker Hardened Images (с 2025–2026) — ещё лучше для тех, кто параноит: distroless-подход, near-zero CVE, non-root по умолчанию, SBOM. Каталог огромный, и они бесплатны/OSS.

Сорян, я не настолько продвинутый, чтобы в реальном времени узнавать про репу, которая была сделана публичной в декабре 2025. Может быть там и есть что-то годное... Наконец.

Открою страшную тайну. Большинство современных CI (GitLab, Woodpecker, и даже Jenkins K8s operator) систем построено на контейнерах.

Ноуп, родные раннеры на GitLab и GitHub прежде всего сделаны на microVM, и потом уже внутри них можно запустить контейнера при желании.

Например:
https://github.com/bcit-ci/CodeIgniter/blob/develop/.github/workflows/test-ph...
Они тестятся прямо на хосте, но postgresql/mysql сервера запускают как контейнера.

Или вот сам postgresql:
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
https://github.com/postgres/postgres/tree/master/src/tools/ci
Опять же VM- и metal-based по большей части, никаких контейнеров.

Так или иначе, все серьёзные хостеры крутят контейнера внутри microVM, никто на хосте контейнера не выдаёт.

https://docs.docker.com/engine/logging/configure
journald Writes log messages to journald. The journald daemon must be running on the host machine.
Через vector.dev оно интегрируется с любым ингестом логов

А кто будет journald реализовывать? Тебе обязательно нужен логер к докеру — а в systemd уже есть systemd-journald. В том и прикол: systemd — это законченная система локальной оркестрации. А докер — это просто один молоток.

Портируемость и иммутабельность — образ гарантированно запустится одинаково везде (с теми же зависимостями).

Это актуально для бессмысленной перекладывалки JSON-а в XML, но если у тебя что-то более интегрированное, то внезапно выясняется, что в контейнере нет нужного SIMD-а или на хосте старый io_uring.

Я напоминаю, что контейнера — это linux-only решение, потому какая нафик портируемость? Ты изначально писал про изоляцию и иммутабельность — это валидный набор требований для контейнеров. А вот портируемость — нет, контейнера не портируемы. Даже на ARM той же версии линя ты x86 контейнера не запустишь.

Заметь, я упоминал Alpine Linux, т.е. OpenRC + Docker вместо systemd.

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

А ещё лучше по отдельной железке с OpenBSD под каждый несистемный сервис?

Я не доволен состоянием управления ресурсами и привелегиями в Linux, но решить эту проблему нереально, потому что слишком много наследия, с которым нужно быть совместимым. Докер — это костыль, который пытается решить часть этих проблем, и далеко не самым оптимальным способом. В разных ситуациях приходится собирать свою комбинацию решений, серебрянной пули не существует под линь.

Самый элементарный пример — в линуксе отсутствуют инструменты точного контроля потребления RAM, и при этом чрезмерное использование памяти может привести к выносу кэшей с катастрофическим влиянием на производительность. К слову, мне на LOR-е подсказали классный сервис, Early OOM, больше у меня подобных проблем нет. Другое дело, что в проде идея «убить случайный сервис БД, потому что мы не подрасчитали ресурсы хоста» — это так-себе затея, а вот для десктопа самое оно.

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

Это лишь показывает то, что при желании точечно можно интегрировать и докер, но при этом остальные несистемные сервисы изолировать по умолчанию?

Я бы скорее сказал, что это показывает, какой всратый софт релизит Nvidia. Несистемные сервисы, которые работают не как root, внезапно, изолированы обычными правами доступа.

На вопрос «а если права настроены криво?» — если контейнер в докере настроен криво, то он может получить рут права на хосте, и тогда всё лицо в изоляции будет. В том числе потому серьёзные провайдеры крутят контейнера строго в VM.

Как ты думаешь, сколько на рынке таких специалистов, и сколько они стоят? Сколько компаний пишут на Erlang/Elixir? Меньше 1% ? Кто потом будет поддерживать их велосипед? Традиционный вопрос, почему не на асме или в машкодах.

Вопрос в 2026 не актуален, поскольку рынок труда завален сеньорами, ищущими работу. То, что 90% соискателей пишут на JS и Python, говорит просто про то, что большинство из них не смогут найти работу за приемлимые деньги.

Много твоих постов, где ты с удовольствием рассказывал про консенсусы в самых разных проявлениях?

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

Спешите видеть, эксперт по распределёнке предлагает непрофильным компаниям (которых большая часть), деплоить распределёнку на велосипедных самодельных аналогах Кубера.

Может быть я не совсем понятно выразился, но Ansible+systemd — это не совсем «самодельные велосипеды», хотя определённая доля ручной работы есть. Но в кубернетесе доля ручной работы выше, по крайней мере если цель — получить на k8s high availability, а не отвалиться с первым хостом, как это может произойти в топорном варианте с Ansible+systemd (хотя не факт, опять же, как настроишь).

Если нужно что-то чуть более сложное — есть Nomad. Опять же, как и в случае с systemd, сервисы могут быть чем угодно, не обязательно контейнерами.

От того, что ты настроил self-healing/failover на кубернетесе ты ещё не решил автоматически проблему «самовылечившаяся система теперь пускает пакеты от логики до БД через три хоста» — именно потому я пытался пояснить, что иметь изначально хорошо координирующийся сервис намного удобнее, чем пытаться лепить совершенно беспорядочно разработанные сервисы в единый комок в кубернете. Ну типа «столько-то экземпляров сервиса должны быть на том же хосте, что и БД, для БД нужен выделенный PV, такая-то доля запросов балансируется на удалённые хосты» — это как бы база, это даже не сложный сценарий, есть и повеселее, вроде эксплуатации со смешанными версиями при миграции.

Managed K8s, нет не слышали, ведь мы же иксперд по распределёнке!

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

По этой причине и по указанной выше проблеме с конфигурацией PV пользователи managed k8s часто предпочитают облачные БД вместо собственных БД на managed k8s. А если у тебя по итогу сплошные stateless сервисы в кубере, то там уже и не ясна ценность широких возможностей кубера по конфигурации кластера.

Дооо, Strimzi Kafka и Redpanda смеётся над твоими «гениальными» мыслями.

Ну я же написал «есть и такие извращенцы». Это я про Strimzi Kafka. Там поесть говна можно больше, чем получить преимуществ — но зато «клауд натив».

Вот Redpanda — это да, аргумент. Но это не Kafka, а отдельная protocol-compatible софтина.