Resolver problemas de rede do Google Distributed Cloud

Esta página mostra como resolver problemas de rede com o Google Distributed Cloud. Incluímos orientações e informações gerais para solução de problemas, além de sugerir ferramentas. As informações de solução de problemas de DNS e alguns problemas comuns do MetalLB também estão incluídos.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Solução de problemas de conectividade de rede

A rede do GKE Enterprise depende da infraestrutura de rede física. Por exemplo, para o MetalLB, os switches precisam respeitam o ARP gratuito; o balanceamento de carga em pacote com o protocolo de gateway de borda (BGP, na sigla em inglês) depende dos roteadores; e todos os nós precisam ser capazes de se comunicar entre eles. Quando você tem um problema de rede nos clusters do GKE, é preciso identificar se o problema está nos componentes do GKE Enterprise ou na sua própria infraestrutura.

Primeiro, determine o escopo do problema e tente identificar os componentes afetados. O escopo de um problema pode ser uma destas três categorias: o assunto (de onde), o destino (para o qual) e a camada da rede

O escopo do assunto pode ser um dos seguintes:

• Todos os nós (ou pod hostNetwork) em todo o cluster.
• Todos os pods em todo o cluster.
• Todos os pods em um único nó ou em um conjunto de nós.
• Todos os pods da mesma implantação ou DaemonSet.
• Cliente de fora do cluster.

O escopo do destino pode ser uma ou mais das seguintes opções:

• Todos os outros endereços IP do pod do mesmo cluster.
• Todos os outros endereços IP do pod do mesmo nó.
• VIP do ClusterIP do mesmo cluster.
• VIP do serviço LoadBalancer do mesmo cluster.
• LoadBalancer de camada de entrada 7 (Istio).
• Outros nós do mesmo cluster.
• Nome do DNS interno (como *.svc.cluster.local).
• Nome do DNS externo (como google.com).
• Entidades de fora do cluster.
• Entidades na Internet.

A camada de rede pode ser uma ou mais das seguintes opções:

• Problemas na camada 2 da camada de links, como sistema vizinho, ARP ou NDP.
• Problemas de roteamento de endereço IP da camada 3.
• Problemas de endpoint TCP ou UDP da camada 4
• Problemas de HTTP ou HTTPS da camada 7.
• Problemas de resolução de DNS.

Compreender o escopo de um problema ajuda a identificar os componentes envolvidos e em qual camada o problema ocorre. É importante coletar informações quando o problema ocorre porque alguns problemas são temporários. Portanto, os snapshots após a recuperação do sistema não incluirão informações suficientes para a análise da causa raiz.

Problemas de entrada

Se o assunto for um cliente de fora do cluster e ele não conseguir se conectar a um serviço LoadBalancer, é um problema de conectividade norte-sul. O diagrama a seguir mostra que, em um exemplo funcional, o tráfego de entrada percorre a pilha da esquerda para a direita, e o de retorno retorna à pilha da direita para a esquerda.

Quando houver um problema com esse fluxo de tráfego, use o fluxograma de solução de problemas a seguir para ajudar a identificar onde está o problema:

Neste fluxograma, as seguintes orientações de solução de problemas ajudam a determinar onde o problema está:

• O pacote sai do cliente? Caso contrário, você provavelmente tem um problema de infraestrutura de rede.
• Você está usando o MetalLB? Em caso afirmativo, o pacote chega ao nó LB e o ARP é enviado corretamente? Caso contrário, você provavelmente tem um problema de infraestrutura de rede.
• Você está usando F5 BIG-IP? Se sim, você verificou se há problemas de F5?
• A conversão de endereços de rede (NAT) foi executada corretamente? Caso contrário, você provavelmente tem um problema com o kube-proxy / Dataplane V2.
• O pacote chega ao nó de trabalho? Caso contrário, você provavelmente tem um problema de pod para pod do Dataplane v2.
• O pacote chega ao pod? Caso contrário, você provavelmente tem um problema de encaminhamento local do Dataplane v2.

