Resolva problemas de rede do Google Distributed Cloud

Esta página mostra-lhe como resolver problemas de rede com o Google Distributed Cloud. São disponibilizadas informações e orientações gerais de resolução de problemas, juntamente com ferramentas sugeridas. Também estão incluídas informações de resolução de problemas de DNS e alguns problemas comuns para o Calico, o Seesaw e o MetalLB.

Resolução de problemas de conetividade de rede

A rede do GKE Enterprise baseia-se na sua infraestrutura de rede física. Por exemplo, o Seesaw ou o MetalLB baseiam-se nos seus comutadores que respeitam o ARP gratuito, o equilíbrio de carga agrupado com o protocolo de gateway de fronteira (BGP) baseia-se nos seus routers e todos os nós devem poder comunicar entre si. Quando tem um problema de rede nos seus clusters do GKE, tem de identificar se o problema está nos componentes do GKE Enterprise ou na sua própria infraestrutura.

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

O âmbito do assunto pode ser um dos seguintes:

  • Todos os nós (ou o cluster hostNetwork Pod).
  • Todos os pods ao nível do cluster.
  • Todos os pods num único nó ou num conjunto de nós.
  • Todos os pods da mesma implementação ou DaemonSet.
  • Cliente de fora do cluster.

O âmbito do alvo pode ser um ou mais dos seguintes:

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

A camada de rede pode ser uma ou mais das seguintes:

  • Problemas da camada de ligação da camada 2, como sistema vizinho, ARP ou NDP.
  • Problemas de encaminhamento de endereços IP da camada 3.
  • Problemas com o ponto final TCP ou UDP da camada 4.
  • Problemas de HTTP ou HTTPS da camada 7.
  • Problemas de resolução de DNS.

Compreender o âmbito de um problema ajuda a identificar os componentes envolvidos no problema e em que camada o problema ocorre. A recolha de informações quando o problema ocorre é importante porque alguns problemas são temporários. Por isso, as capturas de ecrã após a recuperação do sistema não incluem informações suficientes para a análise da causa principal.

Problemas de entrada

Se o assunto for um cliente fora do cluster e não conseguir estabelecer ligação a um serviço LoadBalancer, trata-se de um problema de conetividade norte-sul. O diagrama seguinte mostra que, num exemplo funcional, o tráfego de entrada passa pela pilha da esquerda para a direita e o tráfego de retorno passa pela pilha da direita para a esquerda. O Seesaw é diferente, uma vez que o tráfego de retorno ignora o equilibrador de carga e retorna diretamente ao cliente:

O tráfego de entrada passa do utilizador para a infraestrutura física, através de um balanceador de carga para um anetd / kube-proxy e, em seguida, para o back-end. Com o Seesaw, o tráfego de saída ignora o balanceador de carga.

Quando existe um problema com este fluxo de tráfego, use o seguinte fluxograma de resolução de problemas para ajudar a identificar onde se encontra o problema:

Resolução de problemas de entrada de rede através da revisão de cada passo que um pacote dá à medida que se move no seu ambiente. Verifique se existem as ações e a conetividade adequadas ao longo do caminho.

Neste fluxograma, as seguintes orientações de resolução de problemas ajudam a determinar onde se encontra o problema:

  • O pacote sai do cliente? Caso contrário, é provável que tenha um problema de infraestrutura de rede.
  • Está a usar o balanceador de carga Seesaw? Em caso afirmativo, o pacote chega ao nó do Seesaw e, em seguida, o ARP é enviado corretamente? Caso contrário, é provável que tenha um problema de infraestrutura de rede.
  • Está a usar o MetalLB? Em caso afirmativo, o pacote chega ao nó de LB e o ARP é enviado corretamente? Caso contrário, é provável que tenha um problema de infraestrutura de rede.
  • Está a usar o F5 BIG-IP? Se sim, verificou se existem problemas com o F5?
  • A tradução de endereços de rede (NAT) é realizada corretamente? Caso contrário, é provável que tenha um problema com o kube-proxy / Dataplane V2.
  • O pacote chega ao nó de trabalho? Caso contrário, é provável que tenha um problema de Calico / Dataplane v2 Pod-to-Pod.
  • O pacote chega ao Pod? Caso contrário, é provável que tenha um problema de encaminhamento local do Calico / Dataplane v2.

