У меня есть в кластере два DaemonSet-а: база данных и

клиент для этой базы.
Необходимо сделать так, что бы клиент конектился только к тому pod-у с базой, которая запущена на той же ноде, что и клиент.
Судя по доке, это решается сервисом с опцией internalTrafficPolicy: Local.
Но у меня так работает только на одной ноде (на мастере), на остальных нодах клиент не может подключиться к базе, хоть и резолвит имя сервиса в IP-адрес.
Если эту опцию убрать из сервиса, то везде всё работает, но конект роутится раунд-робином по всем нодам кластера. Т.е. в целом и база и клиент рабочие, и у меня какая-то проблема только с тем как работает internalTrafficPolicy: Local.
Может кто-то делал что-то подобное и может подтвердить, что всё должно работать нормально? Или оно всё ещё не стабильное (фича в статусе beta) и может не всегда работать?

Объедини в один под и через локал хост)

Нельзя, там разные политики обновления этих приложений. Например клиент будет обновляться чаще.

Вот это я понимаю - использование Kubernetes на 200%

Я только начал переносить инфраструктуру в кубер и сразу столкнулся с этой проблемой. Так-то там будет всё сложнее. 😊

Ну это я тебе придумал под стать архитектуре)))

чот ты фигню делаешь какую-то) вообще не так делать нужно

Согласен

Скинь лучше задачу которую решаешь а мы тут тебе решение придумаем

А как надо? Это приложение "умный кеш". Сам кеш лежит на диске, в базе данных хранится индекс и доп. информация о кеше. Роутинг запросов в кеш идёт по хешу от параметра в запросе. Т.е. я не могу просто так отправить запрос на node1, если кеш для него лежит на node2. Само приложение я ещё могу сделать не DaemonSet-ом, но база-данных должна быть прибита гвоздями к ноде, на которой лежит volume с файлами кеша. И обращаться к этой базе должен только тот pod с приложением который запущен на этой же ноде, что бы потом он мог достать из кеша файл, на который укажет база-данных. Разные ноды с приложением ничего не знают друг от друге, базы данных не объединены в какой-то кластер.

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

> Разные ноды ничего не знают друг от друге, базы данных не объединены в какой-то кластер. Вот это концептуальненько

а конкретнее? это 2 разных окружения одного приложения? ну разгнеси по разным неймспейсам и все

Тут задачка в том чтобы соседи друг к другу ходили

Вот именно, и у меня оно не работает так как написано в доке

А что именно не работает?

Не работает опция internalTrafficPolicy: Local для сервиса.

крч я бы просто навешал на ноды лейблы 2 этих БД разнес по разным неймспейсам и сиди себе натравливай клиентов по service

Руками? А масштабировать как? Новые неймспесы делать для каждой новой ноды и заново создавать все "объекты"? Хотелось бы просто добавить ноду в кластер, пометить её лейблом, который означает, что на ней надо развернуть приложение и дальше бы кубер сделал всё что нужно.

Daemonset не умеет в PVС Template

умеет. чо бы нет. а в темлпейт нет

В Template умеет разве?

чат в реалном времене

Недописал 🙂

звучит как огромный велосипед и костыльная архитектура

архитектор на тяжелых наркотиках сидит с детства ? что бывает, когда тянешь легаси в оркестратор. Предлагаю поступить кардинально. Вашим подам с "базойданных" прописать режим сети hostnetwork. А подам через dawnwardAPI закинуть адрес узла из status.hostIP - the IP of the node to which the Pod is assigned чтобы они ходили к БД своей на адрес узла.

мы с кассандрой так и сделали

можешь засунуть базу и приложение в один под, лол, кек