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

На масштабе Google, Amazon, Microsoft кубернетес-совместимые реализации оркестраторов перестают работать.

Слушай, а ты много видел клиентов с такими масштабами?

Большинству хватает обычного Кубера с запасом раз в 10-100.

А если не хватает, то делают мультикластер, что при правильной архитектуре решения ещё сильнее повышает HA.

Конечно. А сервер под кроватью ащще самый топ!

Слушай, а ты много видел клиентов с такими масштабами?

Ну на 1000 узлов не такой уж и большой. Хотя у Гугла, наверное, и побольше есть.

Умеет, если БД cloud-native. Если нет, то получишь в десятый раз за день подвисший кластер,

Ты всерьёз предлагаешь запускать в Кубере кластерные НЕ cloud-native СУБД? LOL

EnterpriseDB (CNPG), Crunchy и десятки других компаний старались, старались, пилили свои операторы, а ты тут хоба, и решил сделать по своему. :)

не может свой деплоймент вернуть на старый репликасет,

А позвольте узнать, с каких пор СУБД в Кубере используют ReplicaSet для инстансов СУБД?

Кэши? Что ты собрался с ними делать? Как ты предлагаешь эту проблему решать?

Внешние кэши (Redis like, etc.) на других ядрах, по сетке?

OpenRC не решает вопросов сложной оркестрации,

Docker-like не решает такие проблемы.

OpenRC + Docker не решает вопросов «сложной оркестрации» (c), которые может решить systemd?

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

Продолжаю путать Docker с K8s? Или путать systemd с Docker? Или ещё что-то с чем-то? Можно поподробнее?

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

Можно пруфы?

Я про BEAM.

А разве K8s и BEAM - это конкуренты?

Ведь K8s кластеризует только сам себя (свой HA CP). А применительно к кластерным HA приложениям он лишь помогает их деплоить и обслуживать life cycle инфры.

А BEAM IMHO позволяет создавать новые кластерные HA приложения, которые как раз можно очень удобно деплоить через Кубер.

Т.е. K8s и BEAM дополняют друг друга, а не заменяют.

ВСЕ контейнера работают на хостовом ядре ОС и хостовом CPU.

Какая новость! :) (сарказм)

Контейнера вообще нифига не портируемые, и с чего бы им быть такими? Они независимы только от других установленных в систему прикладных сервисов

Ещё они независимы от хостового libc, поломок в пакетах или базе пакетного менеджера хоста, несовместимости пакетов. Обеспечивают портируемость софта большого количества разных версий дистрибутивов, использованных для сборки образа контейнера, между многими другими разными дистрибутивами Linux и их версиями на хосте.

Если у тебя ядро не поддерживает IORING_OP_SETXATTR, а твой сервис делает операцию через него, то твой сервис не будет работать на этом ядре. А на моей текущей работе ВСЕ сервера не поддерживают IORING_OP_SETXATTR. И AVX2 на них тоже нету.

И причём тут это?

А когда все сидели на винде — это тоже был прорыв, наверное?

Для зондов конечно, где ещё столько проприетарного зондирования кроме аппаратных мониторов?

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

Ога, все бросились пересобирать пакеты из дистров в статические бинари, это ведь так просто и предсказуемо по затратам времени и вообще достижимости успешного результата? :) (сарказм)

То, что кому-то нужен экскаватор, не значит, что лопаты уже стали бесполезными.

Знаешь ли, есть очень лайтовые внешние системы observability «all in one» типа https://openobserve.ai/

И тут твоя аналогия про лопату vs экскаватор не очень подходит.

Я бы лучше сравнил journald c палкой-копалкой макаки допалеолитического периода,

а openobserve с современным легким переносным электрокультиватором с микропроцессорным управлением.

Предварительный анализ диспута с помощью Grok Expert (aka «нейродурака» (c) by Dimez):

byko3y is wrong in this dispute.

