Neste documento, mostramos como configurar o Google Distributed Cloud para usar o balanceamento de carga em pacote com o balanceador de carga MetalLB. Este documento é destinado a especialistas em redes que projetam e arquitetam a rede para a organização e instalam, configuram e oferecem suporte a equipamentos de rede. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE.
No Google Distributed Cloud, o MetalLB é executado no modo camada 2.
Exemplo de uma configuração MetalLB
Veja um exemplo de configuração para clusters que executam o balanceador de carga MetalLB:
O diagrama anterior mostra uma implantação MetalLB. O MetalLB é executado diretamente nos nós do cluster. Neste exemplo, o cluster de administrador e o cluster de usuário estão em duas VLANs separadas, e cada cluster está em uma sub-rede separada:
| Cluster | Sub-rede |
|---|---|
| Cluster de administrador | 172.16.20.0/24 |
| Cluster de usuário | 172.16.40.0/24 |
admin-cluster.yaml
A seguinte porção de um arquivo de configuração do cluster de administrador mostra a configuração vista no diagrama anterior de:
Plano de controle de alta disponibilidade
Balanceador de carga MetalLB
VIP no MetalLB para o servidor da API Kubernetes do cluster de administrador
network:
...
controlPlaneIPBlock:
netmask: "255.255.255.0"
gateway: "172.16.20.1"
ips:
- ip: "172.16.20.50"
hostname: "admin-cp-1"
- ip: "172.16.20.51"
hostname: "admin-cp-2"
- ip: "172.16.20.52"
hostname: "admin-cp-3"
loadBalancer:
kind: "MetalLB"
...
vips:
controlPlaneVIP: "172.16.20.100"
...
adminMaster:
cpus: 4
memoryMB: 16384
replicas: 3
user-cluster.yaml
A seguinte porção de um arquivo de configuração do cluster de usuário mostra a configuração de:
Pool de endereços para o controlador MetalLB escolher e atribuir a Serviços do tipo
LoadBalancer. O VIP de entrada está neste pool.VIP designado para o servidor da API Kubernetes do cluster de usuário e o VIP de entrada que você escolheu configurar para o proxy de entrada.
Um pool de nós ativado para usar MetalLB. O MetalLB será implantado nos nós desse pool de nós.
enableControlplaneV2: true
...
network:
hostConfig:
...
ipMode:
type: "static"
ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...
controlPlaneIPBlock:
netmask: "255.255.255.0"
gateway: "172.16.40.1"
ips:
- ip: "172.16.40.21"
hostname: "user-cp"
loadBalancer:
kind: MetalLB
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "172.16.40.101-172.16.40.112
avoidBuggyIPs: true
...
vips:
controlPlaneVIP: "172.16.20.100"
ingressVIP: "172.16.40.101"
...
nodePools:
- name: "node-pool-1"
cpus: 4
memoryMB: 8192
replicas: 3
enableLoadBalancer: true
A configuração no exemplo anterior especifica um conjunto de endereços disponíveis
para os Serviços. Quando um desenvolvedor de aplicativos cria um serviço do tipo
LoadBalancer no cluster de usuários, o controlador MetalLB escolhe
um endereço IP do pool.
user-cluster-ipblock.yaml
O exemplo a seguir de um arquivo de bloco de IP mostra a designação de endereços IP para os nós no cluster de usuário. Isso inclui um endereço IP extra a ser usado durante upgrades, atualizações e reparos automáticos de clusters.
blocks:
- netmask: "255.255.255.0"
gateway: "17.16.40.1"
ips:
- ip: 172.16.40.22
hostname: user-vm-1
- ip: 172.16.40.23
hostname: user-vm-2
- ip: 172.16.40.24
hostname: user-vm-3
- ip: 172.16.40.25
hostname: user-vm-4
- ip: 172.16.40.26
hostname: user-vm-5
- ip: 172.16.40.27
hostname: user-vm-6
Configurar o MetalLB
Abrir portas de firewall
O MetalLB usa a
biblioteca de membros do Go
para fazer a eleição de líder. A biblioteca memberlist usa a porta TCP 7946 e a porta UDP 7946 para trocar informações. Verifique se essas portas estão acessíveis para o tráfego de entrada e saída em todos os nós do balanceador de carga.
Ativar o MetalLB para um novo cluster de administrador
No arquivo
de configuração do cluster de administrador, defina loadBalancer.kind como "MetalLB":
loadBalancer: kind: "MetalLB"
Preencha o restante do arquivo de configuração do cluster de administrador e crie o cluster de administrador, conforme descrito em Criar um cluster de administrador.
Especificar pools de endereços
O controlador MetalLB atribui endereços IP aos Serviços. Quando um desenvolvedor de aplicativos cria um serviço do tipo LoadBalancer em um cluster de usuários, o controlador MetalLB atribui automaticamente um endereço IP ao serviço. O controlador do MetalLB seleciona um endereço IP de um pool de endereços especificado.
Para garantir que o cluster de usuário tenha endereços IP suficientes, considere o número máximo
de serviços LoadBalancer que provavelmente estarão ativos. Em seguida, especifique endereços IP suficientes na seção loadBalancer.metalLB.addressPools do arquivo de configuração do cluster de usuário.
Os endereços no pool precisam estar no formato CIDR ou de intervalo. Para especificar um
endereço individual, use um CIDR /32. Exemplo:
addresses:
- "192.0.2.0/26"
- "192.0.2.64-192.0.2.72"
- "192.0.2.75/32"
Excluir endereços IP usados para outras finalidades
Não inclua os seguintes endereços IP em nenhum pool de endereços:
VIPs do plano de controle:
Endereços IP do nó do plano de controle:
Endereços IP do gateway:
Endereços IP para serviços:
Endereços IP para pods:
Endereços IP dos nós de trabalho do cluster de usuário
Endereços IP dos servidores vCenter, servidores DNS, servidores NTP e da estação de trabalho do administrador
Se precisar ajustar os endereços em um pool após a criação do cluster, use
gkectl update cluster. Saiba mais em
Atualizar o MetalLB.
Ativar o MetalLB para um novo cluster de usuário
No arquivo de configuração do cluster de usuários:
- Defina
loadBalancer.kindcomo"MetalLB". - Especifique um ou mais pools de endereços para Serviços. O VIP de entrada precisa estar em um desses pools.
Defina
enableLoadBalancercomotruepara pelo menos um pool de nós no cluster. Quando definido comotrue, esse campo permite que o alto-falante do MetalLB seja executado nos nós do pool.Observe as seguintes diferenças no comportamento do campo
enableLoadBalancerquandoenableAdvancedClusteré definido comotrue(cluster avançado ativado): na versão 1.31, quando o cluster avançado está ativado, esse campo não tem efeito porque o speaker do MetalLB sempre é executado nos nós do plano de controle do cluster de usuário. Na versão 1.32, quando o cluster avançado está ativado, essa limitação é removida, e é necessário especificar pelo menos um pool de nós em que o alto-falante do MetalLB é executado.
Preencha o restante do arquivo de configuração do cluster de usuário e crie o cluster de usuário conforme descrito em Criar um cluster de usuário.
Atribuição manual de endereços de Serviço
Se você não quiser que o controlador do MetalLB atribua automaticamente endereços IP
de um pool específico aos Serviços, defina o campo manualAssign do
pool como true. Em seguida, um desenvolvedor pode criar um serviço do tipo LoadBalancer e especificar manualmente um dos endereços do pool. Por exemplo:
loadBalancer:
metalLB:
addressPools:
- name: "my-address-pool-2"
addresses:
- "192.0.2.73-192.0.2.80"
manualAssign: true
Como evitar endereços IP com bugs
Se você definir o campo avoidBuggyIPs de um pool de endereços como true, o controlador MetalLB não usará endereços do pool que terminam em .0 ou .255. Isso
evita o problema de dispositivos com bug de consumo que descartam o tráfego enviado
para esses endereços IP especiais. Por exemplo:
loadBalancer:
metalLB:
addressPools:
- name: "my-address-pool-1"
addresses:
- "192.0.2.0/24"
avoidBuggyIPs: true
Crie um serviço do tipo LoadBalancer
Veja aqui dois manifestos: um para uma implantação e outro para um serviço:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
selector:
matchLabels:
greeting: hello
replicas: 3
template:
metadata:
labels:
greeting: hello
spec:
containers:
- name: hello
image: gcr.io/google-samples/hello-app:2.0
---
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: LoadBalancer
selector:
greeting: hello
ports:
- name: metal-lb-example-port
protocol: TCP
port: 60000
targetPort: 8080
O manifesto do serviço não especifica um endereço IP externo. O controlador MetalLB escolherá um endereço IP externo do pool de endereços especificado no arquivo de configuração do cluster de usuário.
Salve os manifestos em um arquivo chamado my-dep-svc.yaml. Em seguida, crie os objetos de implantação e serviço:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-dep-svc.yaml
Veja o Serviço:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get service my-service --output wide
A saída mostra o endereço IP externo que foi atribuído automaticamente ao serviço. Por exemplo:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR my-service LoadBalancer 10.96.2.166 192.0.2.2 60000:31914/TCP 28s
Verifique se o endereço IP externo atribuído foi retirado do pool de endereços especificado no arquivo de configuração do cluster de usuário. Por exemplo, 192.0.2.2 está neste pool de endereços:
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "192.0.2.0/24"
- "198.51.100.1-198.51.100.3"
Chame o serviço:
curl EXTERNAL_IP_ADDRESS:60000
A saída exibe uma mensagem Hello, world!:
Hello, world! Version: 2.0.0
Atualizar o MetalLB
Depois de criar o cluster, é possível atualizar os pools de endereços do MetalLB e o
campo enableLoadBalancer nos pools de nós. Faça as alterações desejadas no
arquivo de configuração do cluster de usuário e chame gkectl update cluster:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONIFG --config USER_CLUSTER_CONFIG
Pods do MetalLB e ConfigMap
O controlador do MetalLB é executado como uma implantação, e o alto-falante do MetalLB é executado como um
DaemonSet em nós em pools que têm enableLoadBalancer definido como true. O
controlador MetalLB gerencia os endereços IP atribuídos aos serviços. O alto-falante
do MetalLB faz a eleição de líder e anuncia VIPs de serviço.
Veja todos os pods do MetalLB:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get pods --namespace kube-system --selector app=metallb
Use os registros dos pods do MetalLB para resolver problemas.
A configuração do MetalLB é armazenada em um ConfigMap em um formato conhecido pelo MetalLB.
Não altere o ConfigMap diretamente. Em vez disso, use gkectl update cluster, conforme
descrito anteriormente. Para visualizar o ConfigMap para a solução de problemas:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get configmap metallb-config --namespace kube-system
Benefícios do uso do MetalLB
O MetalLB é executado diretamente nos nós do cluster, de modo que não requer VMs extras.
O controlador MetalLB gerencia serviços de endereços IP para que você não precise escolher manualmente um endereço IP para cada Serviço.
Instâncias ativas do MetalLB para diferentes Serviços podem ser executadas em nós diferentes.
É possível compartilhar um endereço IP entre serviços diferentes.
MetalLB em comparação a F5 BIG-IP e Seesaw
Os VIPs precisam estar na mesma sub-rede que os nós do cluster. Esse também é um requisito para o Seesaw, mas não para o F5 BIG-IP.
Não há métricas para o tráfego.
Não há failover imbatível. as conexões existentes são redefinidas durante o failover.
O tráfego externo para os pods de um determinado Serviço passa por um único nó que executa o alto-falante do MetalLB. Isso significa que o endereço IP do cliente geralmente não é visível para contêineres em execução no pod.
- O Cisco Application Centric Infrastructure (ACI) com aprendizado de plano de dados de IP não é compatível com os balanceadores de carga Seesaw e MetalLB. Recomendamos que você use o balanceamento de carga manual ou desative o aprendizado de IP do plano de dados ao usar o Seesaw ou o MetalLB como balanceador de carga. Além disso, o Seesaw está em modo de manutenção. A partir da versão 1.32 do Google Distributed Cloud, os upgrades são bloqueados para clusters que usam Seesaw. É necessário migrar os clusters para recursos recomendados antes de fazer upgrade para a versão 1.32.