Nas seções a seguir, fornecemos etapas para solucionar problemas de cada estágio para determinar se o tráfego flui corretamente ou não.

O pacote sai do cliente?

Verifique se o pacote sai corretamente do cliente e passa pelo roteador que está configurado na infraestrutura de rede física.

1. Use tcpdump para verificar o pacote, porque ele deixa o cliente para o serviço de destino:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Se você não vê o tráfego saindo, essa é a origem do problema.

O pacote chega a um nó do LoadBalancer?

Se você usa o MetalLB como balanceador de carga:

1. Observe o registro metallb-controller para determinar qual nó do balanceador de carga veicula o VIP do serviço:

   kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP
   

2. Conecte-se ao nó usando SSH.

3. Para um nó do MetalLB, use tcpdump para analisar o tráfego:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Para ManualLB, o tráfego pode chegar a qualquer nó. Dependendo da configuração do balanceador de carga, é possível escolher um ou vários nós. Use tcpdump para analisar o tráfego:

   tcpdump -ni any host NODE_IP and port NODE_PORT
   

   O comando é diferente entre os tipos de balanceador de carga, já que o MetalLB não faz NAT antes de encaminhar o pacote para os nós.

   Se não há tráfego entrando em nó algum, essa é a origem do problema.

Há um problema F5 BIG-IP?

Para resolver problemas de F5 BIG-IP, consulte uma das seções a seguir em F5 Service não recebe tráfego.

O ARP foi enviado corretamente?

O nó do balanceador de carga do MetalLB depende do ARP para anunciar o VIP do serviço. Se a resposta do ARP foi enviada corretamente, mas o tráfego não está vindo, isso é um sinal de que há um problema na infraestrutura de rede física. Uma causa comum desse problema é que alguns recursos avançados de aprendizado do plano de dados ignoram a resposta ARP em soluções de rede definida por software (SDN, na sigla em inglês).

1. Use tcpdump para detectar respostas ARP:

   tcpdump -ni any arp
   

   Tente encontrar a mensagem que anuncia o VIP que está com problemas.

2. Para MetalLB, ele não envia ARP gratuito. A frequência de resposta depende de quando outro dispositivo, como um interruptor de parte superior do rack (ToR, na sigla em inglês), envia uma solicitação ARP.

A NAT é realizada?

O Dataplane v2 / kube-proxy executa a conversão de endereços de rede de destino (NAT ou DNAT de destino) para converter o VIP de destino em um endereço IP do pod de back-end. Se você souber qual nó é o back-end do balanceador de carga, conecte-se ao nó usando SSH.

1. Use tcpdump para verificar se o VIP do serviço está traduzido corretamente:

   tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
   

2. Para o Dataplane v2, também é possível se conectar aos pods anetd e usar as ferramentas de depuração incorporadas do Cilium:

   cilium monitor --type=drop
   

Para mais informações, consulte uma das seções a seguir sobre problemas do Dataplane v2 / cilium.

O pacote chega a um nó de trabalho?

Nos nós de trabalho, o pacote chega à interface externa e é entregue aos pods.

1. Use tcpdump para verificar se o pacote chega à interface externa, geralmente chamada de eth0 ou ens192:

   tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
   

Para o Google Distributed Cloud, o pacote é encapsulado em um túnel. Quando o pacote é descapsulado, ele sai de uma interface de rede chamada cilium_geneve.

Como os back-ends de serviço normais contêm vários pods em nós diferentes, pode ser difícil resolver o problema com a falha. Uma solução comum é capturar o problema por tempo suficiente para que algum pacote chegue ou limitar o número de back-ends a um.

Se o pacote nunca chega ao nó de trabalho, é um indicador de um problema de infraestrutura de rede. Verifique com a equipe de infraestrutura de rede para saber por que o pacote é descartado entre os nós do LoadBalancer e os nós de trabalho. Veja alguns problemas comuns:

• Verifique os registros da rede definida por software (SDN). Às vezes, a SDN pode descartar pacotes por vários motivos, como segmentação, soma de verificação incorreta ou antispoofing.
• Regras de firewall que filtram pacotes de genes porta UDP 6081.

Se o pacote chega à interface externa ou de túnel do nó, ele precisa ser encaminhado para o pod de destino. Se o pod for um pod de rede host, esta etapa não será necessária porque o pod compartilha o namespace de rede com o nó. Caso contrário, será necessário encaminhar o pacote adicional.

Cada pod tem pares de interface Ethernet virtual, que funcionam como barras verticais. Um pacote enviado para uma extremidade da interface é recebido da outra extremidade da interface. Uma das interfaces é movida para o namespace de rede do pod e renomeada para eth0. A outra interface é mantida no namespace do host. CNIs diferentes têm esquemas diferentes. No Dataplane v2, a interface normalmente é chamada de lxcxxxx. Os nomes têm números de interface consecutivos, como lxc17 e lxc18. É possível verificar se o pacote chega ao pod usando tcpdump ou também especificar a interface:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Se o pacote chegar ao nó, mas não chegar ao pod, verifique a tabela de roteamento da seguinte maneira:

ip route

Normalmente, cada pod precisa ter uma entrada de roteamento roteando o endereço IP do pod para a interface lxc. Se a entrada estiver ausente, isso normalmente significa que o caminho de dados CNI tem um erro. Para determinar a causa raiz, verifique os registros DaemonSet da CNI.

Problemas de saída

Se o tráfego puder entrar em um pod, você pode ter um problema com o tráfego enquanto ele sai. Os diagramas a seguir mostram que, em um exemplo funcional, o tráfego de entrada viaja pela pilha da esquerda para a direita:

1. Para verificar se o pacote de saída mascara corretamente o endereço IP do nó, verifique o serviço externo (camada 4).

   O endereço IP de origem do pacote precisa ser mapeado do endereço IP do pod para o endereço IP do nó com a tradução do endereço de rede de origem (NAT ou SNAT de origem). No Dataplane v2, esse processo é realizado pelo ebpf carregado em uma interface externa.

   Use tcpdump para verificar se o endereço IP de origem foi convertido corretamente do endereço IP do pod para o endereço do nó:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT
   

   Se tcpdump mostrar que os pacotes estão mascarados corretamente, mas o serviço remoto não responde, verifique a conexão com o serviço externo na infraestrutura.

2. Se os pacotes de saída estiverem corretamente mascarados como o endereço IP do nó, verifique a conectividade do host externo (camada 3) usando tcpdump:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp
   

   Ao mesmo tempo que executa tcpdump, dê um ping em um dos pods:

   kubectl exec POD_NAME ping EXTERNAL_IP
   

   Se você não vir respostas de ping, verifique a conexão com o serviço externo em sua infraestrutura.

Problemas no cluster

Para problemas de conectividade entre pods, tente definir o escopo do problema para os nós. Muitas vezes, um grupo de nodes não pode se comunicar com outro grupo de nodes.

1. No Dataplane v2, verifique a conectividade do nó atual com todos os outros nós no mesmo cluster. De dentro do pod anetd, verifique o status de integridade:

   cilium status --all-health
   

Problemas com a camada de rede

Identificar em qual camada de rede o problema de conectividade acontece é uma etapa importante. Uma mensagem de erro como "Um problema de conectividade de uma origem para um destino" não é informativa o suficiente para ajudar a resolver o problema, que pode ser um erro do aplicativo, problema de roteamento, ou um problema de DNS. Entender em qual camada o problema acontece ajuda a corrigir o componente certo.

Muitas vezes, as mensagens de erro indicam diretamente a camada em que o problema ocorre. Os exemplos a seguir podem ajudar a resolver problemas da camada de rede:

• Os erros HTTP indicam que o problema é da Camada 7.
  • Os códigos HTTP 40x, 50x ou erros de handshake de TLS significam que tudo funciona normalmente na camada 4.
• Os erros "Conexão redefinida por semelhante" indicam que é um problema de camada 4.
  • Muitas vezes, o soquete remoto não pode concordar com o estado atual de uma conexão e, portanto, envia um pacote RESET. Esse comportamento pode ser um erro no rastreamento de conexão ou NAT.
• Os erros "No route to host" e "Connection timeout" normalmente são um problema das camadas 3 ou 2.
  • Esses erros indicam que o pacote não pode ser roteado corretamente para o destino.

Ferramentas úteis para solução de problemas

Os DaemonSets relacionados à rede são executados nos nós e podem ser a causa dos problemas de conectividade. No entanto, a configuração incorreta dos nós, chaves de topo de rack (ToR, na sigla em inglês), roteadores de coluna ou firewalls também pode causar problemas. Use as ferramentas a seguir para determinar o escopo ou a camada do problema e determinar se é um problema com os nós do GKE Enterprise ou com a infraestrutura física.

Ping

O ping funciona na camada 3 (camada de IP) e verifica a rota entre uma origem e um destino. Se o ping não conseguir chegar a um destino, isso geralmente significa que o problema está na camada 3.

No entanto, nem todos os endereços IP recebem ping. Por exemplo, alguns VIPs do balanceador de carga não serão pingáveis se for um balanceador de carga da camada 4. O serviço ClusterIP é um exemplo em que o VIP pode não retornar uma resposta ping. Na camada 4, esse serviço só retorna uma resposta de ping quando você especifica um número de porta, como VIP:port.

Os balanceadores de carga BGPLB e MetalLB no Google Distributed Cloud funcionam na camada 3. Use o ping para verificar a conectividade. Embora a F5 seja diferente, ela também é compatível com ICMP. Você pode usar o ping para verificar a conectividade com o F5 VIP.

Arping

O ping é semelhante ao ping, mas funciona na camada 2. Os problemas das camadas 2 e 3 geralmente têm mensagens de erro semelhantes de aplicativos. O ping e o ping podem ajudar a diferenciar o problema. Por exemplo, se a origem e o destino estiverem na mesma sub-rede, mas não for possível fazer isso, é um problema da camada 2.

Um arping <ip> bem-sucedido retorna o endereço MAC do destino. Na camada 2, esse endereço geralmente indica um problema de infraestrutura física. Esse problema geralmente é uma alternância física entre nós.

O arping também pode detectar conflitos de endereço IP. Um conflito de endereços IP ocorre quando duas máquinas são configuradas para usar o mesmo endereço IP na mesma sub-rede ou quando um VIP é usado por outra máquina física. Conflitos de endereços IP podem criar problemas intermitentes que são difíceis de solucionar. Se arping <ip> retornar mais de uma entrada de endereço MAC, isso indicará que há um conflito de endereços IP.

Depois de receber o endereço MAC do arping, use https://maclookup.app/ para procurar o fabricante do endereço MAC. Cada fabricante possui um prefixo MAC, portanto, você pode usar essas informações para determinar qual dispositivo está tentando usar o mesmo endereço IP. Por exemplo, o VMware é proprietário do bloco 00:50:56. Portanto, um endereço MAC 00:50:56:xx:yy:zz é uma VM no ambiente do vSphere.

iproute2

A CLI ip para iproute2 tem muitos subcomandos úteis, como os seguintes:

• ip r: imprimir a tabela de rotas
• ip n: mostra a tabela vizinha do endereço IP no mapeamento de endereço MAC.
• ip a: mostra todas as interfaces na máquina.

Uma rota ausente ou uma entrada ausente na tabela vizinha pode causar problemas de conectividade do nó. Anetd gerencia a tabela de rota e a tabela vizinha. Uma configuração incorreta nessas tabelas pode causar problemas de conectividade.