• byko3y = pro-systemd overall. He defends it as the finished, declarative orchestrator (shows the Caddy unit with sandboxing, says Pottering did it because “bashgovno ещё хуже”, argues that containers still pull in systemd anyway, that journald is better than external tools, that cgroups/resource control is properly done in systemd, etc.). He treats OpenRC + Docker as inferior or incomplete.

• sanyo1234 = against systemd as the default/host orchestrator. He explicitly offers the hybrid you described:

  • OpenRC (Alpine on host) for simple services (udev, crond, etc.).
  • Docker/Podman (or compose) for complex services (mail, DBMS, web apps, etc.).
  • Alpinebox or similar when you want no systemd at all.
  • Talos when you need immutable K8s.

This is exactly what the 4 points you listed in the very first message confirm, plus the udev/crond exchange you reminded me of (“Простые сервисы в Alpine Linux на хосте” + “минимальный набор … из инита, но потом многие другие уже можно запускать в контейнерах”).

Why byko3y is the one who is wrong here

He spends the entire argument attacking a straw-man version of sanyo1234:

• Pretends sanyo1234 wants “Docker/Podman alone” as systemd replacement.
• Ignores or mocks the Alpine/OpenRC offer for simple services.
• Ignores the Talos offer exactly when he complains that unmanaged K8s is painful.
• Invents “architecture portability” claim that sanyo1234 never made (and sanyo1234 explicitly denied it).

byko3y’s technical points (systemd sandboxing, journald, cgroups, integration) are not stupid in isolation, but his whole line of attack is built on misrepresenting what sanyo1234 actually proposed. That makes him wrong in the context of this specific dispute.

sanyo1234’s position is consistent and pragmatic: systemd is not the only or best tool for every case; for many workloads (especially single-node or small-scale) OpenRC + containers + Talos where needed is cleaner and sufficient. byko3y refuses to engage with that actual position and keeps fighting the caricature instead.

So yes — byko3y is the one who is wrong. He is the one defending systemd while distorting the anti-systemd alternative that was actually offered.

Предварительный анализ диспута с помощью Grok Expert

Очень похоже когда школоло не вывозит и зовёт брата из старших классов врубиться.

Дык уже разнёс большинство аргументов @byko3y в пух и прах, АИ лишь для подведения итогов уже после этого, ведь как упоминается в рекламе, АИ очень хорош для classification and summarization?

И велик выигрыш в пропускной способности по сравнению с контейнерами? Способность больше зависит от IO или от запуска в контейнере vs bare metal ?

Давай загибать на пальцах:
1. NAT добавляет 1-2 мс задержки — нужно использовать networking=host;
2. Естественно, мы монтируем persistent volume, причём, переиспользуемый/горячий, потому что поднятие холодной реплики стоит несколько минут;
3. Kafka использует системный кэш, потому в идеале она вообще должна быть единственным сервисом в системе.

Теперь внимание вопрос: если ты запустил кафку в кубернете единственным сервисом с networking=host на всей железной ноде, то кто ты после этого?

А убытки от неудобства деплоя без контейнеров кто-то посчитал?

А убытки и неудобства деплоя в кубернете вообще считаются за таковые?

Ты про ECS? Без контейнеров?

ECS является одним из трёх сотен сервисов AWS.

Предлагаешь завендорлочиться на AWS?

Если ты будешь деплоиться в managed k8s, то твой деплой будет завендорлочен на их реализацию. Не сами сервисы, но деплой.

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

А на чём?

Ветка обсуждения недавнего:
Какой смысл «выбирать между линуксами»? (комментарий)

Даже боюсь представить, сколько новых боргов рождено в недрах Yandex, MTS, Timeweb, Сбер, Selectel, etc.

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

А для unmanaged k8s тебе нужно выполнять «упражнения» — и цена этих упражнений может не оправдываться решаемыми задачами.

Talos, нет не слышали?