As secções seguintes fornecem passos para resolver problemas em cada fase e 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 router configurado na sua infraestrutura de rede física.

  1. Use tcpdump para verificar o pacote quando sai do cliente para o serviço de destino:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Se não vir tráfego a sair, esta é a origem do problema.

O pacote chega a um nó do Seesaw?

Se usar o Seesaw, consulte a documentação da versão 1.16, encontre o nó principal e, em seguida, ligue-se ao nó através de SSH.

  1. Use tcpdump para verificar se os pacotes esperados chegaram ao nó do Seesaw:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Se não vir tráfego a entrar, esta é a origem do problema.

O pacote chega a um nó do LoadBalancer?

Se usar o MetalLB como balanceador de carga:

  1. Consulte o registo metallb-controller para determinar que nó do balanceador de carga serve o VIP do serviço:

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

  2. Ligue-se ao nó através de SSH.

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

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Para o ManualLB, o tráfego pode chegar a qualquer nó. Consoante a configuração do balanceador de carga, pode escolher um ou vários nós. Use tcpdump para rever o tráfego:

    tcpdump -ni any host NODE_IP and port NODE_PORT

    O comando é diferente entre os tipos de equilibradores de carga, uma vez que o MetalLB e o Seesaw não fazem NAT antes de encaminharem o pacote para os nós.

    Se não vir tráfego a entrar em nenhum nó, esta é a origem do problema.

Existe um problema com o F5 BIG-IP?

Para resolver problemas do F5 BIG-IP, consulte uma das seguintes secções sobre O serviço F5 não recebe tráfego.

O ARP é enviado corretamente?

O nó do balanceador de carga para o MetalLB ou o Seesaw depende do ARP para anunciar o VIP do serviço. Se a resposta ARP for enviada corretamente, mas não estiver a receber tráfego, é um sinal de um problema na sua infraestrutura de rede física. Uma causa comum deste problema é o facto de algumas funcionalidades de aprendizagem do plano de dados avançadas ignorarem a resposta ARP em soluções de rede definida por software (SDN).

  1. Use tcpdump para detetar respostas ARP:

    tcpdump -ni any arp

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

    • Para o Seesaw, são enviados ARPs gratuitos para todos os IPs virtuais. Deve ver as mensagens ARP para cada VIP a cada 10 segundos.

    • Para o MetalLB, não envia ARP gratuito. A frequência com que vê uma resposta depende do momento em que outro dispositivo, como um comutador de topo de rack (ToR) ou um comutador virtual, envia um pedido ARP.

É realizado NAT?

O plano de dados v2 / kube-proxy realiza a tradução de endereços de rede de destino (NAT de destino ou DNAT) para traduzir o VIP de destino num endereço IP do pod de back-end. Se souber qual é o nó de back-end do balanceador de carga, estabeleça ligação ao nó através de SSH.

  1. Use o 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 pode estabelecer ligação aos pods anetd e usar as ferramentas de depuração do Cilium incorporadas:

    cilium monitor --type=drop

Para mais informações, consulte uma das seguintes secções 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, em seguida, é entregue aos pods.

  1. Verifique se o pacote chega à interface externa, normalmente denominada eth0 ou ens192, através de tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

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

Se o pacote nunca chegar ao nó de trabalho, é um indicador de um problema de infraestrutura de rede. Contacte a equipa de infraestrutura de rede para saber por que motivo o pacote é rejeitado entre os nós do LoadBalancer e os nós de trabalho. Seguem-se alguns problemas comuns:

  • Verifique os registos da rede definida por software (SDN). Por vezes, a SDN pode eliminar pacotes por vários motivos, como segmentação, soma de verificação incorreta ou anti-spoofing.
  • Regras de firewall que filtram pacotes cujo destino é o endereço IP e a porta do pod de back-end.

