Как стать автором
Обновить

Комментарии 12

Да, а ещё бывают целые приложения для решения той же задачи. В какой-то мере это костыль, но поскольку он собран по частям из разных утилит, позволяет делать и другие «обходные» вещи (вроде тех, что описаны в «других идеях»).
Отличная идея, спасибо!

и тут вы открываете для себя kubectl port-forward и понимаете что целая статья костылей посвящена уже готовому решению из коробки

С kubectl port-forward есть проблема: он не поддерживает forward-proxy (с компьютера на под). Также в разделе «Другие идеи» есть другие примеры использования tcpserver в рамках k8s
если автор статьи знает про этот инструмент, то ему просто было необходимо сказать что дескать вот существует готовое решение и сказать что его функционала не хватает (чего конкретно не хватает) и предложить собственное. т.е. обязательно с указанием того какую проблему он решает. В текущей ситуации читателю придется садиться и реально анализировать чем ему описанный в статье подход поможет

tl;dr, зачем это все, если можно задеплотить socat в pod? Есть даже готовый хельм. Кажется, называется, socat-tuneller. У него есть один фатальный недостаток, но, в целом, методика рабочая.
Ну, и, конечно, kubectl port-forward

Миллениалы изобрели…
Представляю следующую статью на хабре "Шок! Сенсация! Отправка емейл с помощью telnet!"


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


P.S. Представляю что будет когда девопсы узнают про iptables. Сколько статей появится про dnat

В этом и «фишка» данного рецепта. Он использует традиционные утилиты и предлагает довольно универсальное решение, которое хорошо ложится на k8s, но легко распространяется и на другие контейнеры, и не только на них, конечно.

На статью про нее есть ссылка в ответе на первый комментарий :)

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