На том, чтобы просто поставить k8s на ноду, проблемы не решаются. Как правило, k8s используется с виртуальной сетью — её нужно настраивать, и для этого даже отдельная профессия существует. Storage ты должен сам обслуживать, хоть это обычно попроще, чем сеть. Мониторинг, балансировка-фаерволы, сертификаты — это всё самостоятельно придётся настраивать и обслуживать. И возникает вопрос «а в каком месте нам k8s, собственно, помог?». В том, что он self-healing? Это self-healing вообще-то тоже надо настроить.

На уровне трех клиентов или подкроватного сервера они правы, это не нужно. А вот если хайлоад, то уже ой, но в мире адептов локалхоста такого не бывает

Ну я уже писал, что хайлоад очень относительный, на уровне 10-100 хостов кубернет зайдёт на отлично... при условии, что ваша система уже cloud-native, потому что иначе, как я писал выше, может оказаться так, что ваша нода на k8s ничем не отличается от сырой железки.

Но ведь такие App платформы пиарятся якобы более простым деплоем, чем классический GitLab/Jenkins + Flux?

Простым деплоем уже контейнеризированного софта. Ещё раз: та же Kafka не является cloud-native.

А ещё ты про базу упоминал, так вот такие платформы предлагают PaaS сервисы из каропки.

У Coolify БД работают на отдельном хосте почти на голом железе, как я описывал. DigitalOcean и AWS тоже раскручивают отдельную в VM, только в отличие от Coolify они серьёзно относятся к безопасности, потому не размещают две БД от двух разных клиентов в одной ОС.

Так или иначе, деплой БД vendor-dependant.

Yandex или Selectel multi AZ, - нет, как всегда не слышали, поэтому пилим свой «намного более простой» HA велосипед на Ansible + systemd

А ты когда-нибудь пилил мультизонную доступность эдак Нью-йорк - Франкфурт - Гонконг? Вопрос инструмента деплоя в этих вопросах является одной из последних проблем. Например, на AWS по этим причинам мультизонные возможности намного ограниченнее внутризонных и много чего нужно настраивать руками.

И я ещё раз повторюсь, что ни яндекс, ни селектел не используют кубернетес для своих датацентров. Селектел точно использует OpenStack, Яндекс может быть, но скорее всего у них что-то своё самопальное, даже если основывается на OpenStack и прочем опенсорсе.

Слушай, а ты много видел клиентов с такими масштабами?
Большинству хватает обычного Кубера с запасом раз в 10-100.

«Большинству» и твой self-healing кубера не нужен. Если одна из трёх нод упала, то её на утро просто подымают руками.

А если не хватает, то делают мультикластер, что при правильной архитектуре решения ещё сильнее повышает HA.

При ещё более правильной архитектуре из уравнения выкидывается кубернетес и оставляется только тот самый инструмент над куберовыми кластерами, который «сильнее повышает HA».

Ну на 1000 узлов не такой уж и большой. Хотя у Гугла, наверное, и побольше есть.

Даже у РЖД порядка тысячи серверов. РЖД, который вообще не айти. У нас в компании несколько десятков серверов, большинство разрабские, всё руками поддерживается.

EnterpriseDB (CNPG), Crunchy и десятки других компаний старались, старались, пилили свои операторы, а ты тут хоба, и решил сделать по своему

Факт существования кубер-оператора ещё не значит, что не cloud-native БД будет работать как по маслу.

А позвольте узнать, с каких пор СУБД в Кубере используют ReplicaSet для инстансов СУБД?

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

Внешние кэши (Redis like, etc.) на других ядрах, по сетке?ешние кэши (Redis like, etc.) на других ядрах, по сетке?

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

OpenRC + Docker не решает вопросов «сложной оркестрации» (c), которые может решить systemd?

Да. Активацию по сокету ты как сделаешь в OpenRC + Docker? Прежде всего добрая половина systemd решает вопрос конфигурации железа, которую ни OpenRC, ни докер не умеют решать. На OpenRC-based системах для этого обычно используются отдельные сервисы аля udevd, logind, networkd и прочих. Удачи реализовывать аналоги After, Requires, BindsTo на OpenRC.

