Implementar o MetalLB em clusters Kubernetes Bare Metal exige uma compreensão profunda de como o balanceamento de carga interage com a infraestrutura de rede física. Este guia detalha estratégias avançadas para diagnóstico de falhas, monitoramento proativo e gerenciamento de ciclo de vida em ambientes de produção.

Diagnóstico de Falhas e Resolução de Incidentes

Abaixo, exploramos os cenários de erro mais frequentes e as etapas sistemáticas para restaurar a disponibilidade do serviço.

Erros na Alocação de IPs

Quando um Service permanece com o status Pending no campo LoadBalancer IP, o problema geralmente reside no controlador do MetalLB ou na definição dos pools de endereços.

Validação de Configuração Estática

O MetalLB valida as configurações recebidas. Se houver um erro de sintaxe ou lógica, ele manterá a última configuração válida (stale). Para verificar erros no parser:

# Inspeção de logs do controlador em busca de erros de parsing
kubectl logs -n metallb-system -l app.kubernetes.io/component=controller | grep -Ei "error|invalid|failed"

# Verificação do status do recurso IPAddressPool
kubectl describe ipaddresspools.metallb.io -n metallb-system

Causas comuns incluem sobreposição de faixas de IP ou seletores de etiquetas (labels) que não coincidem com os serviços criados.

Falhas no Anúncio de Rotas (Speaker)

O componente speaker é responsável por informar à rede física onde o IP do LoadBalancer está localizado. Se o IP foi atribuído, mas não há conectividade externa, o problema está no anúncio.

Cenário de Camada 2 (L2)

No modo L2, o MetalLB responde a requisições ARP/NDP. Problemas comuns envolvem proteções de rede como "MAC Spoofing protection" em switches virtuais ou físicos.

# Teste de resposta ARP para o IP do LoadBalancer
arping -I eth0 <IP_DO_LOADBALANCER>

# Monitoramento de eventos ARP no pod speaker
kubectl logs -n metallb-system -l app.kubernetes.io/component=speaker -c speaker | grep "ARP"

Cenário BGP (Camada 3)

No modo BGP, a falha geralmente ocorre na sessão entre o nó do Kubernetes e o roteador de borda.

1. Status da Sessão: Verifique se o peering está em estado Established.
2. Propagação de Prefixos: Confirme se os prefixos estão sendo enviados ao vizinho.

# Verificação de vizinhos BGP em implementações baseadas em FRR
kubectl exec -it -n metallb-system <NOME_DO_POD_SPEAKER> -c frr -- vtysh -c "show bgp summary"

# Visualização das rotas anunciadas
kubectl exec -it -n metallb-system <NOME_DO_POD_SPEAKER> -c frr -- vtysh -c "show ip bgp neighbor <IP_DO_ROTEADOR> advertised-routes"

Observabilidade e Métricas do Prometheus

O MetalLB expõe métricas detalhadas que permitem a criação de dashboards e alertas inteligentes.

Métricas de Alocação e Sistema

Configuração de Alertas no Prometheus

Um sistema de monitoramento robusto deve alertar sobre quedas de sessão BGP ou exaustão de IPs:

groups:
- name: metallb_alerts
  rules:
  - alert: MetalLBBGPSessionDown
    expr: metallb_bgp_session_up == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      description: "A sessão BGP com o peer {{ $labels.peer }} caiu no nó {{ $labels.instance }}."
  
  - alert: MetalLBIPPoolExhausted
    expr: (metallb_allocator_addresses_in_use_total / metallb_allocator_addresses_total) > 0.90
    for: 5m
    labels:
      severity: warning
    annotations:
      description: "O pool de IPs {{ $labels.pool }} está com mais de 90% de ocupação."

Gestão de Atualizações e Compatibilidade de API

Manter o MetalLB atualizado é essencial para segurança, mas requer atenção às mudanças nas Custom Resource Definitions (CRDs).

Migração de Versão da API

Versões recentes migraram de v1beta1 para v1beta2. Ao atualizar, certifique-se de que seus manifestos refletem a nova estrutura de dados, especialmante para recursos de BGPPeer e IPAddressPool.

# Exemplo de IPAddressPool v1beta1 (Antigo) vs v1beta1 (Novo padrão MetalLB.io)
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: pool-servicos-externos
  namespace: metallb-system
spec:
  addresses:
  - 10.0.50.0/24
  autoAssign: true

Recomenda-se o uso do Helm para gerenciar atualizações, pois ele lida com a ordem correta de atualização dos componentes:

helm upgrade --install metallb metallb/metallb -n metallb-system --wait

Melhores Práticas para Ambientes Produtivos

Para garantir alta disponibilidade e isolamento, adote as seguintes estratégias de arquitetura.

Isolamento de Rede e Segurança

O componente speaker necessita de privilégios elevados (hostNetwork: true). É fundamental restringir seu tráfego via NetworkPolicies para garantir que ele se comunique apenas com os roteadores autorizados.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: permitir-bgp-egress
  namespace: metallb-system
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: speaker
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: <IP_DO_ROTEADOR_BORD>/32
    ports:
    - protocol: TCP
      port: 179

Planejamento de Endereçamento

• Segmentação: Divida os pools de IPs por criticidade (ex: prod-pool, dev-pool).
• BFD (Bidirectional Forwarding Detection): Sempre que possível, utilize perfis BFD para detecção de falhas em milissegundos, superando os timeouts padrão do BGP.
• Seletor de Nós: Se nem todos os nós possuem conectividade com o roteador de borda, use nodeSelectors na configuração do MetalLB para evitar anúncios de rotas por nós "cegos".

Otimização de Recursos

Configure limites de recursos (CPU/Memória) para evitar que o controlador ou os speakers causem instabilidade no nó durante picos de atualização de rotas. O speaker em clusters com centenas de serviços pode demandar mais memória para processar a tabela de rotas do FRR.

# Sugestão de limites para o Speaker em clusters médios
resources:
  requests:
    cpu: 150m
    memory: 200Mi
  limits:
    cpu: 500m
    memory: 512Mi