Em ambientes de infraestrutura baseados em arquitetura ARM64, é comum a utilização de clonagem de máquinas virtuais para agilizar o provisionamento de nós em um cluster Kubernetes. No entanto, essa prática pode introduzir problemas críticos na camada de rede (Overlay), especificamente quando o Flannel é utilizado como CNI (Container Network Enterface). O sintoma mais comum é a impossibilidade de comunicação entre Pods localizados em nós distintos do cluster.

Identificação do Problema

Ao implementar um cluster em instâncias clonadas, a interface virtual flannel.1 (utilizada para o encapsulamento VXLAN) pode acabar retendo o mesmo endereço MAC em todos os nós. Isso ocorre devido a políticas de persistência de identificadores de rede no sistema operacional de origem que são replicadas durante o processo de clonagem.

Para diagnosticar, pode-se utilizar um DaemonSet de teste para validar a conectividade entre os nós:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: debug-network-checker
  labels:
    app: net-check
spec:
  selector:
    matchLabels:
      app: net-check
  template:
    metadata:
      labels:
        app: net-check
    spec:
      containers:
      - name: nginx-node
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-net-check
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: net-check

Se ao tentar realizar um curl do endereço IP de um Pod residente no Nó A a partir do Nó B a requisição falhar (timeout), o próximo passo é verificar os endereços MAC das interfaces de rede:

# Executar em todos os nós
ip link show flannel.1

Se o campo link/ether exibir o mesmo endereço hexadecimal em múltiplos servidores, o tráfego VXLAN não será roteado corretamente pelo switch virtual, causando a perda de pacotes entre os nós.

Procedimento de Correção

A solução consiste em forçar o sistema operacional a não herdar ou gerar endereços MAC estáticos para a interface do Flannel, permiitndo que o Kubernetes gerencie essa atribuição de forma única por nó. Deve-se aplicar os seguintes passos em todos os nós do cluster:

1. Configurar a Política de Link do Systemd

Crie um arquivo de configuração para o systemd-networkd que defina a política de endereço MAC como nula para a interface específica do Flannel:

printf "[Match]\nOriginalName=flannel.1\n\n[Link]\nMACAddressPolicy=none\n" > /etc/systemd/network/10-flannel.1.link

2. Remover a Interface Conflituosa

Para que a nova política entre em vigor, a interface virtual atual deve ser removida manualmente:

ip link delete flannel.1

3. Reiniciar o Agente de Rede

Após a remoção da interface, é necessário reiniciar o Pod do Flannel para que ele recrie o dispositivo de rede com os parâmetros corretos. Identifique e delete o Pod correspondente ao nó:

# Localize o nome do pod no namespace kube-system
kubectl get pods -n kube-system -l app=flannel -o wide

# Delete o pod para forçar o reinício
kubectl delete pod <nome-do-pod-flannel> -n kube-system

Validação Final

Após o reinício do CNI, verifique se o novo endereço MAC da interface flannel.1 coincide com o que o Kubernetes registrou no objeto node:

kubectl get node <nome-do-no> -o yaml | grep flannel.alpha.coreos.com/backend-data

Compare o valor da chave VtepMAC no output acima com o resultado de ip link show flannel.1 no host físico. Com os endereços MAC normalizados e únicos por host, a comunicação entre Pods em diferentes nós deverá ser restabelecida imediataemnte.