Всем привет, ходил в офф доку, в гугл, в поиск

по чатику, в чат гпт, в Ютуб, может кто помочь с leases и leader election в кубе? Я не пойму, нужно чтобы само приложение захватывало этот leases? Допустим захватило, а что дальше? Я так думал, что будут какие-то действия со стороны куба, например только этот под будет оставаться в endpoints. В частности, такую задачу я и хочу решить. Например поднять что-то в нескольких репликах, но чтобы все маршрутизировалось на 1 под, пока прикостылил на стики сессиях, но вот хочу про leases разобраться.

1. можно заюзать разные сервисы под это и выбирать нужные контейнеры через лейбл 2. Истое вроде такое позволяет сделать

leader election это вообще не про трафик, это просто механизм доя определения кто тут папа

и как вариант костыля, можно readiness не отдавать без election

я вот вообще не понимаю, накой хер в такой задаче election

я тоже

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

Например есть wiremock, который ты предварительно конфигуришь что тебе и как мокать. Потом стучится клиент, а он тебе отвечает - такого адреса нет. Адреса нет, потому что запрос от клиента попал на второй под wiremock, а запрос на настройку мока на первый.

выглядит как проебанный readiness

то есть у тебя есть * конфигуратор - это один http клиент * клиент апи - это второй http клиент * wiremock api - это первый http сервер * wiremock mock api - это второй http сервер и тебе надо как-то сделать так, чтоб конфигуратор и клиент с одного инстанса ходили к api и mock api другого инстанса. это даже не stickiness, потому что клиенты и сервера разные. такое лучше через shared state решать

Три действующих лица: конфигуратор, приложение в двух репликах в кубах, клиент. За счёт того что стучатся разные клиенты, куб балансирует их на разные поды. Как итог конфигуратор и клиент видят разные состояния. Из коробки эта штука не умеет использовать ничего, что позволит вынести ее состояние куда либо, типа бд, чтобы оно работало корректно в более чем одной реплике

ну тогда использовать одну реплику wiremock

Если бы я мог, я бы не пришел сюда, логично? 😁 Раз мы оба пришли к тому мнению. И вот в этом и стоит вопрос про понятие lease в кубах. Это что-то большее чем просто сущность, которую кто-то должен захватывать и самолично обрабатывать или нет.

лизы это про выбор лидера в кластере приложения. тебе это не поможет. Если wiremock не умеет в кластер, то такой внешний механизм тебя приведёт к тому, что из нескольких реплик будет тупо использоваться одна - для всех клиентов.

а зачем тебе два пода wiremock?

> Это что-то большее чем просто сущность, которую кто-то должен захватывать и самолично обрабатывать или нет. нет это именно такая сущность, а не что-то большое ты можешь написать сайдкар к wiremock, который будет занимать lease и redinessProbe для него. Если lease не занят, фейлишь redinessProbe. Но непонятно нафига тебе несколько подов wiremock если он не умеет в таком режиме работать. Запусти один pod Даже если lease заюзать как я выше описал. У тебя все равно стейт wiremock не переносится никаким образом. И если lease займет другой wiremock то его стейт будет чист как слеза младенца

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

Супер разжевал, спасибо. О проблемах я понимаю, просто как раз активно предлагают использовать lease для решения озвученной проблемы, я и не мог понять чем же он поможет, думал там у куба под капотом ещё куча всего. А так получается либо сайдкар, либо само приложение учить (если это твое приложение).

удолетвори любопытсво. Зачем wiremock в нескольких подах?