Se o pacote chegar à interface externa ou à interface de túnel do nó, tem de ser encaminhado para o pod de destino. Se o Pod for um Pod de rede do anfitrião, este passo não é necessário porque o Pod partilha o espaço de nomes de rede com o nó. Caso contrário, é necessário o encaminhamento de pacotes adicional.

Cada Pod tem pares de interfaces Ethernet virtuais, que funcionam como tubos. Um pacote enviado para uma extremidade da interface é recebido da outra extremidade da interface. Uma das interfaces é movida para o espaço de nomes de rede do pod e o nome é alterado para eth0. A outra interface é mantida no espaço de nomes do anfitrião. Os CNIs diferentes têm esquemas diferentes. Para o Dataplane v2, a interface é normalmente denominada lxcxxxx. Os nomes têm números de interface consecutivos, como lxc17 e lxc18. Pode verificar se o pacote chega ao Pod através de tcpdump ou também pode 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 encaminhamento da seguinte forma:

ip route

Normalmente, cada agrupamento deve ter uma entrada de encaminhamento que encaminhe o endereço IP do agrupamento para a interface lxc. Se a entrada estiver em falta, normalmente significa que o caminho de dados da CNI tem um erro. Para determinar a causa principal, verifique os registos do DaemonSet da CNI.

Problemas de saída

Se o tráfego puder entrar num pod, pode ter um problema com o tráfego à medida que sai do pod. Os diagramas seguintes mostram que, num exemplo funcional, o tráfego recebido percorre a pilha da esquerda para a direita:

O tráfego de saída passa do pod através da interface externa do anfitrião para a infraestrutura física e, em seguida, para o serviço externo.

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

    O endereço IP de origem do pacote deve ser mapeado do endereço IP do pod para o endereço IP do nó com a tradução de endereços de rede de origem (NAT de origem ou SNAT). No Dataplane v2, este processo é alcançado através do ebpf carregado numa interface externa. O Calico usa regras de iptables.

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

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT

    Se tcpdump mostrar que os pacotes estão corretamente mascarados, mas o serviço remoto não responder, verifique a ligação ao serviço externo na sua infraestrutura.

  2. Se os pacotes de saída estiverem corretamente mascarados como o endereço IP do nó, verifique a conetividade do anfitrião externo (camada 3) através do comando tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    Ao mesmo tempo que executa tcpdump, envie um ping de um dos pods:

    kubectl exec POD_NAME ping EXTERNAL_IP

    Se não vir respostas de ping, verifique a ligação ao serviço externo na sua infraestrutura.

Problemas no cluster

Para problemas de conetividade de pod para pod, experimente restringir o problema aos nós. Muitas vezes, um grupo de nós não consegue comunicar com outro grupo de nós.

  1. No Dataplane v2, verifique a conetividade dos nós do nó atual a todos os outros nós no mesmo cluster. No interior do anetd Pod, verifique o estado de funcionamento:

    cilium status --all-health

    O Google Distributed Cloud usa o modo de encaminhamento direto. Deve ver uma entrada de rota por nó no cluster, conforme mostrado no exemplo seguinte:

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    Se faltar uma rota esperada para um nó, a ligação a esse nó é perdida.

Problemas da camada de rede

Identificar em que camada de rede ocorre o problema de conetividade é um passo importante. Uma mensagem de erro como "Um problema de conetividade de uma origem para um destino" não é suficientemente informativa para ajudar a resolver o problema, que pode ser um erro de aplicação, um problema de encaminhamento ou um problema de DNS. Compreender em que camada ocorre o problema ajuda a corrigir o componente certo.

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

  • Os erros HTTP indicam que se trata de um problema da camada 7.
    • Os códigos HTTP 40x, 50x ou os erros de handshake TLS significam que tudo funciona normalmente na camada 4.
  • Os erros "Ligação reposta pelo par" indicam que se trata de um problema da camada 4.
    • Muitas vezes, o socket remoto não concorda com o estado atual de uma ligação e, por isso, envia um pacote RESET. Este comportamento pode ser um erro no acompanhamento de ligações ou no NAT.
  • Os erros "No route to host" e "Connection timeout" são normalmente um problema da camada 3 ou da camada 2.
    • Estes erros indicam que não é possível encaminhar corretamente o pacote para o destino.