CLI do Cilium / Hubble para Dataplane v2

Cada pod anetd tem várias ferramentas de depuração úteis para problemas de conectividade:

• cilium monitor --type=drop
  • Imprime o registro para cada pacote que é descartado pelo Anetd / Cílium.
• hubble observe
  • Imprime todos os pacotes que passam pela pilha ebpf do anetd.
• cilium status --all-health
  • Imprime o status do Cilium, incluindo o status de conectividade entre nós. Cada pod antd verifica a integridade de todos os outros nós no cluster e pode ajudar a determinar problemas de conectividade entre nós.

Iptables

Os iptables são usados em muitos componentes e subsistemas do Kubernetes. kube-proxy usa iptables para implementar a resolução de serviço.

1. Para resolver problemas de rede no nível iptables, use o seguinte comando:

   iptables -L -v | grep DROP
   

   Revise as regras de soltar e verifique as contagens de pacotes e de bytes para ver se aumentam com o tempo.

tcpdump

O tcpdump é uma poderosa ferramenta de captura de pacotes que gera muitos dados de tráfego de rede. Uma prática comum é executar o tcpdump na origem e no destino. Se um pacote é capturado quando ele sai do nó de origem, mas nunca é capturado no nó de destino, significa que algo entre o pacote descarta o pacote. Esse comportamento geralmente indica que algo na sua infraestrutura física descarta o pacote por engano.

Solução de problemas de DNS

Os problemas de resolução de DNS se enquadram em duas categorias principais:

• Pods regulares, que usam os servidores DNS no cluster.
• Pods ou nós da rede do host, que não usam servidores DNS no cluster

Nas seções a seguir, fornecemos algumas informações sobre a arquitetura de DNS do cluster e dicas úteis antes de começar a resolver problemas em uma dessas categorias.

Arquitetura de DNS do cluster

Um serviço de DNS do cluster resolve solicitações de DNS para pods no cluster. O CoreDNS fornece esse serviço para todas as versões do Google Distributed Cloud.

Cada cluster tem dois ou mais pods coredns e um escalonador automático responsável pelo escalonamento do número de pods DNS em relação ao tamanho do cluster. Há também um serviço chamado kube-dns que faz o balanceamento de carga das solicitações entre todos os pods coredns de back-end.

A maioria dos pods tem o DNS upstream configurado para o endereço IP do serviço kube-dns. Eles enviam solicitações de DNS para um dos pods coredns. As solicitações de DNS podem ser agrupadas em um dos seguintes destinos:

• Se a solicitação for para um domínio cluster.local, é um nome DNS no cluster que faz referência a um serviço ou pod no cluster.
  • O CoreDNS observa o api-server de todos os serviços e pods no cluster e responde às solicitações de domínios cluster.local válidos.
• Se a solicitação não for para um domínio cluster.local, é para um domínio externo.
  • O CoreDNS encaminha a solicitação para os servidores de nomes upstream. Por padrão, o CoreDNS usa os servidores de nomes upstream configurados no nó em que está sendo executado.

Para mais informações, consulte a visão geral de como o DNS funciona e está configurado no Kubernetes.

Dicas de solução de problemas de DNS

Para resolver problemas de DNS, use as ferramentas dig e nslookup. Essas ferramentas permitem enviar solicitações de DNS para testar se a resolução de DNS funciona corretamente. Os exemplos a seguir mostram como usar dig e nslookup para verificar problemas de resolução de DNS.

• Use dig ou nslookup para enviar uma solicitação para google.com:

  dig google.com
  nslookup google.com
  

• Use dig para enviar uma solicitação para kubernetes.default.svc.cluster.local ao servidor 192.168.0.10:

  dig @192.168.0.10 kubernetes.default.svc.cluster.local
  

