Configurei 3 nós mestres e 6 nós de trabalho usando o mesmo segmento IP, 172.26.10.XX.
Para serviços de balanceador de carga, estou usando o Kube-Vip para balanceador de carga com especificações de namespace de configuração conforme abaixo: -
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
Quando tento expor um LB de serviço com IP 172.26.10.XX, consigo acessar o cluster de entrada/saída sem problemas. Mas quando venho expor um serviço com IPs LB 172.26.16.XX e 172.26.14.XX, posso acessá-los apenas nos nós do cluster e não fora do cluster. Algo errado? Todos os conselhos são apreciados.
Observado:
K8S: v1.27.7 + k3s2 KUBE-VIP: 0.6.4 Regras de firewall: Permitir/Todas as comunicações de servidor para servidor com segmento Ips 172.26.10.XX, 172.26.16.XX e 172.26.14.XX
Reinicie todos os nós e verifique a configuração do firewall.
Espero que o LB possa navegar em endereços IP com segmentos de IP diferentes.
Responder1
Problema
172.26.16.0 é uma sub-rede diferente de 172.26.10.0/27. Os hosts dentro do cluster terão informações de roteamento para a sub-rede 172.26.16.0, pois o kube-vip adiciona as rotas corretas. Os hosts fora do cluster não saberão onde encontrar essa sub-rede, a menos que sejam informados especificamente (algo está atualizando suas rotas). Para hosts sem rota, eles usarão a rota padrão, que geralmente é um roteador na rede. Se esse roteador não souber onde encontrar 172.26.16.0, ele descartará os pacotes ou os encaminharáisso éRota Padrão.
Quando você usa um IP dentro da sub-rede com a qual os hosts estão configurados, outros hosts verão que estão enviando informações para um host na mesma rede e usarão o ARP para procurar o endereço MAC do destino e enviar quadros para esse hospedar.
Você pode examinar essas tabelas de roteamento em nós dentro e fora do cluster
ip route show table all
tldr; você precisa de um roteador para cruzar redes. Seus nós do Kubernetes atuam como roteadores e é por isso que a comunicação funciona de dentro do cluster
Solução
Provavelmente o mais fácil é usar IPs que fazem parte da sub-rede do host se você quiser que hosts fora do cluster possam acessar os IPs. Por exemplo, se seus hosts estiverem na sub-rede 172.26.10.0/27, use 172.26.10.24/29 (0,24 - 0,31) para seus VIPs.
Outra opção; configurar rotas estáticas em hosts fora do Kubernetes que lhes digam que podem encontrar a rede VIP usando os nós do Kubernetes como gateway. Se seus nós forem 172.26.10.1, .2, .3, então os hosts fora de k8s teriam uma rota como172.26.16.0/24 via 172.26.10.1
Outra opção; configure rotas nos hosts do roteador fora do uso do k8s e faça com que o roteador envie o tráfego para a rede VIP de volta (seu roteador provavelmente precisará de um endereço IP para cada sub-rede configurada na mesma interface)
Outra opção; adicione IPs secundários a cada host fora do k8s que esteja na mesma sub-rede que os VIPs do balanceador de carga.
Outra opção; configure um protocolo de roteamento como RIP ou OSPF para que hosts fora do k8s possam aprender sobre redes dentro do cluster k8s (alguns CNIs fazem isso como Calico com BGP)