Nesta página, descrevemos como configurar o balanceamento de carga em pacote com o MetalLB para GDCV para Bare Metal. 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 ver exemplos de topologias de balanceamento de carga disponíveis em GDCV para 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:
- Criar clusters de administrador
- Criar clusters de usuários
- Criar clusters híbridos
- Criar clusters independentes
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
oufalse
. Setrue
, 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
oufalse
. Setrue
, os endereços neste pool não serão atribuídos automaticamente aos serviços do Kubernetes. Se fortrue
, um endereço IP nesse pool será usado somente 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 (como198.51.100.0/24
) ou na notação de intervalo (como198.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. 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. O GDCV para Bare Metal executa o Keepa deslocar e o GCE 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
.
O GDCV para Bare Metal usa MetalLB
em execução no modo Camada 2 para balanceamento de carga do plano de dados. O balanceamento de carga do plano de dados
só pode ser configurado por GDCV para Bare Metal. Não modifique o ConfigMap
do MetalLB 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:
Abra o serviço
istio-ingress
para edição:kubectl edit service -n gke-system istio-ingress
Adicione
externalTrafficPolicy: Local
aspec
, 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