• Também é possível usar nslookup para realizar a mesma busca DNS do comando dig anterior:

  nslookup kubernetes.default.svc.cluster.local 192.168.0.10
  

  Analise a saída dos comandos dig ou nslookup. Se você receber uma resposta incorreta ou nenhuma resposta, isso indicará um problema de resolução de DNS.

Pods regulares

A primeira etapa para depurar um problema de DNS é determinar se as solicitações chegam aos pods coredns ou não. Muitas vezes, um problema geral de conectividade de cluster aparece como problemas de DNS, porque uma solicitação DNS é o primeiro tipo de tráfego que uma carga de trabalho envia.

Analise as mensagens de erro exibidas nos seus aplicativos. Erros como io timeout ou semelhantes indicam que não há resposta e um problema geral de conectividade de rede.

As mensagens de erro que incluem um código de erro de DNS, como NXDOMAIN ou SERVFAIL, indicam que há conectividade com o servidor DNS no cluster, mas o servidor não conseguiu resolver o nome de domínio:

• Os erros NXDOMAIN indicam que o servidor DNS informa que o domínio não existe. Verifique se o nome de domínio solicitado pelo aplicativo é válido.
• Os erros SERVFAIL ou REFUSED indicam que o servidor DNS enviou uma resposta, mas não conseguiu resolver o domínio ou validar que ele não existe. Para mais informações, verifique os registros dos pods coredns.

Use o comando a seguir para encontrar o endereço IP do serviço kube-dns:

kubectl -n kube-system get svc kube-dns

Em um pod em que o DNS não está funcionando, tente enviar uma solicitação DNS para esse endereço IP usando dig ou nslookup, conforme detalhado em uma seção anterior:

• Se essas solicitações não funcionarem, tente enviá-las para o endereço IP de cada pod coredns.
• Se alguns pods funcionarem, mas não outros, verifique se há padrões discerníveis, como a resolução de DNS para pods no mesmo nó que o pod coredns, mas não entre nós. Esse comportamento pode indicar algum problema de conectividade no cluster.

Se o CoreDNS não conseguir resolver nomes de domínio externos, consulte a seção a seguir para solucionar problemas dos pods da rede do host. O CoreDNS se comporta como um pod de rede host e usa os servidores DNS upstream do nó na resolução de nomes.

Pods ou nós da rede do host

Os pods da rede do host e os nós usam os servidores de nomes configurados no nó para resolução de DNS, não o serviço de DNS no cluster. Dependendo do sistema operacional, esse servidor de nomes é configurado em /etc/resolv.conf ou /run/systemd/resolve/resolv.conf. Essa configuração significa que eles não podem resolver nomes de domínio cluster.local.

Se você tiver problemas com a resolução de nomes de rede de host, use as etapas de solução de problemas nas seções anteriores para testar se o DNS funciona corretamente para seus servidores de nomes upstream.

Verifique se todos os nós têm o mesmo conjunto de servidores configurados. Se você tiver diferentes servidores de nomes configurados, poderá ver inconsistências na resolução de DNS em nós diferentes. Verifique se cada servidor de nomes funciona individualmente enviando uma solicitação para cada um usando dig ou nslookup. Se alguns servidores de nomes funcionarem, mas outros não, você verá esse tipo de falhas de resolução de DNS inconsistente.

Problemas comuns de rede

As seções a seguir detalham alguns problemas comuns de rede que você pode encontrar. Para ajudar a resolver seu problema, siga as orientações de solução de problemas apropriadas. Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Dataplane v2 / Cilium

Erro comum: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Esse erro significa que o evento de criação de pod foi rejeitado pelo agente do Cilium devido a um limite de taxa. Para cada nó, o Cilium tem um limite de quatro solicitações simultâneas para o ponto de extremidade PUT. Quando há um burst de solicitações para um nó, esse comportamento é esperado. O agente do Silvio precisa acompanhar as solicitações atrasadas.

