ты мог снаружи управлять кластером подключаясь по одному IP? Самому кластеру он ведь не нужен для работы? И в целом без него можно жить подключаясь просто к живому мастеру самостоятельно?
Представим картину что у тебя есть 3 мастера и 2 воркера: - master-a(1.1.1.1) - master-b(1.1.1.2) - master-c (1.1.1.3) - worker-1 - worker-2 Ты на master-b выполнил команду kubectl get join token или чет-то там. Он вшил свой айпи в эту команду и ты присоединил этой командой worker-2 в случае если у тебя master-b выйдет из строя и станет недоступен kubelet на worker-2 не сможет получить информацию от API и выведет ноду из работы вызвав NotReady и переезд нагрузки на другие воркеры в нашем случае на worker-1 потому что ты его джоинил например на master-c
Ого, спасибо за классное объяснение. Но конечно обидно почему кубер сам не может это чинить, передавать например на воркеры IP всех мастеров, чтобы воркер потом просто проверял кто стал главным.
Самый популярный способ HA для воркеров это Nginx / HAproxy с апстримами всех мастеров
https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ha-mode.md
Кстати, если интересно. Я сейчас посмотрел как в microk8s эта проблема решена (и решена ли) и там автоматом настраивается на воркерах traefik в котором прописываются IP всех мастеров. То есть по сути все как ты описал. Очень познавательно 🤓
HAproxy обычно больно
хапрокси топ
бесспорно но конфиги после nginx прям не привычно странно
персональные привычки не делают продукт лучше/хуже
Все говно. Переходим на энвой
ну дак не имей привычек делать из веб сервера балансер +)
лучше не имет привычки делать все веб-сервером XD
Обсуждают сегодня