Небольшое замечание по-поводу настройки демона keepalived на трёх master-нодах. Автор пишет что на всех трёх узлах необходимо указать:
state BACKUP
priority 100
Это не совсем верно. При такой конфигурации при "холодном старте" kubernetes-кластера (полное выключение всех нод кластера и последующий запуск) - регулярно будут возникать ситуации, когда виртуальный IP-адрес кластера отвечает на ping, но вот подключение к управляющему интерфейсу кластера с внешнего компьютера (не входящего в кластер) будет невозможно, с получением ошибок TLS-соединения.
Более правильным будет на одной из нод указать state MASTER и дать ей больший приоритет, например priority 101, после чего нодам кластера будет понятно что в первую очередь кластерный IP необходимо назначать на эту ноду, и только в случае её недоступности - на одну из BACKUP-нод.
Подробнее можно прочитать в документации по High Availability Considerations.
К слову, из этого также стаёт понятно, почему в связке с keeplived рекомендуется использовать haproxy. Т.к. без него все соединения будет обрабатывать только та нода, которая в данный момент держит IP-адрес кластера и чаще всего это будет нода отмеченая как MASTER, а остальные ноды будут простаивать. Haproxy решает эту проблему за счёт банального round-robin, пересылая каждый следующий запрос на следующую ноду, вне зависимости от того какая из нод сейчас обслуживает кластерный IP-адрес.
Ну и напоследок, в той-же Ubuntu 22.04 вместо интерфейса ens33 будет eth0 (но это уже просто маленькое дополнение).
Небольшое замечание по-поводу настройки демона keepalived на трёх master-нодах. Автор пишет что на всех трёх узлах необходимо указать:
Это не совсем верно. При такой конфигурации при "холодном старте" kubernetes-кластера (полное выключение всех нод кластера и последующий запуск) - регулярно будут возникать ситуации, когда виртуальный IP-адрес кластера отвечает на ping, но вот подключение к управляющему интерфейсу кластера с внешнего компьютера (не входящего в кластер) будет невозможно, с получением ошибок TLS-соединения.
Более правильным будет на одной из нод указать state MASTER и дать ей больший приоритет, например priority 101, после чего нодам кластера будет понятно что в первую очередь кластерный IP необходимо назначать на эту ноду, и только в случае её недоступности - на одну из BACKUP-нод.
Подробнее можно прочитать в документации по High Availability Considerations.
К слову, из этого также стаёт понятно, почему в связке с keeplived рекомендуется использовать haproxy. Т.к. без него все соединения будет обрабатывать только та нода, которая в данный момент держит IP-адрес кластера и чаще всего это будет нода отмеченая как MASTER, а остальные ноды будут простаивать. Haproxy решает эту проблему за счёт банального round-robin, пересылая каждый следующий запрос на следующую ноду, вне зависимости от того какая из нод сейчас обслуживает кластерный IP-адрес.
Ну и напоследок, в той-же Ubuntu 22.04 вместо интерфейса ens33 будет eth0 (но это уже просто маленькое дополнение).