Version 1.14. This version is no longer supported. For more information see the version support policy.

Balanceamento de carga em pacote com o MetalLB

Neste documento, mostramos como configurar o GKE no VMware para usar o balanceamento de carga em pacote com o balanceador de carga MetalLB.

No GKE no VMware, 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:

Configuração do balanceador de carga MetalLB. — Configuração do balanceador de carga MetalLB (clique para ampliar)

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

O seguinte exemplo de um arquivo de configuração do cluster de administrador mostra a configuração vista no diagrama anterior de:

Balanceador de carga MetalLB
VIPs no servidor de API MetalLB para Kubernetes e complementos do cluster de administrador

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/admin-cluster-ipblock.yaml"
...

loadBalancer:
  kind: "MetalLB"
  ...

  vips:
    controlPlaneVIP: "172.16.20.100"
    addonsVIP: "172.16.20.101"

admin-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 administrador. Isso também inclui o endereço do nó do plano de controle do cluster de usuário e um endereço IP a ser usado durante o upgrade do cluster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.20.1"
  ips:
  - ip: 172.16.20.50
    hostname: admin-vm-1
  - ip: 172.16.20.51
    hostname: admin-vm-2
  - ip: 172.16.20.52
    hostname: admin-vm-3
  - ip: 172.16.20.53
    hostname: admin-vm-4
  - ip: 172.16.20.54
    hostname: admin-vm-5

user-cluster.yaml

O seguinte exemplo de um arquivo de configuração do cluster de usuário mostra a configuração de:

Pools de endereços para o controlador MetalLB escolher e atribuir a Serviços do tipo LoadBalancer. O VIP de entrada está em um desses pools.
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. O VIP do servidor da API Kubernetes está na sub-rede do cluster de administrador porque o plano de controle de um cluster de usuário é executado em um nó no cluster de administrador.
Um pool de nós ativado para usar MetalLB. O MetalLB será implantado nos nós no cluster de usuário que pertencem a esse pool de nós.

network:
  hostConfig:
  ...

  ipMode:
    type: "static"
    ipBlockFilePath: "config-folder/user-cluster-ipblock.yaml"
...

loadBalancer:
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.40.100/32"
      - "172.16.40.101-172.16.40.112
      avoidBuggyIPs: true
  ...

  vips:
    controlPlaneVIP: "172.16.20.102"
    ingressVIP: "172.16.40.102"
...

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 deste 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 a ser usado durante o upgrade do cluster.

blocks:
- netmask: "255.255.255.0"
  gateway: "17.16.40.1"
  ips:
  - ip: 172.16.40.21
    hostname: user-vm-1
  - ip: 172.16.40.22
    hostname: user-vm-2
  - ip: 172.16.40.23
    hostname: user-vm-3
  - ip: 172.16.40.24
    hostname: user-vm-4
  - ip: 172.16.40.25
    hostname: user-vm-5

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.kind como "MetalLB".
Especifique um ou mais pools de endereços para Serviços. O VIP de entrada precisa estar em um desses pools.
Defina enableLoadBalancer como true para 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.