Configure o balanceamento de carga integrado com o MetalLB

Esta página descreve como configurar o equilíbrio de carga agrupado com o MetalLB para o Google Distributed Cloud. Os balanceadores de carga do MetalLB são executados num conjunto dedicado de nós de trabalho ou nos mesmos nós que o plano de controlo.

Consulte a vista geral dos balanceadores de carga para ver exemplos de topologias de balanceamento de carga disponíveis no Google Distributed Cloud.

Requisitos

  • Todos os nós do equilibrador de carga têm de estar na mesma sub-rede da camada 2.
  • Todos os VIPs têm de estar na sub-rede dos nós do equilibrador de carga e ser encaminháveis através do gateway da sub-rede.
  • O gateway da sub-rede do balanceador de carga tem de ouvir mensagens ARP gratuitas e encaminhar pacotes ARP para os nós do balanceador de carga.

Campos de configuração

Edite a secção cluster.spec.loadBalancer do ficheiro de configuração do cluster para configurar o equilíbrio de carga agrupado. Para obter informações sobre ficheiros de configuração de clusters e exemplos de configurações válidas, consulte uma das seguintes páginas:

loadBalancer.mode

Este valor tem de ser bundled para ativar o equilíbrio de carga agrupado.

loadBalancer.ports.controlPlaneLBPort

Este valor especifica a porta de destino a usar para o tráfego enviado para o plano de controlo do Kubernetes (os servidores da API Kubernetes).

loadBalancer.vips.controlPlaneVIP

Este valor especifica o endereço IP de destino a usar para o tráfego enviado para o plano de controlo do Kubernetes (os servidores da API Kubernetes). Este endereço IP tem de estar na mesma sub-rede da camada 2 que os nós no cluster. Não liste este endereço na secção address pools do ficheiro de configuração.

loadBalancer.vips.ingressVIP

Este valor especifica o endereço IP a usar para os serviços atrás do balanceador de carga para tráfego de entrada. Este campo não é permitido em ficheiros de configuração de admin cluster. Este endereço tem de ser apresentado na secção address pools da configuração.

loadBalancer.addressPools

Esta secção da configuração contém um ou mais conjuntos de endereços. Cada conjunto de endereços especifica uma lista de intervalos de endereços IP. Quando cria um serviço do tipo LoadBalancer, os endereços IP externos do serviço são escolhidos a partir destes intervalos.

Os conjuntos de endereços são especificados no seguinte formato:

- name: POOL_NAME
  avoidBuggyIPs: BOOLEAN
  manualAssign: BOOLEAN
  addresses:
  - IP_RANGE
  - IP_RANGE2
  • name: o nome do conjunto de endereços, pool-name, para os seus próprios fins organizacionais. Este campo é imutável.
  • avoidBuggyIPs: (Opcional) true ou false. Se true, o conjunto omite endereços IP que terminam em .0 e .255. Alguns hardwares de rede eliminam o tráfego para estes endereços especiais. Pode omitir este campo. O valor predefinido é false. Este campo é mutável.
  • manualAssign: (Opcional) true ou false. Se true, os endereços neste conjunto não são atribuídos automaticamente aos serviços do Kubernetes. Se true, é usado um endereço IP neste conjunto apenas quando é especificado explicitamente por um serviço. Pode omitir este campo. O valor predefinido é false. Este campo é mutável.
  • addresses Uma lista de um ou mais intervalos de endereços IP não sobrepostos. ip-range pode ser especificado na notação CIDR (como 198.51.100.0/24) ou na notação de intervalo (como 198.51.100.0-198.51.100.10, sem espaços à volta do traço). Este campo é imutável.

Os intervalos de endereços IP na lista addresses não podem sobrepor-se e têm de estar na mesma sub-rede que os nós que executam equilibradores de carga.

loadBalancer.nodePoolSpec

Esta secção da configuração especifica uma lista de nós para executar equilibradores de carga. Por predefinição, os nós do equilibrador de carga podem executar cargas de trabalho normais. Não existe nenhuma restrição especial nesses nós. Embora os nós no node pool do equilibrador de carga possam executar cargas de trabalho, estão separados dos nós nos node pools de nós trabalhadores. Não pode incluir um determinado nó de cluster em mais do que um conjunto de nós. Os endereços IP dos nós sobrepostos entre os conjuntos de nós bloqueiam a criação de clusters e outras operações de clusters.

Se quiser impedir que as cargas de trabalho sejam executadas num nó no conjunto de nós do balanceador de carga, adicione a seguinte mancha ao nó:

node-role.kubernetes.io/load-balancer:NoSchedule

O Google Distributed Cloud adiciona tolerâncias para esta mancha aos pods necessários para o equilíbrio de carga.