Ferramentas de resolução de problemas úteis

Os DaemonSets relacionados com a rede são executados nos seus nós e podem ser a causa de problemas de conetividade. No entanto, a configuração incorreta dos nós, dos comutadores de topo de rack (ToR), dos routers principais ou das firewalls também pode causar problemas. Pode usar as seguintes ferramentas para ajudar a determinar o âmbito ou a camada do problema e determinar se se trata de um problema com os nós do GKE Enterprise ou com a sua infraestrutura física.

Tchim-tchim

O ping funciona na camada 3 (camada IP) e verifica o caminho entre uma origem e um destino. Se o ping não conseguir alcançar um destino, significa frequentemente que o problema se encontra na camada 3.

No entanto, nem todos os endereços IP são acessíveis através de ping. Por exemplo, alguns VIPs do equilibrador de carga não são pingáveis se for um equilibrador de carga de camada 4 puro. O serviço ClusterIP é um exemplo em que o VIP pode não devolver uma resposta de ping. Na camada 4, este serviço só devolve uma resposta de ping quando especifica um número de porta, como VIP:port.

Os equilibradores de carga BGPLB, MetalLB e Seesaw no Google Distributed Cloud funcionam todos na camada 3. Pode usar o comando ping para verificar a conetividade. Embora seja diferente, o F5 também suporta o ICMP. Pode usar o comando ping para verificar a conetividade com o VIP do F5.

Arping

O arping é semelhante ao ping, exceto que funciona na camada 2. Os problemas da camada 2 e da camada 3 costumam ter mensagens de erro semelhantes das aplicações. O arping e o ping podem ajudar a distinguir o problema. Por exemplo, se a origem e o destino estiverem na mesma sub-rede, mas não conseguir fazer um arping ao destino, trata-se de um problema da camada 2.

Um arping <ip> bem-sucedido devolve o endereço MAC do destino. Na camada 2, este endereço indica frequentemente um problema de infraestrutura física. Este problema é uma configuração incorreta do comutador virtual.

O arping também pode detetar conflitos de endereços IP. Um conflito de endereço IP ocorre quando duas máquinas estão configuradas para usar o mesmo endereço IP na mesma sub-rede ou quando um VIP é usado por outra máquina física. Os conflitos de endereços IP podem criar problemas intermitentes difíceis de resolver. Se arping <ip> devolver mais do que uma entrada de endereço MAC, é um indício de que existe um conflito de endereços IP.

Depois de obter o endereço MAC a partir do arping, pode usar https://maclookup.app/ para procurar o fabricante do endereço MAC. Cada fabricante tem um prefixo MAC, pelo que pode usar estas informações para ajudar a determinar que dispositivo está a tentar usar o mesmo endereço IP. Por exemplo, a VMware é proprietária do bloco 00:50:56, pelo que um endereço MAC 00:50:56:xx:yy:zz é uma VM no seu ambiente vSphere.

iproute2

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

  • ip r: imprimir a tabela de trajetos
  • ip n: imprimir a tabela de vizinhos para o mapeamento do endereço IP para o endereço MAC
  • ip a: imprimir todas as interfaces na máquina

Uma rota em falta ou uma entrada em falta na tabela de vizinhos pode causar problemas de conetividade a partir do nó. O Anetd e o Calico gerem a tabela de rotas e a tabela de vizinhos. Uma configuração incorreta nessas tabelas pode causar problemas de conetividade.

CLI do Cilium / Hubble para o Dataplane v2

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

  • cilium monitor --type=drop
    • Imprima o registo de cada pacote que é rejeitado pelo anetd / Cilium.
  • hubble observe
    • Imprima todos os pacotes que passam pela pilha eBPF do anetd.
  • cilium status --all-health
    • Imprima o estado do Cilium, incluindo o estado da conetividade entre nós. Cada anetd Pod verifica o estado de funcionamento de todos os outros nós no cluster e pode ajudar a determinar problemas de conetividade entre nós.

