Configurar o balanceamento de carga em pacote

Nesta página, descrevemos como configurar o balanceamento de carga agrupado para clusters do Anthos no bare metal. Os clusters do Anthos em bare metal implantam balanceadores de carga da camada 4 que são executados em um pool de nós de trabalho dedicado ou nos mesmos nós do plano de controle.

Consulte Visão geral dos balanceadores de carga para exemplos de topologias de balanceamento de carga disponíveis no Anthos em Bare Metal.

Requisitos

  • Todos os nós do balanceador de carga precisam estar na mesma sub-rede da camada 2.
  • Todos os VIPs precisam estar na sub-rede de nós do balanceador de carga e ser roteado por meio do gateway da sub-rede.
  • O gateway da sub-rede do balanceador de carga precisa ouvir mensagens ARP gratuitas e encaminhar pacotes ARP para os nós do balanceador de carga.

Campos de configuração

Edite a seção cluster.spec.loadBalancer do arquivo de configuração do cluster para configurar o balanceamento de carga agrupado. Para informações sobre arquivos de configuração de cluster e exemplos de configurações válidas. consulte uma das seguintes páginas:

loadBalancer.mode

Este valor precisa ser bundled para ativar o balanceamento de carga em pacote.

loadBalancer.ports.controlPlaneLBPort

Esse valor especifica a porta de destino a ser usada no tráfego enviado ao plano de controle do Kubernetes (os servidores da API Kubernetes).

loadBalancer.vips.controlPlaneVIP

Esse valor especifica o endereço IP de destino a ser usado para o tráfego enviado ao plano de controle do Kubernetes (os servidores da API Kubernetes). Esse endereço IP precisa estar na mesma sub-rede da camada 2 que os nós que executam balanceadores de carga. Não liste esse endereço na seção address pools do arquivo de configuração.

loadBalancer.vips.ingressVIP

Esse valor especifica o endereço IP a ser usado para serviços atrás do balanceador de carga para o tráfego de entrada. Este campo não é permitido em arquivos de configuração do cluster de administrador. Esse endereço precisa ser listado na seção de pools de endereços da configuração.

loadBalancer.addressPools

Esta seção da configuração contém um ou mais pools de endereços especificados neste formato:

- name: pool-name
  avoidBuggyIPs: boolean
  manualAssign: boolean
  addresses:
  - ip-range
  - ip-range
  • name: o nome do pool de endereços, pool-name, para seus fins organizacionais.
  • avoidBuggyIPs (opcional): true ou false. Se true, o pool omitirá endereços IP terminados em .0 e .255. Alguns hardwares de rede descartam tráfego para esses endereços especiais. É possível omitir esse campo. O valor padrão dele é false.
  • manualAssign (opcional): true ou false. Se true, os endereços neste pool não serão atribuídos automaticamente aos serviços do Kubernetes. Se true, um endereço IP nesse pool só será usado quando for especificado explicitamente por um serviço. É possível omitir esse campo. O valor padrão dele é "false".
  • endereços: 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 ao redor do travessão).

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

loadBalancer.nodePoolSpec

Nesta seção da configuração, é especificada uma lista de nós em que os balanceadores de carga serão executados. Os nós do balanceador de carga podem executar cargas de trabalho regulares por padrão. não há taints especiais nesses nós. O exemplo abaixo mostra um pool de nós com dois nós. O primeiro nó, 1.2.3.4, usa o campo k8sIP para especificar o endereço IP do nó no cluster. O endereço 1.2.3.4 é usado apenas para acesso SSH.

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

Todos os nós no pool de nós do balanceador de carga precisam estar na mesma sub-rede de camada 2 que os VIPs do balanceador de carga configurados na seção loadBalancer.addressPools do arquivo de configuração. Se um nó tiver um k8sIP configurado, somente esse endereço precisará estar na mesma sub-rede da camada 2 que os outros VIPs do balanceador de carga.

Se nodePoolSpec não estiver definido, os balanceadores de carga em pacote serão executados nos nós do plano de controle. Recomendamos executar balanceadores de carga em pools de nós separados, se possível.

Balanceamento de carga do plano de controle

O balanceador de carga desse plano de controle disponibiliza o endereço IP virtual (VIP, na sigla em inglês) do plano de controle. Os clusters do Anthos em Bare Metal executam Keepalived e HAProxy como pods estáticos do Kubernetes nos nós do balanceador de carga para anunciar o VIP do plano de controle. O Keepalived usa o protocolo de redundância de roteador 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 é para todos os Serviços do Kubernetes do tipo LoadBalancer. Os clusters do Anthos em bare metal usam o MetalLB em execução no modo de camada 2 para balanceamento de carga do plano de dados. O balanceamento de carga do plano de dados só pode ser configurado por meio de clusters do Anthos no bare metal, não modifica o ConfigMap do MetalLL diretamente. É possível usar todos os recursos do MetalLB, incluindo compartilhamento de endereço IP entre os serviços. Consulte a documentação do MetalLB para obter informações sobre os recursos.

O MetalLB executa um pod de alto-falante em cada nó usando um daemonset, usando memberlist para alta disponibilidade. Há um nó de balanceador de carga dedicado do MetalLB para cada serviço do Kubernetes, em vez de um para todo o cluster. Dessa forma, o tráfego será distribuído entre nós do balanceador de carga se houver vários serviços.

Os balanceadores de carga do plano de dados podem ser executados nos nós do plano de controle ou em um subconjunto de nós de trabalho. A divisão de balanceadores de carga do plano de dados nos nós do plano de controle aumenta a utilização dos nós do plano de controle. No entanto, a divisão nos nós do plano de controle também aumenta o risco de sobrecarregá-lo e aumenta o perfil de risco de informações confidenciais no plano de controle, como as chaves SSH.

Como preservar o endereço IP da origem do cliente

O serviço LoadBalancer criado com a solução de balanceamento de carga em lote de camada 2 usa a configuração Cluster padrão para a política de tráfego externo. Essa configuração, spec.externalTrafficPolicy: Cluster, direciona o tráfego externo para os endpoints de todo o cluster, mas também oculta o endereço IP da origem do cliente.

As seções a seguir descrevem como configurar o cluster para preservar o endereço IP da origem do cliente.

NodePort serviço

O Kubernetes faz a conversão de endereços de rede (NAT, na sigla em inglês) de origem para os serviços NodePort. Para manter os endereços IP de origem do cliente, defina service.spec.externalTrafficPolicy como Local. O Kubernetes não executará mais a NAT de origem, mas você precisa garantir que haja pods em execução exatamente no IP do nó escolhido.

LoadBalancer serviço

Ao usar externalTrafficPolicy: Local nos serviços LoadBalancer, defina os pods do aplicativo para serem executados exatamente nos nós do balanceador de carga. Adicione o nodeSelector a seguir aos pods do aplicativo para fazer a mudança:

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

Entrada

Se os aplicativos forem serviços HTTP, é possível conseguir a visibilidade IP do cliente configurando componentes de entrada:

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

    kubectl edit service -n gke-system istio-ingress

  2. Adicione externalTrafficPolicy: Local a spec, salve e saia do editor.

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

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

    kubectl edit deployment -n gke-system istio-ingress

  4. Adicione o nodeSelector a seguir à implantação, salve 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 por trás do Ingress veem um cabeçalho X-Forwarded-For com o IP do cliente, como o exemplo a seguir:

X-Forwarded-For: 21.0.104.4