O exemplo seguinte mostra um conjunto de nós de equilíbrio de carga com dois nós. O primeiro nó tem um endereço IP padrão nodePoolSpec.nodes.address ("1.2.3.4") e um endereço IP do Kubernetes nodePoolSpec.nodes.k8sIP (10.0.0.32). Quando especifica o endereço k8sIP opcional para um nó, este é dedicado ao processamento do tráfego de dados do nó, como pedidos e respostas para a API Kubernetes, o kubelet e as cargas de trabalho. Neste caso, o endereço IP padrão nodePoolSpec.nodes.address é usado para ligações SSH ao nó para operações administrativas de cluster. Se não especificar um endereço k8sIP, o endereço IP do nó padrão processa todo o tráfego do nó.

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 10.0.0.32
  - address: 10.0.0.33

Por predefinição, todos os nós no conjunto de nós do equilibrador de carga têm de estar na mesma sub-rede da camada 2 que os VIPs do equilibrador de carga configurados na secção loadBalancer.addressPools do ficheiro de configuração. No entanto, se especificar um endereço IP do Kubernetes k8sIP para um nó, apenas esse endereço tem de estar na mesma sub-rede da camada 2 que os outros VIPs do equilibrador de carga.

Se nodePoolSpec não estiver definido, os equilibradores de carga incluídos são executados nos nós do plano de controlo. Recomendamos que execute equilibradores de carga em node pools separados, se possível.

Balanceamento de carga do plano de controlo

O balanceador de carga do plano de controlo publica o endereço IP virtual (VIP) do plano de controlo. O Google Distributed Cloud executa o Keepalived e o HAProxy como pods estáticos do Kubernetes nos nós do balanceador de carga para anunciar o VIP do plano de controlo. O Keepalived usa o Protocolo de redundância do router virtual (VRRP) nos nós do balanceador de carga para alta disponibilidade.

Balanceamento de carga do plano de dados

O balanceador de carga do plano de dados destina-se a todos os serviços do Kubernetes do tipo LoadBalancer. O Google Distributed Cloud usa o MetalLB em execução no modo de camada 2 para o equilíbrio de carga do plano de dados. O equilíbrio de carga do plano de dados só pode ser configurado através do Google Distributed Cloud. Não modifique o ConfigMap do MetalLB diretamente. Pode usar todas as funcionalidades do MetalLB, incluindo a partilha de endereços IP entre serviços. Consulte a documentação do MetalLB para ver informações sobre funcionalidades.

O MetalLB executa um pod de altifalante em cada nó através de um daemonset, usando memberlist para alta disponibilidade. Existe um nó de balanceador de carga dedicado do MetalLB para cada serviço do Kubernetes, em vez de um para todo o cluster. Desta forma, o tráfego é distribuído pelos nós do balanceador de carga se existirem vários serviços.

Os equilibradores de carga do plano de dados podem ser executados nos nós do plano de controlo ou num subconjunto de nós de trabalho. A união de equilibradores de carga do plano de dados nos nós do plano de controlo aumenta a utilização dos nós do plano de controlo. Além disso, a união nos nós do plano de controlo também aumenta o risco de sobrecarga do plano de controlo e aumenta o perfil de risco das informações confidenciais no plano de controlo, como as chaves SSH.

Separação do balanceador de carga

Antes da versão 1.32, quando configura o equilíbrio de carga da camada 2 com o MetalLB, os equilibradores de carga do plano de controlo e os equilibradores de carga do plano de dados são executados nos mesmos nós. Consoante a sua configuração, todos os balanceadores de carga são executados nos nós do plano de controlo ou todos são executados no conjunto de nós do balanceador de carga.

O diagrama seguinte mostra a configuração predefinida do balanceador de carga incluído com os balanceadores de carga do plano de controlo e do plano de dados a serem executados nos nós do plano de controlo ou ambos a serem executados no conjunto de nós do balanceador de carga:

Configuração do balanceador de carga predefinido

Com os clusters da versão 1.32, pode configurar os balanceadores de carga do plano de controlo para serem executados nos nós do plano de controlo e os balanceadores de carga do plano de dados para serem executados no conjunto de nós do balanceador de carga. Pode especificar esta separação de balanceadores de carga quando cria um novo cluster da versão 1.32 ou pode atualizar um cluster da versão 1.32 para migrar os balanceadores de carga do plano de dados dos nós do plano de controlo para o conjunto de nós do balanceador de carga.

A configuração do cluster para balanceadores de carga separados deve ter um aspeto semelhante ao do seguinte exemplo:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha-lb
  namespace: cluster-hybrid-ha-lb
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.33
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    loadBalancer:
      mode: bundled
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  loadBalancer:
    mode: bundled
    ...
    nodePoolSpec:
      nodes:
      - address: 10.200.0.5
      - address: 10.200.0.6
      - address: 10.200.0.7
  clusterOperations:
  ...

Separe os balanceadores de carga ao criar um cluster

