Как правильно заливать из k8s в приложение список подов определенного сервиса?

Слишком плохо знаю k8s, но м.б. сами стриминговые сервера должны пушить свой статус на какой-нибудь discovery сервер. Бонусом всегда будет понятно, что какой-то из них перестал работать, в запросе ещё можно передавать нагрузку на каждом, чтобы балансер мог равномерно её распределять.

Но это мысли от балды.

не-не, пушить свой статус — это совершенно точно антипаттерн для кубера, там от такого всё ушло в поллинг. Лучше подождать минуту и поллить статус, чем ждать пуша (который не прийдет, прийдет, но не туда, потеряется)

Да и двухсторонние связи — это тоже зло и плохо, лучше до упора тянуть с односторонними.

https://kubernetes.io/docs/concepts/services-networking/service/ - для доступа к своему приложению ты должен определить сервис, который и будет учитывать, что сервис крутиться на нескольких подах, вероятно тебе будет нужен headless service.

Насколько я понимаю, балансировщик у тебя внешний

1. DaemonSet распределяет поды по нодам. И скорее всего у тебя HostNetwork, и порт фиксирован

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

2. уже правильно посоветовали про создание service. даже если тебе не нужна встроенная балансировка service (и вообще нет желания гонять трафик через nat’ы), так проще получить список endpoint’ов

3. (тут я не копенгаген, но с дивана выскажу) возможно, тебе нужен уже не кубер, а service mesh. возможно, пригодится consul

я так и сказал про DaemonSet.

Он нужен, чтобы запускался максимум один под на ноду.

В сервис они все собраны, получить список подов одного сервиса (подходящих нод) можно.

Вопрос именно в правильном паттерне для этого.

1. создать service account

2. выдать ему права на чтение service или что там ещё нужно. через RoleBinding

3. скопировать service account и CA certificate клиенту, который будет получать список. Можно даже собрать из них kubeconfig, чтобы не заморачиваться с написанием клиента, а просто дергать kubectl

4. profit

а можно вообще собрать контейнер, который запрашивает инфу из api и выдаёт endpoint с нужной информацией

Контейнерй по дефолту имеют учётку, достаточную для простых запросов к kube-apiserver’у

DaemonSet - логически это про другое, разделение по нодам - это про anti-affinity на подах

да, я так делаю для некоторых вещей. Вопрос в другом: это всё вот как, в каком-то кронтаске что ли делать, вытаскивать список подов и пихать их в мой балансировщик?

ты всё правильно говоришь, но daemonset настолько проще, чем эта anti-affinity, что его хочется использовать

Не использовал внешние балансировщики

Насколько я понимаю,

• либо такой балансировщик сам умеет работать с kubernetes (как балансировщики у облачных провайдеров), и достаточно создать service типа loadBalancer (https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/), а дальше либо сам балансировщик запрашивает информацию, или какой-то кастомный контроллер в кластере его оповещает/обновляет конфиг
• либо внешний балансировщик не умеет работать с kubernetes, и тогда его конфиг придётся создавать вручную, скриптами или прочими костылями

Ну сделай, чтобы балансировщик ходил в апи-сервер и забирал EndpointSlice от сервиса, например. Чем не вариант?

тебя тут спутал мой термин «балансировщик», надо было другое слово подобрать.

Речь не идет про раскидывание внешних запросов, речь идет про распределение нагрузки между имеющимися серверами.

Это очень консервативная штука, делать надо аккуратно, лишнего не переносить.

Речь не идет про раскидывание внешних запросов, речь идет про распределение нагрузки между имеющимися серверами.

Тогда моя твоя не понимать. Что есть твой балансировщик и где по отношению к кластеру он работает?

Обычно в кластере есть ingress controller. Его роль как правило выполняет специальный контейнер с nginx, traefik или haproxy

Он отслеживает появление в кластере объектов типа Ingress и добавляет их с свою конфигурацию

А уже сам контроллер выставляется наружу через HostNetworking или через внешний балансировщик, или через какой-нибудь менее продуктивный вариант вроде shared ip для кластера средствами metallb

У тебя получается цепочка Ingress -> Service -> Pod Балансировкой занимается сам ingressСontroller

Когда ты сказал, что у тебя вшений балансировщик, я решил, что у тебя вне кластера стоит условный nginx, который раскидывает запросы по отдельным нодам кластера (на которых живут pod’ы из DaemonSet), чтобы запросам не пришлось проходить через ingressController и NAT’ы кубера

Прежде чем изобретать велосипед, я бы проверил имеющиеся технологии. То, что вы описываете, смахивает на задачу для service mesh. В частности: https://istio.io/latest/docs/concepts/traffic-management/#load-balancing-options

так, давай вообще выкинем слово балансировщик, оно тебя уводит в совершенно другую сторону.

Давай назовем это распределителем вычислительной нагрузки между серверами.

Назови это трансклюкатором, твою задачу это никак не прояснит

Создай headless service. Потом делай DNS запрос по имени сервиса. Тебе вернёт список IP-адресов всех подов, которые сейчас живые и готовые обслуживать трафик. На API кубера завязываться в данном случае не нужно.

Это если твой балансировщик тоже внутри куба крутится, конечно. Если снаружи, тогда, наверное, проще через API.

пользоваться DNS вместо http api — это норм?

Ну как минимум это не привязывает твоё приложение к кубу и позволяет легко запускать его в докере или виртуалках или ещё где-то. Норм или не норм - решать тебе. Я бы так сделал.

Да, мы так эрланговские ноды в кластер собираем.

остался вопрос: как часто запускать этот код? Это что: какой-то регулярно стартующий под или его втыкать в какой-то процесс кубера?

Мы это делаем либой (и «стратегией» с дефолтными параметрами — т.е. код запускается каждые 5 секунд) прямо внутри обычного Elixir-приложения.

Т.е. у вас не централизованный провижнинг, а каждый инстанс это что ли делает?

Мы интерконнект нод ни в коем случае делать не хотим, достаточно наелись, мне нужно в центральное место свозить их список.

Т.е. у вас не централизованный провижнинг, а каждый инстанс это что ли делает?

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