He configurado 3 nodos maestros y 6 nodos trabajadores usando el mismo segmento de IP, 172.26.10.XX.
Para los servicios del balanceador de carga, estoy usando Kube-Vip para el balanceador de carga con los detalles del espacio de nombres de configuración como se muestra a continuación: -
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
Cuando intento exponer un servicio LB con IP 172.26.10.XX, puedo acceder al clúster de entrada/salida sin problemas. Pero cuando vengo a exponer un servicio con las IP de LB 172.26.16.XX y 172.26.14.XX, solo puedo acceder a ellos en los nodos del clúster y no fuera del clúster. ¿Ocurre algo? Se agradecen todos los consejos.
Anotado:
K8S: v1.27.7+k3s2 KUBE-VIP: 0.6.4 Reglas de firewall: Permitir/Todas las comunicaciones de servidor a servidor con segmento Ips 172.26.10.XX, 172.26.16.XX y 172.26.14.XX
Reinicie todos los nodos y verifique la configuración del firewall.
Espero que el LB pueda navegar por direcciones IP con diferentes segmentos de IP.
Respuesta1
Problema
172.26.16.0 es una subred diferente a 172.26.10.0/27. Los hosts dentro del clúster tendrán información de enrutamiento para la subred 172.26.16.0 ya que kube-vip agrega las rutas correctas. Los hosts fuera del clúster no sabrán dónde encontrar esta subred a menos que se les indique específicamente (algo está actualizando sus rutas). Para los hosts a los que les falta una ruta, utilizarán la ruta predeterminada, que generalmente es un enrutador en la red. Si ese enrutador no sabe dónde encontrar 172.26.16.0, descartará los paquetes o los enrutará.esRuta por defecto.
Cuando usa una IP dentro de la subred con la que están configurados los hosts, otros hosts verán que están enviando información a un host en la misma red y usarán ARP para buscar la dirección MAC del destino y enviarle tramas. anfitrión.
Puede examinar estas tablas de enrutamiento en nodos dentro y fuera del clúster.
ip route show table all
tldr; necesita un enrutador para cruzar entre redes. Sus nodos de Kubernetes actúan como enrutadores, por eso la comunicación funciona desde el interior del clúster.
Solución
Probablemente lo más fácil sea utilizar IP que formen parte de la subred del host si desea que los hosts fuera del clúster puedan acceder a las IP. Por ejemplo, si sus hosts están en la subred 172.26.10.0/27, use 172.26.10.24/29 (.24 - .31) para sus VIP.
Otra opción; configure rutas estáticas en hosts fuera de Kubernetes que les indiquen que pueden encontrar la red VIP utilizando los nodos de Kubernetes como puerta de enlace. Si sus nodos son 172.26.10.1, .2, .3, entonces los hosts fuera de k8 tendrían una ruta como172.26.16.0/24 via 172.26.10.1
Otra opción; configure rutas en los hosts del enrutador fuera del uso de k8 y haga que el enrutador envíe tráfico a la red VIP nuevamente (su enrutador probablemente necesitará una dirección IP para cada subred configurada en la misma interfaz)
Otra opción; agregue IP secundarias a cada host fuera de k8 que esté en la misma subred que los VIP del equilibrador de carga.
Otra opción; configure un protocolo de enrutamiento como RIP u OSPF para que los hosts externos a k8 puedan conocer las redes dentro del clúster de k8 (algunos CNI hacen esto como Calico con BGP)