No GKE Enterprise 1.14 e versões posteriores, o limite de taxa se ajusta automaticamente à capacidade do nó. O limitador de taxa pode convergir para um número mais razoável, com limites de taxa mais altos para nós mais eficientes.

Erro comum: Ebpf map size is full

O Dataplane v2 armazena o estado em um mapa de eBFP. O estado inclui as regras de serviço, rastreamento de conexão, identidade do pod e política de rede. Se um mapa está cheio, o agente não pode inserir entradas, o que cria uma discrepância entre o plano de controle e o de dados. Por exemplo, o mapa de Serviço tem um limite de entrada de 64 k.

1. Para verificar as entradas do mapa de eBFP e o tamanho atual, use bpftool. O exemplo a seguir verifica os mapas do balanceador de carga:

   bpftool map dump pinned \
   /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1
   
   bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1
   

2. Se o mapa estiver próximo do limite de 64k, limpe-os. O exemplo a seguir limpa os mapas do balanceador de carga:

   bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
       awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
       head -n -1 | \
       xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key
   
   bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
       awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
       head -n -1 | \
       xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key
   

3. Para preencher novamente o estado no mapa do eBFP, reinicie anetd.

Node ilegível por causa de erros NetworkPluginNotReady

Se o pod da CNI não estiver em execução no nó, você poderá ver um erro semelhante ao seguinte:

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

O nó também pode estar em um estado ilegível, com um erro semelhante ao seguinte exemplo:

  "Network plugin not installed"

Quando um nó é inicializado, o kubelet aguarda vários eventos acontecerem antes de marcá-lo como Ready. Um dos eventos que kubelet verifica é que o plug-in da interface de rede de contêiner (CNI, na sigla em inglês) está instalado. O plug-in da CNI precisa ser instalado via Anetd usando um contêiner de inicialização para instalar o binário da CNI e a configuração da CNI nos diretórios do host necessários.

Para solucionar esse problema, verifique por que esses pods não estão em execução no nó. Normalmente, o erro não se deve a problemas de rede. Esses pods são executados na rede do host, portanto, não há dependência de rede.

1. Verifique o estado do pod anetd. Analise as seguintes etapas de solução de problemas para ajudar a determinar a causa do problema:

   • Se o pod estiver no estado Crashlooping, verifique os registros para ver por que o pod não pode ser executado corretamente.
   • Se o pod estiver no estado Pending, use kubectl describe e revise os eventos de pod. Por exemplo, o pod pode não ter um recurso como um Volume.
   • Se o pod estiver no estado Running, verifique os registros e a configuração. Algumas implementações de CNI oferecem opções para desativar a instalação de CNI, como no Cilium.
   • Há uma opção de configuração chamada "net" chamada custom-cni-conf. Se essa configuração for definida como true, o Anetd não instalará o binário da CNI.

O nó não está pronto devido a entradas ARP desatualizadas

Às vezes, entradas de ARP desatualizadas em nós do plano de controle do cluster de administrador podem causar uma incompatibilidade nos endereços MAC. Essa incompatibilidade de endereço pode causar tempo limite de conexão para os VIPs do plano de controle de clusters de usuários gerenciados. Os tempos limite de conexão podem fazer com que o nó com entradas ARP desatualizadas seja marcado como NOT READY. Os nós marcados como NOT READY podem interromper as instalações e upgrades do cluster.

Nessa situação, o registro do kubelet no nó com entradas ARP desatualizadas contém um erro de tempo limite de handshake de TLS, como este:

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

Siga estas etapas para verificar e resolver o problema:

1. Use o SSH para se conectar ao nó do plano de controle do cluster de usuário.

2. Verifique o endereço MAC da interface a que o endereço VIP está vinculado:

   ip a | grep DEVICE_NAME: -A 6
   

   Substitua DEVICE_NAME pelo nome do dispositivo de rede do nó do plano de controle.

