Neste documento, mostramos como configurar o Google Distributed Cloud para usar o balanceamento de carga em pacote com o balanceador de carga do MetalLB.
No Google Distributed Cloud, o MetalLB é executado no modo Layer-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 parte a seguir de um arquivo de configuração do cluster de administrador mostra a configuração vista no diagrama anterior:
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 parte de um arquivo de configuração de cluster de usuário mostra a configuração de:
Pool de endereços para o controlador do MetalLB escolher e atribuir aos Serviços do tipo
LoadBalancer. O VIP de entrada está nesse 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 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ário, o controlador do MetalLB escolhe um
endereço IP desse pool.
user-cluster-ipblock.yaml
O exemplo a seguir de um arquivo de bloco de IP mostra a designação dos endereços IP para os nós de trabalho no cluster de usuário. Isso inclui um endereço IP extra para usar durante upgrades, atualizações e reparos automáticos do cluster.
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 gerencia endereços IP para os Serviços. Portanto, quando um desenvolvedor de aplicativos cria um Serviço do tipo LoadBalancer em um cluster de usuário, não é necessário especificar manualmente um endereço IP para o Serviço. Em vez disso, o controlador MetalLB escolhe um endereço IP de um pool de endereços especificado no momento da criação do cluster.
Pense em quantos Serviços do tipo LoadBalancer provavelmente estarão ativos no
cluster de usuário ao mesmo tempo. Em seguida, na seção
loadBalancer.metalLB.addressPools
do
arquivo de configuração do cluster de usuário, especifique endereços IP suficientes para acomodar
esses Serviços.
O VIP de entrada do cluster de usuário precisa estar entre os endereços especificados em um pool de endereços. Isso ocorre porque o proxy de entrada é exposto por um Serviço do tipo LoadBalancer.
Se os desenvolvedores de aplicativos não precisarem criar Serviços do tipo LoadBalancer, não será necessário especificar endereços diferentes do VIP de entrada.
Os endereços precisam estar no formato CIDR ou de intervalo. Se quiser 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
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.
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. 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. 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. 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.