HA. Только не хочется отдельные машины под haproxy выделять, вот пытаюсь понять что будет если я haproxy на сами мастера засуну.
Даже теряюсь что тебе ответить. Если ты на каждый мастер поставишь хапрокси, который будет балансить все твои мастера, то наверное, отказоустойчивость ты какую-то получишь) Но сказать, что это бредятина - это промолчать
Балансировка не нужна, нужна просто отказоустойчивость. А почему бредятина? Я вот не могу придумать что дает вынос haproxy на отдельные машины (кроме какой-то наглядности и удобства).
Хорошего? :))
Ну как бы ты не решаешь глобально проблему отказоустойчивости
тут надо определиться. 1) HA для подключения к api-server внутри кластера. (из kubelet например) 2) HA для подключения из вне. Например при подключении через kubectl или при деплое из gitlab Для первого я бы рекомендовал локальные прокси/балансировщики на каждом узле. Для второго можно и VIP
Да первый кейс тоже випом закрывается
я бы не советовал этого делать
Для второго можно goteleport.com
в чате уже обсуждалось не однократно. VIP на мастерах с подключенными kubelet'ами к этому випку, это шанс поймать корнер кейсы. failover VIP'а не моментальный, и если что-то пойдет не так, kubelet'ы отваляться от apiserver'а. А следовательно ноды пометяться как notReady, а следвоательно kube-controller-manager выкинет из endpoints сервисов, поды которые были на этих нодах. И легко может случиться так, что в notReady уйдут именнно те ноды, на которых находятся все поды твоего приложения. А значит это гарантированные 503 ошибки. Я сам на личном опыте это ловил кстати
Обсуждают сегодня