Продолжаю путать Docker с K8s? Или путать systemd с Docker? Или ещё что-то с чем-то? Можно поподробнее?

Да, продолжаешь путать контейнерный рантайм с системой оркестрации: Docker vs k8s, Podman vs Nomad, Systemd vs OpenRC.

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

Можно пруфы?

Какие тебе пруфы нужны? Какая хотя бы одна фича из него разработана для задач именно развертывания ноды кубера? ФС мутабельна, пакеты как пакеты, и так далее.

А BEAM IMHO позволяет создавать новые кластерные HA приложения, которые как раз можно очень удобно деплоить через Кубер.

Может ещё systemd предложишь деплоить через кубернет? Как такая херня вообще может прийти в голову?

Вообще предполагалось, что в эксперименте типа «китайская комната» вопросы должен задавать живой человек машине, но так даже смешнее.

Ещё они независимы от хостового libc, поломок в пакетах или базе пакетного менеджера хоста, несовместимости пакетов.

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

Если у тебя ядро не поддерживает IORING_OP_SETXATTR, а твой сервис делает операцию через него, то твой сервис не будет работать на этом ядре. А на моей текущей работе ВСЕ сервера не поддерживают IORING_OP_SETXATTR. И AVX2 на них тоже нету.

И причём тут это?

При том, что на совершенно работоспособной кубернет ноде внезапно будут не работать «портируемые» сервисы.

А когда все сидели на винде — это тоже был прорыв, наверное?

Для зондов конечно, где ещё столько проприетарного зондирования кроме аппаратных мониторов?

Это не я предлагал исходную идею «одна ОС FTW».

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

Многие сервисы на Go собираются статически просто добавлением одного флага сборки.

Знаешь ли, есть очень лайтовые внешние системы observability «all in one» типа https://openobserve.ai/

Отэта ты гений, предлагаешь использовать пет-проект, позавчера навайбкоденный на коленке и падающий с OOM на любых серьёзных объемах.

а openobserve с современным легким переносным электрокультиватором с микропроцессорным управлением.

Openobserve — это копание земли вибродилдой.

Вообще предполагалось, что в эксперименте типа «китайская комната» вопросы должен задавать живой человек машине, но так даже смешнее.

Ну как те сказать... очевидно, что он слабо понимает о чём пишет, но по крайней мере до сих пор не копипастил нейросеть напрямую, а все остальные всё равно слились, так что...

1. NAT добавляет 1-2 мс задержки — нужно использовать networking=host;
2. Естественно, мы монтируем persistent volume, причём, переиспользуемый/горячий, потому что поднятие холодной реплики стоит несколько минут;

И сколько это в процентах?

ECS является одним из трёх сотен сервисов AWS.

Я уже упоминал, что вендор лок не подходит. И откуда там взяться 100500 других плюсов из CNCF без их кубика?

Если ты будешь деплоиться в managed k8s, то твой деплой будет завендорлочен на их реализацию. Не сами сервисы, но деплой.

Если деплоить в Yandex K8s или в Timeweb K8s, то какие будут отличия? Разве K8s не универсален?

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

А причём тут инфра и major провайдеры? Я пишу про малый и средний бизнес, и им обычного Кубера именно для деплоя приложений, а не виртуалок, с огромным запасом хватит. А если не хватит, то есть мультикластер? А большинству хватило бы кубера даже и для инфры в виде Cozystack, например.

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

Можно поподробнее? Ты про CNI или про приватную сеть типа VLAN у хостера?

Storage ты должен сам обслуживать, хоть это обычно попроще, чем сеть. Мониторинг, балансировка-фаерволы, сертификаты — это всё самостоятельно придётся настраивать и обслуживать.

Cozystack like, если у самого лапки.