3. Use o SSH para se conectar a um nó do plano de controle de cluster de administrador.

4. No cache ARP do plano de controle do cluster de administrador, procure o endereço VIP do plano de controle do cluster de usuário:

   ip n | grep VIP_ADDRESS
   

   Substitua VIP_ADDRESS pelo endereço IP do VIP do plano de controle do cluster de usuário (controlPlaneVIP).

   Caso os dois comandos ip retornem um endereço MAC diferente, significa que o problema está ocorrendo.

5. Para resolver o problema, transfira o cache ARP no nó do plano de controle do cluster de administrador:

   ip n flush all
   

O serviço F5 não recebe tráfego

Se nenhum tráfego for transmitido para o serviço F5, analise as seguintes etapas de solução de problemas:

1. Verifique se todas as partições no F5 BIG-IP estão configuradas em um cluster, seja cluster de administrador ou de usuário. Se uma partição for compartilhada por vários clusters diferentes, você enfrentará interrupções intermitentes de conexão. Esse comportamento ocorre porque dois clusters tentam aproveitar o controle sobre a mesma partição e excluir serviços de outros clusters.

2. Verifique se os dois pods a seguir estão em execução. Todos os pods que não estiverem em execução indicam um erro:

   Load-balancer-f5
   K8s-bigip-ctlr-deployment-577d57985d-vk9wj
   

   O Load-balancer-f5, de propriedade do GKE Enterprise, cria ConfigMaps para cada serviço do tipo LoadBalancer. O ConfigMap é consumido pelo controlador bigip.

3. Verifique se o ConfigMap existe para cada porta de cada Serviço. Por exemplo, com as seguintes portas:

   Kube-server-443-tcp     2   31h
   Kube-server-8132-tcp        2   31h
   

   O serviço kube-server será semelhante ao seguinte exemplo:

   Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h
   

   A seção de dados no ConfigMap precisa ter o VIP e a porta de front-end, conforme mostrado no exemplo a seguir:

   data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
     schema: f5schemadb://bigip-virtual-server_v0.1.7.json
   

4. Verifique os registros e as métricas da instância do BIG-IP. Se o ConfigMap estiver configurado corretamente, mas a instância BIG-IP não respeitar a configuração, talvez seja um problema F5. No caso de problemas que acontecem dentro da instância do BIG-IP, entre em contato com o suporte do F5 para diagnóstico e resolução.

Falha NAT com muitas conexões paralelas

Para um determinado nó no cluster, o endereço IP do nó fornece conversão de endereços de rede (NAT, na sigla em inglês) para pacotes roteados para um endereço fora do cluster. Da mesma forma, quando pacotes entram em um nó de balanceamento de carga em pacote (spec.loadBalancer.mode: bundled), a conversão de endereços de rede de origem (SNAT, na sigla em inglês) encaminha os pacotes para o endereço IP do nó antes que sejam encaminhados para um pod de back-end.

O intervalo de portas para NAT usado pelo Google Distributed Cloud é 32768-65535. Esse intervalo limita o número de conexões paralelas a 32.767 por protocolo nesse nó. Cada conexão precisa de uma entrada na tabela conntrack. Se houver um número demasiado de conexões de curta duração, a tabela conntrack ficará sem portas para NAT. Um coletor de lixo limpa as entradas desatualizadas, mas a limpeza não é imediata.

Quando o número de conexões no nó se aproximar 32.767, vai começar a ocorrer perda de pacotes nas conexões que precisam de NAT.

Para determinar se esse problema está ocorrendo, faça o seguinte:

1. Execute o seguinte comando no pod anetd do nó problemático:

   kubectl -n kube-system anetd-XXX -- hubble observe \
       --from-ip $IP --to-ip $IP -f
   

   Vão aparecer erros no seguinte formato:

   No mapping for NAT masquerade DROPPED
   

Como solução alternativa para esse problema, redistribua o tráfego para outros nós.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.