Я пока вижу такое решение:
- так как каждый сервис деплоится сам по себе, то и всей обвязкой типа ингресса и правил роутинга он может сам управлять.
- мы назначаем некий «главный экземпляр» каждого сервиса (не важно, сколько там внутри подов, я про набор лейблов\неймспейс) - и именно он будет за роутинг запросов в себя отвечать.
- ты верно отметил, что оно потом разрастётся и будет больно - и я это понимаю, но препочитаю предварительно не решать.

Потому, что обычно тыкаешь не ты, а тебя

- Тут не нужен меш же, это проблема другого порядка. Он и без него может роутингом управлять в целом.
- Главный экземпляр, назовем его control plane, может конечно всем управлять (как бы контроллер, фактически оператор, если он объектами кубика рулит), но тут опять же непонятно нафиг нужен меш, он и без него может управлять.

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

- Тут не нужен меш же, это проблема другого порядка. Он и без него может роутингом управлять в целом.
- Главный экземпляр, назовем его control plane, может конечно всем управлять (как бы контроллер, фактически оператор, если он объектами кубика рулит), но тут опять же непонятно нафиг нужен меш, он и без него может управлять.

Никакой сервис никаким роутингом управлять не может и не должен, это не его бизнес-функционал. Я про деплой правил роутинга к себе.

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

"Неявная связь" это фактически запрос на virtual service, если я правильно понимаю. Но - функционал virtual service во многом схож с просто "service" и при этом и то, и то требует селекторов для корректной работы.

Я про это вот тут и сказал, что если ты эти сервисы-таргеты деплоишь отдельно, а конфиг роутинга отдельно - то оно обязательно разойдётся