Если торчат tcp-порты, то почему бы нет?
У меня в разных неймспейсах сервисы друг друга видят по FDQN
У тебя же есть DNS внутренний (по-идее)
попробуй внутри
nslookup <svc-name>.<namespace>.svc
или
nslookup <svc-name>.<namespace>.svc.cluster.local
Соотвественно по-сети сервисы друг друга отлично видят

или я не правильно понял вопрос?

Угу, я знаю что их видно с указанием ns. Я просто хочу сделать схему externally-available.routing -> locally-available.internal без добавления промежуточного контейнера, который будет принимать запросы из первого и направлять их во второй.

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

брррр

а что мешает екстернал-сервис ткнуть носом в кубе-днс?

подробнее

NGINX, использующий этот конфиг, бежит прямо на железе

вне всяких контейнеров

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

так а тогда где проблема-то?

под external service подразумевается просто проброс сервиса наружу. сейчас чуть подробнее опишу.

Есть некий namespace, пусть это backend. В нем есть база данных, которая светит портами: порт для клиентов, порт внутренней коммуникации, еще какой-нибудь порт. Все это дело светится только внутри кластера. В то же время я могу захотеть выбросить наружу порт для клиентов, на время или постоянно, и для этого хотелось бы в отдельном неймспейсе роутинга завести сервис, единственная цель которого - выдача внутреннего сервиса наружу, чтобы к нему можно было обратиться оп айпишнику кластера.

Это можно втупую реализовать с еще одним промежуточным деплойментом с nginx/haproxy, но если можно без - хотелось бы узнать такой способ

Что-то пока без идей...

да это не факт что вообще возможно, может я зря ленюсь через контейнер все бросать

а что конкретно у тебя в гластере?

картинки которые через админку загружает редактор