Я настроил 3 главных и 6 рабочих узлов, используя один и тот же сегмент IP, 172.26.10.XX.
Для служб балансировки нагрузки я использую Kube-Vip со следующими параметрами конфигурации пространства имен: -
Data
====
cidr-private-app:
----
172.26.10.XX/27
range-global:
----
172.26.16.XX-172.26.16.XX
range-public-app:
----
172.26.14.XX-172.26.14.XX
BinaryData
Когда я пытаюсь выставить сервис LB с IP 172.26.10.XX, я могу получить доступ к кластеру in/out без проблем. Но когда я пытаюсь выставить сервис с IP LB 172.26.16.XX и 172.26.14.XX, я могу получить к ним доступ только в узлах кластера, а не за его пределами. Что-то не так? Все советы приветствуются.
Отмеченный:
K8S: v1.27.7+k3s2 KUBE-VIP: 0.6.4 Правила брандмауэра: Разрешить/Все соединения сервера с сервером с сегментом IP 172.26.10.XX, 172.26.16.XX и 172.26.14.XX
Перезагрузите все узлы и проверьте конфигурацию брандмауэра.
Я ожидаю, что LB сможет просматривать IP-адреса с другим сегментом IP.
решение1
Проблема
172.26.16.0 — это другая подсеть, нежели 172.26.10.0/27. Хосты внутри кластера будут иметь информацию о маршрутизации для подсети 172.26.16.0, поскольку kube-vip добавляет правильные маршруты. Хосты вне кластера не будут знать, где найти эту подсеть, если им не будет указано специально (что-то обновляет их маршруты). Для хостов, у которых отсутствует маршрут, они будут использовать маршрут по умолчанию, который обычно является маршрутизатором в сети. Если этот маршрутизатор не знает, где найти 172.26.16.0, он либо отбросит пакеты, либо направит их наружуегомаршрут по умолчанию.
При использовании IP-адреса внутри подсети, настроенной для хостов, другие хосты увидят, что они отправляют информацию хосту в той же сети, и будут использовать ARP для поиска MAC-адреса назначения и отправки кадров на этот хост.
Вы можете проверить эти таблицы маршрутизации на узлах внутри и вне кластера.
ip route show table all
tldr; вам нужен маршрутизатор для перехода между сетями. Ваши узлы Kubernetes действуют как маршрутизаторы, поэтому связь работает изнутри кластера
Решение
Вероятно, проще всего использовать IP-адреса, которые являются частью подсети хоста, если вы хотите, чтобы хосты за пределами кластера могли получить доступ к IP-адресам. Например, если ваши хосты находятся в подсети 172.26.10.0/27, используйте 172.26.10.24/29 (.24 - .31) для ваших VIP-адресов.
Другой вариант: настроить статические маршруты на хостах за пределами Kubernetes, которые сообщат им, что они могут найти сеть VIP, используя узлы Kubernetes в качестве шлюза. Если ваши узлы 172.26.10.1, .2, .3, то хосты за пределами k8s будут иметь маршрут типа172.26.16.0/24 via 172.26.10.1
Другой вариант: настроить маршруты на хостах маршрутизатора, которые находятся за пределами использования k8s, и заставить маршрутизатор отправлять трафик обратно в сеть VIP (вашему маршрутизатору, вероятно, понадобится IP-адрес для каждой подсети, настроенной на том же интерфейсе)
Другой вариант: добавьте вторичные IP-адреса к каждому хосту за пределами k8s, который находится в той же подсети, что и VIP-адреса балансировщика нагрузки.
Другой вариант: настроить протокол маршрутизации, например RIP или OSPF, чтобы хосты за пределами k8s могли узнать о сетях внутри кластера k8s (некоторые CNI делают это, например, Calico с BGP).