Iptables

Os iptables são usados em muitos componentes e subsistemas do Kubernetes. kube-proxy usa o iptables para implementar a resolução de serviços. O Calico usa iptables para implementar a política de rede

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

    iptables -L -v | grep DROP

    Reveja as regras de rejeição e verifique as contagens de pacotes e de bytes para ver se aumentam ao longo do tempo.

Tcpdump

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

Métrica

O Google Distributed Cloud contém várias métricas para ajudar a acompanhar o comportamento da sua rede. As seguintes métricas oferecem um bom ponto de partida:

Categoria Métrica Descrição
Pacotes perdidos cilium_drop_bytes_total Total de bytes ignorados, etiquetados por motivo de ignorância e direção de entrada/saída. Esta métrica é um bom ponto de partida para investigar diminuições ao nível do byte.
cilium_drop_count_total Total de pacotes ignorados, etiquetados por motivo de ignorância e direção de entrada/saída.
container_network_receive_packets_dropped_total Contagem cumulativa de pacotes rejeitados durante a receção. Amostrada a cada 60 segundos.
container_network_transmit_packets_dropped_total Contagem cumulativa de pacotes rejeitados durante a transmissão. Amostrada a cada 60 segundos.
Pacotes encaminhados cilium_forward_bytes_total Total de bytes encaminhados, etiquetados pela direção de entrada/saída. Amostrada a cada 60 segundos. Esta métrica fornece informações de encaminhamento ao nível dos bytes.
cilium_forward_count_total Total de pacotes encaminhados, etiquetados pela direção de entrada/saída. Amostrada a cada 60 segundos. Esta métrica indica a quantidade de pacotes para o tráfego encaminhado.
cilium_policy_l7_forwarded_total Total de pedidos encaminhados da camada 7.
Pacotes recebidos cilium_policy_l7_received_total Número total de pedidos/respostas L7 recebidos. Amostrada a cada 60 segundos.
container_network_receive_bytes_total Contagem cumulativa de bytes recebidos. Amostrada a cada 60 segundos.
container_network_receive_packets_total Contagem cumulativa de pacotes recebidos. Amostrada a cada 60 segundos.
container_network_receive_errors_total Contagem cumulativa de erros encontrados durante a receção. Amostrada a cada 60 segundos.
cilium_kubernetes_events_received_total Número de eventos do Kubernetes recebidos etiquetados por âmbito, ação, dados válidos e igualdade. Amostrada a cada 60 segundos.
BPF cilium_bpf_maps_virtual_memory_max_bytes O BPF mapeia o tamanho máximo de utilização da memória do kernel em bytes.
cilium_bpf_progs_virtual_memory_max_bytes Tamanho máximo de utilização de memória do kernel dos programas BPF em bytes.
Conntrack node_nf_conntrack_entries Número de entradas de fluxo atualmente atribuídas para o acompanhamento de ligações. Amostrada a cada 60 segundos.
node_nf_conntrack_entries_limit Tamanho máximo da tabela de acompanhamento de ligações. Amostrada a cada 60 segundos.
Conetividade cilium_node_connectivity_latency_seconds A última latência observada entre o agente Cilium atual e outros nós do Cilium em segundos. Amostrada a cada 60 segundos.
cilium_node_connectivity_status O último estado observado da conetividade ICMP e HTTP entre o agente Cilium atual e outros nós Cilium. Amostrada a cada 60 segundos.
Operadores do Cilium cilium_operator_process_cpu_seconds_total Tempo total da CPU do utilizador e do sistema gasto em segundos. Amostrada a cada 60 segundos.
cilium_operator_process_max_fds Número máximo de descritores de ficheiros abertos. Amostrada a cada 60 segundos.
cilium_operator_process_open_fds Número de descritores de ficheiros abertos. Amostrada a cada 60 segundos.
cilium_operator_process_resident_memory_bytes Tamanho da memória residente em bytes. Amostrada a cada 60 segundos.
cilium_operator_process_start_time_seconds Hora de início do processo desde a época Unix em segundos. Amostrada a cada 60 segundos.
cilium_operator_process_virtual_memory_bytes Tamanho da memória virtual em bytes. Amostrada a cada 60 segundos.
cilium_operator_process_virtual_memory_max_bytes Quantidade máxima de memória virtual disponível em bytes. Amostrada a cada 60 segundos.
cilium_operator_identity_gc_entries O número de identidades ativas e eliminadas no final de uma execução do coletor de lixo. Amostrada a cada 60 segundos.
cilium_operator_identity_gc_runs O número de vezes que o coletor de lixo de identidade foi executado. Amostrada a cada 60 segundos.

