Перед кластером на metallb часто ставят балансер для нод

зис

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

keepalived на линксе как вариант.
Если вопрос в том что "есть Н компьютеров, у каждого есть IP" в случае если ПК физически померает и до него нет связи, то все запросы которые прилетают на конкретно этот IP, будут уходить в никуда.......
То что я знаю это уже отдельный loadbalancer средствами самой линуксы или сетевого оборудования

?

Да, то что часть запросов будет улетать я понимаю. Главное чтобы хотябы пока не ложился полностью кластер

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

у вас весь кластер на одной физической машине ?

Сейчас без keepalived. Мало про него читал, но я как понимаю он выделяет виртуальный айпи, который как раз таки плавает по этим айпишкам?

Нет, нод 11

Но сеть ходит через одну машину

И kubeapi также был заведен. Kubeapi решили через dns по трем айпи, если ляжет один из них ничего страшного в том что один раз из трех будет падать kubectl get pods, главное весь доступ не потерять

У вас есть Н компьютеров/серверов, на каждом ставится служба keepalived, каждому дается приоритет, они каждые Н секунд делают опросы, виртуальный IP назначается компьютеру с наибольшим приоритетом, если виртуальный IP пропадает, начинается голосование, у кого приоритет выше, поднимает у себя данный плавающий IP, в крации как то так.

Ага, тоесть metallb также будет ходить по этому плавающему айпишнику, но куда этот айпи запроксируется решит keepalived. Правильно понимаю? По сути это решит эту задачу

https://habr.com/ru/post/321448/

Есть статейка, не самая лучшая, но достаточно интересная.....
Я не могу представить себе отказоустойчивой схемы с одной точкой отказа.

Мне казалось metallb умеет это с коробки, но я ошибался

я схему не до конца понял, просто представьте что вы руками на сетевой карте прописали 2-ой IP, и он сам при необходимости настроит себя на другой виртуальной машине

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

Сейчас сделано так:
Kubeapi и весь сетевой трафик, идет на 8-ю машину из 11. Это один из мастеров. В metallb из пула адресов прописаны три, 6-8 машины.

Service’у ingress metallb отдает 1 адрес, 8-ю, так как он первый в пуле, в итоге весь сетевой трафик идет на 8 резолвиться.

Если я для сервиса пропишу руками три externalIP, сеть может дойти до service ingress через три хоста, но в итоге loadBalancer этого ingress отправит дальше на 8 машину, так как из пула для loadBalancer он все еще будет брать один, и metallb будет его балансить только на эту машину. Соответственно если упадет 8 машина, подключение дойдет до сервиса с 7 или 6 машины, но дальше он не сможет зарезолвиться

Решает приоритет, у вас 3 сервера, на каждом прописан приоритет 100-120-140, пока сервер с приоритетом 140 жив, VIP на нем, когда он умрет, VIP перескакивает на сервер с приоритетом 120, но в целом... да keepalived решает у кого будет VIP