Подключение к Kafka в изолированном окружении

Есть изолированное от внешнего мира окружение в GCP с кластером Kafka, который живет в GKE. Kafka используется как внутри GKE кластера, так и виртуальными машинами, которым Kafka выставлена через внутренний балансировщик. Часть пользователей не приемлют использование консольных команд чтобы подключиться к Kafka и хотят пользоваться привычными им инструментами вроде Offset Explorer и ему подобными.

Итого у нас есть три брокера Kafka, которые доступны внутри кластера как kafka-0.kafka-headless.default.svc.cluster.local:9092, kafka-1.kafka-headless.default.svc.cluster.local:9092 и kafka-2.kafka-headless.default.svc.cluster.local:9092. Для виртуальных машин создано три балансировщика с адресами 172.16.0.16:19092, 172.16.0.17:19092 и 172.16.0.18:19092.

Если просто пробросить порты на локальную машину, то ничего работать не будет, т.к. после подключения к Kafka брокеру клиент получит метаданные в которых будет фигурировать Kafka advertised listeners и клиент будет пытаться подключиться к ним вместо работы с проброшенными портами.

Лимиты памяти в LXC для CGroupV2

С неделю назад мигрировал ряд сервисов на базе контейнеров LXC в облако. Чтобы не переплачивать за простаивающие ресурсы в облаке взял в два раза меньше памяти и процессорных ядер. Поскольку нагрузка на сервисы минимальная, а памяти на исходном сервере было с запасом, то лимиты по памяти и ядрам не были настроены, но в условиях потенциальной нехватки ресурсов нужно решить проблему "шумного соседа" (когда один сервис может исчерпать ресурсы всего сервера и привести к нестабильной работе или отказу в обслуживании у остальных сервисов).

Для начала настроил сколько RAM и SWAP может использовать каждый из контейнеров.