Я хотел бы расширить свой собственный локальный стек HA Kubernetes с 3 плоскостями управления, кластером с 3 рабочими узлами в 3 офисных помещениях. Таким образом, каждая контрольная плоскость и 1 работник будут в каждом из офисов. У каждой плоскости управления будет свой статический IP-адрес.
Мне трудно понять, как балансировщик нагрузки (я использую Metallb) мог бы выполнять свою работу, если бы, допустим, в офисе 1 отключилось электричество. Как перенаправляется трафик в офис 2 и 3?
например Внешние общедоступные пользователи, обращающиеся к nextcloud, запущенному на узле office-1-node, могут использовать fqdn cloud.company.com, который связан со статическим IP-адресом office-1-node. (хотя nextcloud может быть запущен на рабочем или главном узле office-2-node или office-3-node ... но для пользователей это не проблема.)
Если в офисе-1-node отключится электричество, что будет направлять cloud.company.com на статический IP-адрес office-2-node или office-3-node?
Я все еще учусь, поэтому имейте это в виду при ответе.
Я видел, что Metal LB развернут (https://metallb.universe.tf/installation/) в качестве контроллера (который обрабатывает назначение IP-адреса) и демона (компонент - динамик -> Это, я думаю, обработка внешних объявлений в соответствии с https://metallb.universe.tf/concepts/). Таким образом, этот LB в основном развернут как ресурс Kubernetes.
Теперь переходя к вашему вопросу, если office-1-node выходит из строя, модули daemonset с других узлов будут работать по мере необходимости (делать внешнее объявление и делать службы доступными), а контроллер с других ваших главных узлов будет продолжать обрабатывать назначения IP.
Ресурсы:
Изменить: отвечая на вопрос во втором комментарии. Сначала вам нужно купить доменное имя (от godaddy, bigrock, AWS Route53 и т. Д.). Во-вторых, создайте CNAME, чтобы указать это доменное имя на IP-адрес вашего балансировщика нагрузки (с портом по желанию) (в вашем случае IP-адреса office-1,2,3 могут использоваться циклически, чтобы обеспечить время безотказной работы). Этот круговой алгоритм называется Балансировка нагрузки DNS. Или вы можете реализовать Отказоустойчивость DNS как в AWS Route53, реализовав проверку работоспособности в балансировщике нагрузки. После этого внешний пользователь по-прежнему будет иметь доступ к сервисам в кубернетах (из офисов-2 и 3).