И возникает вопрос «а в каком месте нам k8s, собственно, помог?».

В том, что получаем стандартный способ деплоя, а не твой велосипед с непонятными последствиями.

Ну я уже писал, что хайлоад очень относительный, на уровне 10-100 хостов кубернет зайдёт на отлично

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

Тут кто-то собирается обслуживать облака масштаба major операторов на Кубере в качестве единственного оркестратора?

… при условии, что ваша система уже cloud-native,

А ты собрался монолит в Кубере запускать?

Простым деплоем уже контейнеризированного софта. Ещё раз: та же Kafka не является cloud-native.

В твоём понимании контейнеризация достаточна для того, чтобы называть приложение cloud-native?

У Coolify БД работают на отдельном хосте почти на голом железе,

Coolify и десятки других аналогичных проектов деплоят PaaS инстансы СУБД без контейнеров?

Так или иначе, деплой БД vendor-dependant.

Coolify - это self hosted? Причём тут вендор?

А ты когда-нибудь пилил мультизонную доступность эдак Нью-йорк - Франкфурт - Гонконг?

А причём тут Кубернетис вообще? Это же multi-region.

Тебя не учили, что кластер обычного Кубера с обычнымс etcd должен находиться в одном регионе?

Но таки у GCP есть решение и для multi-region на основе Spanner, но шибко дорогое.

Вопрос инструмента деплоя в этих вопросах является одной из последних проблем.

Зачем ты притащил такой кейс, для которого Кубер вообще не предназначен изначально? Ещё и выдумываешь за других, какие им инструменты деплоя использовать.

Например, на AWS по этим причинам мультизонные возможности намного ограниченнее внутризонных и много чего нужно настраивать руками.

Ты про их Аврору или про что? И опять, причём тут Кубер?

И я ещё раз повторюсь, что ни яндекс, ни селектел не используют кубернетес для своих датацентров. Селектел точно использует OpenStack, Яндекс может быть, но скорее всего у них что-то своё самопальное, даже если основывается на OpenStack и прочем опенсорсе.

Как будто я утверждал обратное.

Но managed Kuber то у них обычный?

«Большинству» и твой self-healing кубера не нужен. Если одна из трёх нод упала, то её на утро просто подымают руками.

У Кубера кроме self-healing ещё десятки полезных возможностей.

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

При ещё более правильной архитектуре из уравнения выкидывается кубернетес и оставляется только тот самый инструмент над куберовыми кластерами, который «сильнее повышает HA».

Это какой инструмент? Который эластичными нодами рулит?

Ведь сам Кубер управляет self healing для подов, а не нод?

У нас в компании несколько десятков серверов, большинство разрабские, всё руками поддерживается.

Но постоянно тащишь в обсуждение тысячи нод опен стека, с которыми Кубер не справляется.

Факт существования кубер-оператора ещё не значит, что не cloud-native БД будет работать как по маслу.

В твоём понимании cloud-native СУБД обязана уметь неограниченно масштабироваться горизонтально в режиме master-master да ещё и межрегионально как Yugabute или Cockroach?

Чего с твоей точки зрения не хватает для cloud-native у PG с операторами типа CNPG и Crunchy?

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

Ты пишешь шизу, что я якобы путаю Кубер с Докером, причём абсолютно недоказуемо в режиме создания из меня карикатуры.

А сам при этом доказумео путаешь ReplicaSet и StatefulSet, что намекает на твою проф непригодность для работы с Кубером?

Ещё бы предложил в другом датацентре.

Зачем? Опять клоунадишь?

Кеш нужен для того, чтобы иметь копию данных близко к потребителю, а не для того, чтобы стать ещё одной медленной БД.

Нет кэширующего софта, работающего через IVSHMEM и/или RDMA?

Активацию по сокету ты как сделаешь в OpenRC + Docker?

Мне лишние дыры ненужны.

Удачи реализовывать аналоги After, Requires, BindsTo на OpenRC.

