Por que "Dead loop on virtual device gw_11cbf51a, fix it urgently" ocorre de forma intermitente quando fazer logon em uma VM usando o VNC?
Sintoma
Em um cluster que usa o modelo de rede da VPC, a mensagem "Dead loop on virtual device gw_11cbf51a, fix it urgently" é exibida após o logon na VM.
Causa
O modelo de rede da VPC usa o módulo Linux IPvlan de código aberto para redes de contêineres. No modo IPvlan L2E, o encaminhamento de camada 2 é preferencialmente realizado e, em seguida, o encaminhamento de camada 3.
Reprodução de cena
Suponha que haja um pod de serviço A, que fornece serviços externamente e é constantemente acessado pelo nó no qual você faz logon por meio da porta do gateway do contêiner por meio do Serviço do Kubernetes do host. Outro cenário pode ser que os pods nesse nó acessem diretamente uns aos outros. Quando o pod A sair devido a upgrade, dimensionamento ou outros motivos, e os recursos de rede correspondentes forem recuperados, se o nó ainda tentar enviar pacotes para o endereço IP do pod A, o módulo IPvlan no kernel primeiro tenta encaminhar esses pacotes na Camada 2 com base no endereço IP de destino. No entanto, como a NIC ao qual o pod A endereço IP pertence não pode mais ser encontrado, o módulo IPvlan determina que o pacote pode ser um pacote externo. Portanto, o módulo tenta encaminhar o pacote na Camada 3 e combina a porta de gateway com base na regra de roteamento. Depois que a porta de gateway recebe o pacote novamente, ela encaminha o pacote através do módulo IPvlan e esse processo se repete. A função dev_queue_xmit no kernel detecta que o pacote é enviado repetidamente por 10 vezes. Como resultado, o pacote é descartado e esse log foi gerado.
Depois que um pacote é perdido, o iniciador de acesso geralmente executa tentativas de retrocesso por várias vezes. Portanto, vários logs são impressos até que o ARP no contêiner do iniciador de acesso envelheça ou o serviço termine o acesso.
Para comunicação entre contêineres em diferentes nós, os endereços IP de destino e de origem não pertencem à mesma sub-rede dedicada no nível do nó (observe que essa sub-rede é diferente da sub-rede da VPC). Portanto, os pacotes não serão enviados repetidamente e esse problema não ocorrerá.
Os pods em diferentes nós no mesmo cluster podem ser acessados por meio de um Serviço do NodePort. No entanto, o endereço IP do Serviço do NodePort é traduzido no endereço IP da interface de gateway do contêiner acessado pela SNAT, que pode gerar os logs que você vê acima.
Impacto
A execução normal do contêiner acessado não é afetada. Quando um contêiner é destruído, há um leve impacto que os pacotes são enviados repetidamente por 10 vezes e depois descartados. Esse processo é rápido no kernel e tem pouco impacto no desempenho.
Se o ARP envelhecer, o serviço não tentar novamente ou um novo contêiner for iniciado, os pacotes de serviço do contêiner serão redirecionados para o novo serviço por meio de kube-proxy.
Manuseio na comunidade de código aberto
Atualmente, esse problema ainda existe na comunidade quando o modo IPvlan L2E é usado. O problema foi relatado à comunidade para uma melhor solução.
Solução
O problema do loop inativo não precisa ser resolvido.
No entanto, recomenda-se que o pod de serviço saia graciosamente. Antes de o serviço ser encerrado, defina o pod para o estado de exclusão. Depois que o processamento do serviço for concluído, o pod sairá.
