<p>o tráfego de nó cruzado de flanela não funciona com o systemd 242 mais recente devido a uma corrida</p>

Comportamento esperado

O tráfego de pod entre nós deve funcionar, o tráfego de nó para pod deve funcionar entre nós.

Comportamento atual

Ao executar o flannel com o systemd 242+, parece haver uma condição de corrida entre o flannel programando o endereço mac da interface flannel.1 e o systemd programando o endereço mac na interface virtual. Isso resulta em todo o tráfego de nó cruzado sendo descartado na camada 2 no nó de destino devido ao mac vtep de destino incorreto.

Com o systemd 242, a política padrão é configurada para ser MACAddressPolicy=persistent

/usr/lib/systemd/network/99-default.link

[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent

Quando o flannel abre a interface, ele programa o endereço mac e o systemd o reprograma novamente.

No rastreamento abaixo você verá

clear@clr-02 ~ $ ip addr show flannel.1
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether d6:02:e3:df:ea:7a brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever

Mas as tabelas arp em nós remotos são configuradas com um endereço mac diferente d6:02:e3:df:ea:7a vs 5e:89:db:49:c6:a4

clear@clr-01 ~ $ ip neigh
10.244.1.0 dev flannel.1 lladdr 5e:89:db:49:c6:a4 PERMANENT

Observando os rastreamentos do netlink, você vê o endereço mac sendo alterado duas vezes, a primeira vez por flanela e a segunda vez para um endereço diferente pelo systemd com base em sua política padrão

clear@clr-02 ~ $ sudo ip monitor all
[NETCONF]inet flannel.1 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
[NETCONF]inet6 flannel.1 forwarding off proxy_neigh off ignore_routes_with_linkdown off
[LINK]4: flannel.1: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default
    link/ether 5e:89:db:49:c6:a4 brd ff:ff:ff:ff:ff:ff
[LINK]4: flannel.1: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default
    link/ether d6:02:e3:df:ea:7a brd ff:ff:ff:ff:ff:ff
[ADDR]4: flannel.1    inet 10.244.1.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever

Solução possível

• O usuário pode configurar uma política de endereço mac específica de MACAddressPolicy=none na interface flanela* em cada sistema que oculta o problema, mas requer alterações no nível do nó
  ou
• Flannel pode observar alterações de endereço mac no link e reprogramar

Etapas para reproduzir (para bugs)

1. kubeadm init
2. kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
3. Ping pod no nó remoto

Contexto

Flannel e quaisquer plugins de rede baseados em flanela param de funcionar com o systemd 242 (Canal).
Isso afetará outras distribuições quando elas atualizarem para o systemd 242 e além.

Seu ambiente

• Versão de flanela: https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
• Backend usado (por exemplo, vxlan ou udp): vxlan
• Versão do Kubernetes (se usado): Kubernetes v1.14.3
• Sistema operacional e versão:
  Clearlinux 4.19.53-53.lts2018 com
  sistema 242 (242)
  +PAM +AUDIT -SELINUX +IMA -APPARMOR -SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 -IDN -PCRE2 hierarquia padrão=legado
• Link para seu projeto (opcional): https://github.com/clearlinux/cloud-native-setup