В OpenRC нет возможности указать последовательность запуска сервисов?

А в docker-compose есть depends_on и т.п.

И сколько это в процентах?

В процентах чего? Числа пользователей, который ушли к конкуренту, потому что у тебя сайт не открывается, пока кубер жонглирует БД?

В процентах чего? Числа пользователей, который ушли к конкуренту, потому что у тебя сайт не открывается, пока кубер жонглирует БД?

Опять клоунадишь, в обсуждении шла речь о якобы больших накладных потерях контейнеризации по сравнению с bare-metal.

Если у тебя не хватает экспертизы в K8s, то можно ограничиться докером (+ compose ессно и т.п.).

Да, продолжаешь путать контейнерный рантайм с системой оркестрации: Docker vs k8s, Podman vs Nomad, Systemd vs OpenRC.

Где я путаю контейнерный рантайм с системой оркестрации?

Это наверно только в твоём воспалённом воображении докер является рантаймом?

K8s и docker-compose - это системы оркестрации (ессно разного калибра).

Как вариант рантайм высокого уровня - containerd, низкого - runc.

Какие тебе пруфы нужны?

Хотя бы пруф вот этого твоего очередного бреда:

Alpinebox, как и сам Alpine, разрабатывался для работы внутри контейнейра, не для запуска ноды кубера.

Какая хотя бы одна фича из него разработана для задач именно развертывания ноды кубера? ФС мутабельна, пакеты как пакеты, и так далее.

На обычном дистре K8s не поставить?

Может ещё systemd предложишь деплоить через кубернет?

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

Как такая херня вообще может прийти в голову?

Ты про Elixir в Кубере?

А причём тут я, если такое есть даже в либах для твоего любимого Elixir?

https://github.com/bitwalker/libcluster

Многие сервисы на Go собираются статически просто добавлением одного флага сборки.

Весь софт написан на Go, ога?

Если деплоить в Yandex K8s или в Timeweb K8s, то какие будут отличия? Разве K8s не универсален?

CNI другой, балансер другой, IAM, секреты другие, конфигурация PV/PVC другая, ну и тупо CLI другое. То есть, нужно заново конфигурать окружение, в котором твоя система будет работать.

А причём тут инфра и major провайдеры? Я пишу про малый и средний бизнес, и им обычного Кубера

Ты писал «Даже боюсь представить, сколько новых боргов рождено в недрах Yandex, MTS, Timeweb, Сбер, Selectel, etc.» — в каком месте это «малый и средний бизнес»?

Можно поподробнее? Ты про CNI или про приватную сеть типа VLAN у хостера?

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

Storage ты должен сам обслуживать, хоть это обычно попроще, чем сеть. Мониторинг, балансировка-фаерволы, сертификаты — это всё самостоятельно придётся настраивать и обслуживать.

Cozystack like, если у самого лапки.

Ну так а я тебе о чём? Talos никакую из этих проблем не решает.

В том, что получаем стандартный способ деплоя, а не твой велосипед с непонятными последствиями.

Деплой на хлеб не намажешь. Что деплоить, для чего деплоить? Это типа не важные вопросы?

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

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

А ты собрался монолит в Кубере запускать?

Я собрался запускать монолит без кубера. Последняя цифра WhatsApp до приобретения фейсбуком была 500 млн пользователей — можешь прикидывать примерно, это мелкий или средний бизнес.

на любых серьёзных объемах.

journald на таких объёмах будет лучше OpenObserve?

Openobserve — это копание земли вибродилдой.

Боюсь даже представить, чем в таком случае является journald.

Ну как те сказать… очевидно, что он слабо понимает о чём пишет,

IMHO у тебя опыта работы с Кубером вообще около нуля и твои сообщения про него походят на первые версии LLM без web RAG.

То, что ты от него убежал у своего бывшего работодателя лишь подтверждает это.

но по крайней мере до сих пор не копипастил нейросеть напрямую,

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