Комментарии 12
Да, а ещё бывают целые приложения для решения той же задачи. В какой-то мере это костыль, но поскольку он собран по частям из разных утилит, позволяет делать и другие «обходные» вещи (вроде тех, что описаны в «других идеях»).
Отличная идея, спасибо!
и тут вы открываете для себя kubectl port-forward и понимаете что целая статья костылей посвящена уже готовому решению из коробки
С kubectl port-forward есть проблема: он не поддерживает forward-proxy (с компьютера на под). Также в разделе «Другие идеи» есть другие примеры использования tcpserver в рамках k8s
если автор статьи знает про этот инструмент, то ему просто было необходимо сказать что дескать вот существует готовое решение и сказать что его функционала не хватает (чего конкретно не хватает) и предложить собственное. т.е. обязательно с указанием того какую проблему он решает. В текущей ситуации читателю придется садиться и реально анализировать чем ему описанный в статье подход поможет
VPN через k8s кластер: https://github.com/kayrus/kuttle
tl;dr, зачем это все, если можно задеплотить socat в pod? Есть даже готовый хельм. Кажется, называется, socat-tuneller. У него есть один фатальный недостаток, но, в целом, методика рабочая.
Ну, и, конечно, kubectl port-forward
Миллениалы изобрели…
Представляю следующую статью на хабре "Шок! Сенсация! Отправка емейл с помощью telnet!"
По сути. К куберу это отношения не имеет. Перенаправлять трафик на уровне приложения это стандартная, десятки лет решённая задача.
P.S. Представляю что будет когда девопсы узнают про iptables. Сколько статей появится про dnat
Вот есть удобная тулза с UI github.com/pixel-point/kube-forwarder
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как с tcpserver и netcat открыть туннель в Kubernetes pod или контейнер