Para receber notificações quando qualquer uma destas métricas exceder ou ficar abaixo de um determinado limite, crie políticas de alerta. Para saber mais, consulte o artigo Crie políticas de alerta de limite de métricas na documentação do Cloud Monitoring.

Para saber mais sobre estas métricas e ver a lista completa de métricas, consulte o artigo Métricas do Google Distributed Cloud.

Resolução de problemas de DNS

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

  • Pods normais, que usam os servidores DNS no cluster.
  • Pods ou nós de rede de anfitrião, que não usam servidores DNS no cluster

As secções seguintes fornecem algumas informações sobre a arquitetura de DNS do cluster e sugestões úteis antes de começar a resolver problemas de uma destas categorias.

Arquitetura de DNS de cluster

Um serviço DNS de cluster resolve pedidos DNS para pods no cluster. O CoreDNS fornece este serviço para as versões 1.9.0 e posteriores do Google Distributed Cloud.

Cada cluster tem dois ou mais coredns pods e um dimensionador automático responsável por dimensionar o número de pods de DNS em relação ao tamanho do cluster. Existe também um serviço denominado kube-dns que equilibra a carga dos pedidos entre todos os agrupamentos coredns de back-end.

A maioria dos pods tem o respetivo DNS a montante configurado para o endereço IP do serviço kube-dns e os pods enviam pedidos DNS para um dos pods coredns. Os pedidos de DNS podem ser agrupados num dos seguintes destinos:

  • Se o pedido for para um domínio cluster.local, trata-se de um nome DNS no cluster que faz referência a um serviço ou um pod no cluster.
    • O CoreDNS monitoriza o api-server de todos os serviços e pods no cluster e responde a pedidos de domínios cluster.local válidos.
  • Se o pedido não for para um domínio cluster.local, é para um domínio externo.
    • O CoreDNS encaminha o pedido para os servidores de nomes upstream. Por predefinição, o CoreDNS usa os servidores de nomes a montante configurados no nó em que está a ser executado.

Para mais informações, consulte a vista geral de como o DNS funciona e é configurado no Kubernetes.

Sugestões de resolução de problemas de DNS

Para resolver problemas de DNS, pode usar as ferramentas dig e nslookup. Estas ferramentas permitem-lhe enviar pedidos de DNS para testar se a resolução de DNS funciona corretamente. Os exemplos seguintes mostram como usar dig e nslookup para verificar se existem problemas de resolução de DNS.

  • Use dig ou nslookup para enviar um pedido de google.com:

    dig google.com
nslookup google.com

  • Use dig para enviar um pedido de kubernetes.default.svc.cluster.local para o servidor 192.168.0.10:

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

  • Também pode usar nslookup para realizar a mesma pesquisa DNS que o comando dig anterior:

    nslookup kubernetes.default.svc.cluster.local 192.168.0.10

    Reveja o resultado dos comandos dig ou nslookup. Se receber uma resposta incorreta ou nenhuma resposta, isto indica um problema de resolução de DNS.

Agrupamentos normais

O primeiro passo para depurar um problema de DNS é determinar se os pedidos chegam aos corednspods ou não. Muitas vezes, um problema de conetividade geral do cluster aparece como problemas de DNS porque um pedido de DNS é o primeiro tipo de tráfego que uma carga de trabalho envia.

Reveja as mensagens de erro das suas aplicações. Erros como io timeout ou semelhantes indicam que não existe resposta e que há um problema geral de conetividade de rede.

