Estou executando o metallb há mais de um ano, mas depois de uma atualização malfeita, reinstalei tudo do zero. Depois de reinstalar o metallb, ele conseguiu atribuir IPs externos aos serviços, mas esses serviços estavam inacessíveis. Em uma inspeção mais aprofundada, vi que o alto-falante não estava respondendo a solicitações ARP, e pesquisei mais e vi que o endereço IP nunca foi vinculado à interface de rede do nó. Quando vinculei o endereço IP manualmente executando ip addr add 192.168.1.29/24 dev enp10s0, o endereço imediatamente começou a funcionar e consegui acessar o serviço.
Não tenho certeza do porquê isso não está sendo vinculado automaticamente, presumo que o alto-falante deva estar fazendo isso? Meu ambiente é um cluster Talos 1.9.4 de 2 nós executando o kubernetes 1.32.2. Usando uma instalação nova do metallb 0.14.9 com helm e todos os valores padrão, adicionei o seguinte l2advertisement e ipaddresspool:
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: default
spec:
addresses:
- 192.168.1.20-192.168.1.99
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: default
namespace: metallb
spec:
ipAddressPools:
- default
Estou usando versões bem avançadas do kubernetes e do metallb, então possivelmente é um bug? Estou olhando o código do alto-falante no GitHub, mas não falo golang
Acontece que o metallb não vincula o endereço à interface normalmente, embora no meu caso isso tenha feito o nó responder às solicitações ARP, o que não estava correto.
O problema na verdade acabou sendo muito mais simples. Versões mais recentes do Talos adicionam o
node.kubernetes.io/exclude-from-external-load-balancersrótulo para controlar nós de plano automaticamente, o que excluiu o metallb de rodar em qualquer um dos meus nós prontos para uso.A solução é remover os rótulos ou adicionar
.speaker.ignoreExcludeLB=trueao helm values.yaml