Se estiver a criar um novo cluster da versão 1.32 ou superior, pode configurar os balanceadores de carga para executar os balanceadores de carga do plano de controlo nos nós do plano de controlo e os balanceadores de carga do plano de dados no conjunto de nós do balanceador de carga.

O diagrama seguinte mostra os balanceadores de carga do plano de controlo e do plano de dados separados em nós diferentes:

Balanceadores de carga do plano de controlo e do plano de dados separados

Para separar os equilibradores de carga quando cria um cluster, siga os passos seguintes:

  1. No ficheiro de configuração do cluster, especifique um node pool do equilibrador de carga com loadBalancer.nodePoolSpec, conforme descrito na secção loadBalancer.nodePoolSpec deste documento.

  2. Adicione controlPlane.loadBalancer.mode ao ficheiro de configuração do cluster e defina o valor mode como bundled.

  3. Conclua a configuração do cluster e execute bmctl create cluster para criar o cluster.

Migre os equilibradores de carga do plano de dados para fora do plano de controlo

Se tiver um cluster existente com a versão 1.32 ou superior em que nem controlPlane.loadBalancer.mode nem loadBalancer.nodePoolSpec estão definidos, o balanceador de carga do painel de controlo e o balanceador de carga do plano de dados são executados no conjunto de nós do painel de controlo. Pode atualizar o cluster para migrar o balanceador de carga do plano de dados para um node pool do balanceador de carga.

O diagrama seguinte mostra os balanceadores de carga do plano de controlo e do plano de dados separados após a migração do balanceador de carga do plano de dados dos nós do plano de controlo:

Balanceador de carga do plano de dados migrado para o conjunto de nós do balanceador de carga

Para migrar o balanceador de carga do plano de dados para um conjunto de nós do balanceador de carga quando atualiza um cluster, siga estes passos:

  1. No ficheiro de configuração do cluster, especifique um node pool do equilibrador de carga com loadBalancer.nodePoolSpec, conforme descrito na secção loadBalancer.nodePoolSpec deste documento.

  2. Adicione controlPlane.loadBalancer.mode ao ficheiro de configuração do cluster e defina o valor mode como bundled.

  3. Atualize o cluster executando o seguinte comando:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que está a atualizar.

    • ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

Preservar o endereço IP de origem do cliente

O serviço criado com a solução de balanceamento de carga de camada 2 incluída usa a predefinição Cluster para a política de tráfego externo.LoadBalancer Esta definição, spec.externalTrafficPolicy: Cluster, encaminha o tráfego externo para os pontos finais ao nível do cluster, mas também oculta o endereço IP de origem do cliente.

O Google Distributed Cloud suporta dois métodos para preservar o endereço IP de origem do cliente:

  • Defina o modo de encaminhamento para o balanceamento de carga como Direct Server Return (DSR). Para mais informações acerca do modo de encaminhamento DSR, incluindo instruções para o ativar, consulte o artigo Configure o modo de encaminhamento do equilíbrio de carga.

  • Defina a política de tráfego externo como local para o LoadBalancerserviço e configure os serviços e a entrada relacionados em conformidade. As secções seguintes descrevem como configurar o cluster para usar este método.

LoadBalancer serviços

Quando usar os serviços externalTrafficPolicy: Local nos seus serviços LoadBalancer, defina os pods da aplicação para serem executados exatamente nos nós do equilibrador de carga. Adicione o seguinte nodeSelector aos pods da aplicação para fazer esta alteração:

apiVersion: v1
kind: Pod
...
spec:
  nodeSelector:
      baremetal.cluster.gke.io/lbnode: "true"
...

NodePort serviços

O Kubernetes faz a tradução de endereços de rede de origem (SNAT) para NodePort serviços. Para reter os endereços IP de origem do cliente, defina service.spec.externalTrafficPolicy como Local. O Kubernetes já não executa o SNAT, mas tem de se certificar de que existem pods em execução exatamente no IP do nó que escolheu.

Entrada

Se as suas aplicações forem serviços HTTP, pode alcançar a visibilidade do IP do cliente configurando componentes de entrada:

  1. Abra o istio-ingress serviço para edição:

    kubectl edit service -n gke-system istio-ingress

  2. Adicione externalTrafficPolicy: Local ao spec, guarde e saia do editor.

    apiVersion: v1
kind: Service
...
spec:
...
  externalTrafficPolicy: Local

  3. Abra a istio-ingress implementação para edição:

    kubectl edit deployment -n gke-system istio-ingress

  4. Adicione o seguinte nodeSelector à implementação, guarde e saia do editor.

    apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
          baremetal.cluster.gke.io/lbnode: "true"
...

Agora, todos os seus serviços atrás do Ingress veem um cabeçalho X-Forwarded-For com o IP do cliente, como no exemplo seguinte:

X-Forwarded-For: 21.0.104.4