Пытаясь настроить экспериментальный кластер Kubernetes (в нескольких виртуальных машинах на моем ноутбуке) как «высокодоступный», я нашел совет сделать это с помощью комбинации keepalived и haproxy (https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing).
Глядя на настройки конфигурации, я прочитал
${STATE} является MASTER для одного хоста и BACKUP для всех остальных хостов, поэтому виртуальный IP изначально будет назначен MASTER.
${PRIORITY} должен быть выше на главном сервере, чем на резервных. Поэтому 101 и 100 соответственно будет достаточно.
и эти настройки меня удивляют. Похоже, мне нужно выбрать, какая из этих систем будет первоначальным мастером, и мне нужно "жестко" настроить это в самих узлах.
На мой взгляд, такая «высокодоступная» настройка отличается от аналогии «домашнее животное»/«скот», которую я нахожу в Kubernetes.
Другие системы, например HBase, имеют похожую настройку (один активный и несколько резервных лидеров), и все они настроены «идентично» (выборы осуществляются через ZooKeeper).
Есть ли способ настроить Keepalived (для использования в Kubernetes) таким образом, чтобы все узлы имели одинаковую конфигурацию и при этом все работало правильно?
решение1
Kubernetes сам по себе предоставляет приложениям «cattle» сервисы. Хотя многие «главные» сервисы kubernetes основаны на той же инфраструктуре, в какой-то момент вам нужно будет запустить сервис с чем-то более низким уровнем, чтобы все это запустить.
поддерживать активностькак настроено всвязанный kubernetes doccoобеспечивает единыйВРРПвиртуальный IP-адрес как высокодоступная конечная точка, совместно используемая главными устройствами.
Все узлы настраивают один и тот же IP-адрес VRRP (или имя) и keepalived перемещают этот адрес вокруг мастеров. «Выборы» завершаются в логике проверки работоспособности keepalived и отказоустойчивости.
Альтернативой этому методу является перенос решения о балансировке нагрузки на внешнее устройство или клиентов. Вы можете запустить обратный прокси на каждом узле (как haproxy), который может взвешивать серверы kube-api и выполнять проверки работоспособности.
решение2
Я понимаю, что это устаревшая тема, но я все равно решил вмешаться, поскольку я запустил KeepaliveD с одинаковой конфигурацией на всех узлах.
В Debian все узлы изначально настроены на BACKUP и имеют своего рода проверку работоспособности, которая увеличивает приоритет (например, как долго работает KeepaliveD или проверка работоспособности локальной службы, для которой вы хотите обеспечить высокую доступность...)
VRRP v2, на котором KeepaliveD (по крайней мере, версии, с которыми я работал) работает в Debian, имеет функцию разрешения конфликтов, при которой, если приоритет на нескольких узлах одинаков, побеждает «наибольший IP-адрес».
Это может вызвать начальную задержку, если все узлы запускаются одновременно, но там, где мы это используем, это приемлемо.
Надеюсь, это поможет.