As mensagens de erro que incluem um código de erro de DNS, como NXDOMAIN ou SERVFAIL, indicam que existe conetividade 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 comunica que o domínio não existe. Verifique se o nome do domínio solicitado pela sua aplicação é válido.
  • Os erros SERVFAIL ou REFUSED indicam que o servidor DNS enviou uma resposta, mas não conseguiu resolver o domínio nem validar que não existe. Para mais informações, consulte os registos dos corednspods.

Pode encontrar o endereço IP do serviço kube-dns através do seguinte comando:

kubectl -n kube-system get svc kube-dns

A partir de um pod onde o DNS não está a funcionar, tente enviar um pedido DNS para este endereço IP usando dig ou nslookup, conforme detalhado numa secção anterior:

  • Se estes pedidos não funcionarem, experimente enviar pedidos para o endereço IP de cada corednspod.
  • Se alguns Pods funcionarem, mas outros não, verifique se existem padrões discerníveis, como a resolução de DNS funcionar para Pods no mesmo nó que o Pod coredns, mas não entre nós. Este comportamento pode indicar um problema de conetividade no cluster.

Se o CoreDNS não conseguir resolver nomes de domínios externos, consulte a secção seguinte para resolver problemas dos pods de rede do anfitrião. O CoreDNS comporta-se como um pod de rede de anfitrião e usa os servidores DNS upstream do nó para a resolução de nomes.

Pods ou nós de rede de anfitrião

Os pods de rede de anfitrião e os nós usam os servidores de nomes configurados no nó para a resolução de DNS e não o serviço de DNS no cluster. Consoante o SO, este servidor de nomes é configurado em /etc/resolv.conf ou /run/systemd/resolve/resolv.conf. Esta configuração significa que não conseguem resolver os nomes de domínio cluster.local.

Se tiver problemas com a resolução de nomes de rede de anfitriões, siga os passos de resolução de problemas nas secções anteriores para testar se o DNS funciona corretamente para os seus servidores de nomes a montante.

Problemas de rede comuns

As secções seguintes detalham alguns problemas de rede comuns que pode encontrar. Para ajudar a resolver o problema, siga as orientações de resolução de problemas adequadas. Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Calico

Erro comum: calico/node is not ready: BIRD is not ready: BGP not established

Este erro de estado "não pronto" no Kubernetes significa normalmente que um determinado par não está acessível no cluster. Verifique se a conetividade BGP entre os dois pares é permitida no seu ambiente.

Este erro também pode ocorrer se forem configurados recursos de nós inativos para a malha de nó a nó. Para corrigir este problema, desative os nós desatualizados.

Dataplane v2 / Cilium

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

Este erro significa que o evento de criação do Pod foi rejeitado pelo agente do Cilium devido a um limite de velocidade. Para cada nó, o Cilium tem um limite de quatro pedidos simultâneos ao ponto final PUT. Quando existe um pico de pedidos para um nó, este comportamento é esperado. O agente do Cilium deve recuperar os pedidos atrasados.

No GKE Enterprise 1.14 e posterior, o limite de taxa ajusta-se automaticamente à capacidade do nó. O limitador de taxa pode convergir para um número mais razoável, com limites de taxa mais elevados para nós mais potentes.

Erro comum: Ebpf map size is full

O plano de dados v2 armazena o estado num mapa eBFP. O estado inclui o serviço, a monitorização da ligação, a identidade do pod e as regras da política de rede. Se um mapa estiver cheio, o agente não pode inserir entradas, o que cria uma discrepância entre o plano de controlo e o plano de dados. Por exemplo, o mapa de serviços tem um limite de 64 mil entradas.

  1. Para verificar as entradas do mapa eBFP e o respetivo tamanho atual, use bpftool. O exemplo seguinte verifica os mapeamentos 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 perto do limite de 64 mil, limpe os mapas. O exemplo seguinte limpa os mapeamentos 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 eBFP, reinicie o anetd.

O nó não está pronto devido a erros NetworkPluginNotReady

Se o CNI Pod não estiver em execução no nó, pode 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 num estado não pronto, com um erro semelhante ao do exemplo seguinte:

  "Network plugin not installed"

