Como criar um balanceador de carga interno / privado no mecanismo de cálculo do google

Question

Eu tenho dois clusters. O cluster A (no mecanismo de contêiner do Google) é um cluster voltado ao público e precisa se conectar a um cluster privado B (um cluster de clique para implantação no GCE) para acessar um serviço. Eu gostaria de ter o Cluster A conectado ao Cluster B por meio de um balanceador de carga, e isso pode funcionar mesmo que pareça que todos os balanceadores de carga do GCE exigem um endereço IP público link (eu preferiria que fosse tudo privado).

O endereço IP público não é tão ruim por si só se você puder definir apenas uma regra de firewall simples e usar o Google Load Balancer padrão. Infelizmente, as tags de origem não parecem cruzar o limite da WAN (ou simplesmente não são passadas pelo balanceador de carga). Esta é a regra que eu gostaria de usar:

gcloud compute firewall-rules create servicename-lb-from-gke-cluster --allow tcp:1234 --source-tags k8s-gke-cluster-node --target-tags servicename #DOES NOT WORK

Depois de inserir o comando acima, o Cluster A não pode se comunicar com o Cluster B (via balanceador de carga) pela porta tcp 1234.

Isso funciona, mas é doloroso porque requer supervisão para automatizar a configuração dos endereços IP públicos do cluster de origem:

gcloud compute firewall-rules create servicename-lb-from-gke-cluster --allow tcp:1234 --source-ranges 100.2.3.4/32 100.3.5.9/32 100.9.1.2/32 --target-tags servicename #Does work, but is painful

Como sugerido no tópico Grupos do Google, o proxy HA é outra sugestão.

Outra idéia é abrir o firewall para toda a WAN e adicionar autenticação segura entre o cluster A e B. Talvez seja uma boa ideia fazer isso por razões de segurança, de qualquer maneira? A dificuldade pode variar de fácil a difícil, dependendo do que o cluster A e B estão executando embora - pode ser bom ter uma solução mais geral.

Alguém tem uma ideia melhor? Alguém mais tem o mesmo problema?

    

Answer 1

Isso agora é possível com o LB interno oficial do GCP: link

Especificamente, aqui está a documentação do kubernetes (GKE): link

Anote a anotação de serviço:

  annotations:
    cloud.google.com/load-balancer-type: "Internal"

Observe que, embora essa LB já seja acessível apenas internamente, se você quiser restringir ainda mais, por exemplo, seus pods de cluster, você poderia fazer algo assim:

loadBalancerSourceRanges: 10.4.0.0/14

Para obter seu intervalo de IPs de pod, você pode executar: gcloud container clusters describe $CLUSTER_NAME |grep clusterIpv4Cidr

    

Answer 2

Sinto muito pela complexidade! Não sou especialista em firewalls do Compute Engine, mas espero que você esteja correto quanto às limitações das tags de origem para trabalhar apenas para tráfego interno.

A equipe do Kubernetes está ciente de que é difícil coordenar vários clusters e estamos começando a trabalhar em soluções, mas infelizmente não temos nada particularmente sólido e útil para você ainda.

Nesse meio tempo, há um jeito hacker de balancear a carga do tráfego de um cluster para outro sem exigir o Google Cloud Load Balancer ou algo parecido com o haproxy. Você pode especificar o endereço IP interno de um dos nós no cluster B (ou o IP de uma rota GCE que direciona o tráfego para um dos nós no cluster B) no campo PublicIPs do serviço com o qual você deseja conversar. Em seguida, o cluster A envia suas solicitações para esse IP na porta do serviço e elas serão equilibradas em todos os pods que suportam o serviço.

Ele deve funcionar porque há algo chamado kube-proxy em execução em cada nó do cluster do kubernetes, que faz proxy automaticamente do tráfego destinado ao IP e porta de um serviço para os pods que suportam o serviço. Contanto que o PublicIP esteja na definição de serviço, o kube-proxy irá equilibrar o tráfego para você.

Se você parar aqui, isso é tão confiável quanto o nó para o qual o IP está enviando tráfego (mas a confiabilidade de nó único é realmente muito alta). No entanto, se você quiser ficar realmente chique, podemos tornar as coisas um pouco mais confiáveis, pelo balanceamento de carga do cluster A em todos os nós do cluster B.

Para fazer isso funcionar, você colocaria todos os IPs internos dos nós do cluster B (ou rotas para todos os IPs internos dos nós) no campo PublicIPs do seu serviço. Em seguida, no cluster A, você poderia criar um serviço separado com um seletor de rótulo vazio e preencher o campo de pontos de extremidade manualmente ao criá-lo com um par (IP, porta) para cada IP no cluster B. O seletor de rótulo vazio impede a infra-estrutura do kubernetes substitui seus terminais inseridos manualmente e os proxies kube no cluster A farão o balanceamento de carga do tráfego para o serviço entre os IPs do cluster B. Isso foi possível graças ao PR # 2450 , se você quiser mais contexto.

Deixe-me saber se você precisa de mais ajuda com isso!