Os clusters do Anthos em bare metal agora são o Google Distributed Cloud (somente software) em bare metal. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

Configurar balanceamento de carga em pacote com o MetalLB

Nesta página, descrevemos como configurar o balanceamento de carga em pacote com o MetalLB para Google Distributed Cloud. Os balanceadores de carga do MetalLB são executados em um pool dedicado de nós de trabalho ou nos mesmos nós do plano de controle.

Consulte a Visão geral dos balanceadores de carga para exemplos de topologias de balanceamento de carga disponíveis no Google Distributed Cloud.

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 no cluster. 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. Cada pool de endereços especifica uma lista de intervalos de endereços IP. Quando você cria um Serviço do tipo LoadBalancer, os endereços IP externos do Serviço são escolhidos nesses intervalos.

Os pools de endereços são especificados no formato a seguir:

- name: POOL_NAME
  avoidBuggyIPs: BOOLEAN
  manualAssign: BOOLEAN
  addresses:
  - IP_RANGE
  - IP_RANGE2

name: o nome do pool de endereços,pool-name , para seus fins organizacionais. Este campo não pode ser modificado.
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. Este campo pode ser modificado.
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. Este campo pode ser modificado.
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 ao redor do travessão). Este campo não pode ser modificado.

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. Embora os nós no pool de nós do balanceador de carga podem executar cargas de trabalho, elas são separadas dos nós nos pools de nós de trabalho. Você não pode incluir um determinado nó de cluster em mais de um pool de nós. Nó sobreposto Endereços IP entre pools de nós bloqueiam a criação de clusters e outros clusters operações.

Se você quiser impedir que cargas de trabalho sejam executadas em um nó no balanceador de carga pool de nós, adicione o seguinte taint ao nó:

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

O Google Distributed Cloud adiciona tolerâncias desse taint aos pods necessários para balanceamento de carga.

O exemplo a seguir mostra um pool de nós de balanceamento 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 você especifica o endereço k8sIP opcional para um nó, ele é dedicado ao processamento de tráfego de dados para o nó, como solicitações e respostas para a API Kubernetes, o kubelet e as cargas de trabalho. Nesse caso, o endereço IP padrão nodePoolSpec.nodes.address é usado para conexões SSH com o nó para operações administrativas do cluster. Se você não especificar um endereço k8sIP, o endereço IP padrão do nó processará todo o tráfego dele.

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

Por padrão, 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. No entanto, se você especificar um endereço IP k8sIP do Kubernetes para um nó, somente esse endereço precisará estar na mesma sub-rede de 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 no sistema 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. O Google Distributed Cloud executa o Keepa Pesquisa e o GCE como pods estáticos do Kubernetes na os 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. O Google Distributed Cloud usa MetalLB em execução no modo de Camada 2 para balanceamento de carga do plano de dados. Balanceamento de carga do plano de dados só pode ser configurado usando o Google Distributed Cloud, não modifique o MetalLB ConfigMap 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. Além disso, 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.

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

Defina o modo de encaminhamento do balanceamento de carga como retorno direto do servidor (DSR). Para mais informações sobre o modo de encaminhamento do DSR, incluindo instruções para ativar, consulte Configurar o modo de encaminhamento do balanceamento de carga.
Defina a política de tráfego externa como local para o serviço LoadBalancer e configure os serviços e Entrada relacionados de acordo. As seções a seguir descrevem como configurar o cluster para usar esse método.

Serviços de `LoadBalancer`

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"
...

Serviços de `NodePort`

O Kubernetes faz a conversão de endereços de rede (SNAT) 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 SNAT, mas você precisa garantir que haja pods em execução exatamente no IP do nó escolhido.

Entrada

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

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

kubectl edit service -n gke-system istio-ingress

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

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

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

kubectl edit deployment -n gke-system istio-ingress

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