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