Este documento mostra como configurar o Google Distributed Cloud para usar o equilíbrio de carga integrado com o equilibrador de carga MetalLB. Este documento destina-se a especialistas em redes que concebem e arquitetam a rede para a respetiva organização, e instalam, configuram e suportam equipamento de rede. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulteFunções e tarefas comuns do utilizador do GKE.
No Google Distributed Cloud, o MetalLB é executado no modo de camada 2.
Exemplo de uma configuração do MetalLB
Segue-se um exemplo de uma configuração para clusters que executam o balanceador de carga MetalLB:
O diagrama anterior mostra uma implementação do MetalLB. O MetalLB é executado diretamente nos nós do cluster. Neste exemplo, o cluster de administrador e o cluster de utilizador estão em duas VLANs separadas, e cada cluster está numa sub-rede separada:
| Cluster | Sub-rede |
|---|---|
| Cluster de administrador | 172.16.20.0/24 |
| Cluster de utilizadores | 172.16.40.0/24 |
admin-cluster.yaml
A parte seguinte de um ficheiro de configuração do cluster de administrador mostra a configuração vista no diagrama anterior de:
Plano de controlo 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 parte seguinte de um ficheiro de configuração do cluster de utilizadores mostra a configuração de:
Intervalo de endereços para o controlador MetalLB escolher e atribuir a serviços do tipo
LoadBalancer. O VIP de entrada está neste conjunto.O VIP designado para o servidor da API Kubernetes do cluster de utilizadores e o VIP de entrada que escolheu configurar para o proxy de entrada.
Um node pool ativado para usar o MetalLB. O MetalLB vai ser implementado nos nós neste conjunto 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 programador de aplicações cria um serviço do tipo
LoadBalancer no cluster de utilizadores, o controlador MetalLB escolhe um
endereço IP deste conjunto.
user-cluster-ipblock.yaml
O exemplo seguinte de um ficheiro de bloqueio de IP mostra a designação de endereços IP para os nós de trabalho no cluster de utilizadores. Isto inclui um endereço IP adicional para usar durante as atualizações, as atualizações e a reparação automática 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
Configure o MetalLB
Abra portas da firewall
O MetalLB usa a
biblioteca Go memberlist
para fazer a eleição do líder. A biblioteca memberlist usa a porta TCP 7946 e a porta UDP 7946 para trocar informações. Certifique-se de que essas portas estão acessíveis para tráfego de entrada e
saída em todos os nós do equilibrador de carga.
Ative o MetalLB para um novo cluster de administrador
No
ficheiro de configuração do cluster de administrador,
defina loadBalancer.kind como "MetalLB".
loadBalancer: kind: "MetalLB"
Preencha o resto do ficheiro de configuração do cluster de administrador e crie o cluster de administrador conforme descrito em Criar um cluster de administrador.
Especifique conjuntos de endereços
O controlador MetalLB atribui endereços IP para serviços. Quando um programador de aplicações cria um serviço do tipo LoadBalancer num cluster de utilizadores, o controlador MetalLB atribui automaticamente um endereço IP para o serviço. O controlador MetalLB seleciona um endereço IP de um conjunto de endereços que especificar.
Para garantir que o cluster de utilizadores tem 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 secção loadBalancer.metalLB.addressPools do ficheiro de configuração do cluster de utilizadores.
As moradas no conjunto têm de estar no formato CIDR ou no formato de intervalo. Para especificar um endereço individual, use um CIDR./32 Por exemplo:
addresses:
- "192.0.2.0/26"
- "192.0.2.64-192.0.2.72"
- "192.0.2.75/32"
Se precisar de ajustar os endereços num conjunto depois de criar o cluster, pode usar gkectl update cluster. Para mais informações, consulte o artigo Atualize o MetalLB.
Ative o MetalLB para um novo cluster de utilizadores
No ficheiro de configuração do cluster de utilizadores:
- Defina
loadBalancer.kindcomo"MetalLB". - Especifique um ou mais conjuntos de endereços para os serviços. O VIP de entrada tem de estar num destes conjuntos.
Defina
enableLoadBalancercomotruepara, pelo menos, um conjunto de nós no seu cluster. Quando definido comotrue, este campo permite que o altifalante do MetalLB seja executado nos nós no conjunto.Tenha em atenção as seguintes diferenças no comportamento do campo
enableLoadBalancerquandoenableAdvancedClusterestá definido comotrue(cluster avançado ativado): na versão 1.31, quando o cluster avançado está ativado, este campo não tem efeito porque o altifalante MetalLB é sempre executado nos nós do plano de controlo do cluster de utilizador. Na versão 1.32, quando o cluster avançado está ativado, esta limitação foi removida e tem de especificar, pelo menos, um conjunto de nós no qual o altifalante do MetalLB é executado.
Preencha o resto do ficheiro de configuração do cluster de utilizadores e crie o cluster de utilizadores conforme descrito em Crie um cluster de utilizadores.
Atribuição manual de moradas de serviço
Se não quiser que o controlador MetalLB atribua automaticamente endereços IP de um conjunto específico aos serviços, defina o campo manualAssign do conjunto como true. Em seguida, um programador pode criar um serviço do tipo LoadBalancer
e especificar manualmente um dos endereços do conjunto. Por exemplo:
loadBalancer:
metalLB:
addressPools:
- name: "my-address-pool-2"
addresses:
- "192.0.2.73-192.0.2.80"
manualAssign: true
Evitar endereços IP com erros
Se definir o campo avoidBuggyIPs de um conjunto de endereços como true, o controlador do MetalLB não usa endereços do conjunto que terminam em .0 ou .255. Isto evita o problema de dispositivos de consumo com erros que rejeitam por engano 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
Seguem-se dois manifestos: um para uma implementaçã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
Repare que o manifesto do serviço não especifica um endereço IP externo. O controlador MetalLB escolhe um endereço IP externo do conjunto de endereços que especificou no ficheiro de configuração do cluster de utilizadores.
Guarde os manifestos num ficheiro com o nome my-dep-svc.yaml. Em seguida, crie os objetos Deployment e Service:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f my-dep-svc.yaml
Ver 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 conjunto de endereços que especificou no ficheiro de configuração do cluster de utilizadores. Por exemplo, 192.0.2.2 está neste conjunto de endereços:
metalLB:
addressPools:
- name: "address-pool-1"
addresses:
- "192.0.2.0/24"
- "198.51.100.1-198.51.100.3"
Ligue para o serviço:
curl EXTERNAL_IP_ADDRESS:60000
O resultado apresenta a mensagem Hello, world!:
Hello, world! Version: 2.0.0
Atualize o MetalLB
Depois de criar o cluster, pode atualizar os conjuntos de endereços do MetalLB e o campo enableLoadBalancer nos conjuntos de nós. Faça as alterações pretendidas no ficheiro de configuração do cluster de utilizadores e, de seguida, chame gkectl update cluster:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONIFG --config USER_CLUSTER_CONFIG
Pods do MetalLB e ConfigMap
O controlador MetalLB é executado como uma implementação e o altifalante MetalLB é executado como um DaemonSet em nós em pools que têm enableLoadBalancer definido como true. O controlador MetalLB gere os endereços IP atribuídos aos serviços. O MetalLB
speaker faz a eleição de líder e anuncia os VIPs de serviço.
Ver todos os pods do MetalLB:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get pods --namespace kube-system --selector app=metallb
Pode usar os registos dos pods do MetalLB para a resolução de problemas.
A configuração do MetalLB é armazenada num ConfigMap num formato conhecido pelo MetalLB.
Não altere o ConfigMap diretamente. Em alternativa, use gkectl update cluster, conforme descrito anteriormente. Para ver o ConfigMap para resolução de problemas:
kubectl --kubeconfig USER_CLUSTER_KUBECONIFG get configmap metallb-config --namespace kube-system
Vantagens da utilização do MetalLB
O MetalLB é executado diretamente nos nós do cluster, pelo que não requer VMs adicionais.
O controlador MetalLB faz a gestão de endereços IP para os serviços, pelo que não tem de escolher manualmente um endereço IP para cada serviço.
As instâncias ativas do MetalLB para diferentes serviços podem ser executadas em nós diferentes.
Pode partilhar um endereço IP entre diferentes serviços.
Comparação entre o MetalLB e o F5 BIG-IP e o Seesaw
Os IPs virtuais têm de estar na mesma sub-rede que os nós do cluster. Isto também é um requisito para o Seesaw, mas não para o F5 BIG-IP.
Não existem métricas para o tráfego.
Não existe uma comutação por falha sem interrupções; as ligações existentes são repostas durante a comutação por falha.
O tráfego externo para os agrupamentos de um determinado serviço passa por um único nó que executa o altifalante do MetalLB. Isto significa que o endereço IP do cliente normalmente não é visível para os contentores em execução no pod.
- A infraestrutura centrada na aplicação (ACI) da Cisco com a aprendizagem de IP do plano de dados é incompatível com os balanceadores de carga Seesaw e MetalLB. Recomendamos que use o equilíbrio de carga manual ou desative a aprendizagem de IP do plano de dados quando usar o Seesaw ou o MetalLB como equilibrador de carga. Além disso, o Seesaw está no modo de manutenção. A partir da versão 1.32 do Google Distributed Cloud, as atualizações estão bloqueadas para clusters que usam o Seesaw. Tem de migrar os clusters para as funcionalidades recomendadas antes de atualizar para a versão 1.32.