Quando um nó é inicializado, o kubelet aguarda que ocorram vários eventos antes de marcar o nó como Ready. Um dos eventos que o kubelet verifica é se o plug-in da interface de rede do contentor (CNI) está instalado. O plugin CNI deve ser instalado pelo anetd ou pelo Calico através de um contentor init para instalar o binário CNI e a configuração CNI nos diretórios de anfitrião necessários.

Para resolver este problema, verifique por que motivo esses pods não estão a ser executados no nó. Normalmente, o erro não se deve a problemas de rede. Esses pods são executados na rede do anfitrião, pelo que não existe dependência de rede.

  1. Verifique o estado do anetd ou do calico-node Pod. Reveja os seguintes passos de resolução de problemas para ajudar a determinar a causa do problema:

    • Se o Pod estiver num estado Crashlooping, verifique os registos para ver por que motivo o Pod não consegue ser executado corretamente.
    • Se o pod estiver num estado Pending, use kubectl describe e reveja os eventos do pod. Por exemplo, o pod pode não ter um recurso, como um volume.
    • Se o pod estiver no estado Running, verifique os registos e a configuração. Algumas implementações de CNI oferecem opções para desativar a instalação de CNI, como no Cilium.
    • Existe uma opção de configuração no anetd denominada custom-cni-conf. Se esta definição estiver configurada como true, o anetd não instala o respetivo binário CNI.

O nó NÃO ESTÁ PRONTO devido a entradas ARP desatualizadas

Por vezes, as entradas ARP obsoletas nos nós do plano de controlo do cluster de administrador podem causar uma incompatibilidade nos endereços MAC. Esta incompatibilidade de endereços pode, por sua vez, causar limites de tempo limite de ligação aos VIPs do plano de controlo dos clusters de utilizadores geridos. Os limites de tempo da ligação podem fazer com que o nó com entradas ARP desatualizadas seja marcado como NOT READY. Os nós marcados como NOT READY podem atrasar as instalações e as atualizações dos clusters.

Nesta situação, o registo kubelet no nó com entradas ARP desatualizadas contém um erro de limite de tempo de handshake TLS semelhante ao seguinte:

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 os passos abaixo para validar e resolver o problema:

  1. Use o SSH para estabelecer ligação ao nó do plano de controlo do cluster de utilizadores.

  2. Valide o endereço MAC da interface à qual o endereço VIP está associado:

    ip a | grep DEVICE_NAME: -A 6

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

  3. Use SSH para se ligar a um nó do plano de controlo do cluster de administrador.

  4. Verifique a cache ARP no plano de controlo do cluster de administrador para o endereço VIP do plano de controlo do cluster de utilizador:

    ip n | grep VIP_ADDRESS

    Substitua VIP_ADDRESS pelo endereço IP do VIP do plano de controlo do cluster do utilizador (controlPlaneVIP).

    Se os dois comandos ip devolverem um endereço MAC diferente, significa que é afetado por este problema.

  5. Para resolver o problema, limpe a cache ARP no nó do plano de controlo do cluster de administrador:

    ip n flush all

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

Se não passar tráfego para o serviço F5, reveja os seguintes passos de resolução de problemas:

  1. Verifique se todas as partições no F5 BIG-IP estão configuradas num cluster, quer seja um cluster de administrador ou de utilizador. Se uma partição for partilhada por vários clusters diferentes, ocorrem interrupções de ligação intermitentes. Este comportamento deve-se ao facto de dois clusters tentarem assumir o controlo da mesma partição e eliminarem os serviços de outros clusters.

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

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

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

  3. Certifique-se de que 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 deve ser semelhante ao seguinte exemplo:

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

    A secção de dados no ConfigMap deve ter o VIP e a porta do front-end, conforme mostrado no exemplo seguinte:

    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 registos e as métricas da instância BIG-IP. Se o ConfigMap estiver configurado corretamente, mas a instância do BIG-IP não respeitar a configuração, pode ser um problema do F5. Para problemas que ocorrem na instância do BIG-IP, contacte o apoio técnico da F5 para diagnosticar e resolver os problemas.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte: