Como usar o GKE Dataplane V2

Nesta página, descrevemos como resolver problemas do GKE Dataplane V2 para clusters do Google Kubernetes Engine (GKE).

Solução de problemas com o GKE Dataplane V2

Nesta seção, mostramos como investigar e resolver problemas com o GKE Dataplane V2.

  1. Confirme se o GKE Dataplane V2 está ativado:

    kubectl -n kube-system get pods -l k8s-app=cilium -o wide

    Se o GKE Dataplane V2 estiver em execução, a saída incluirá pods com o prefixo anetd-. O anetd é o controlador de rede do GKE Dataplane V2.

  2. Se o problema for com a aplicação da política de serviços ou rede, verifique os registros do pod anetd: Use os seguintes seletores de registros no Cloud Logging:

    resource.type="k8s_container"
labels."k8s-pod/k8s-app"="cilium"
resource.labels.cluster_name="CLUSTER_NAME"

  3. Se a criação do pod falhar, verifique as dicas nos registros do kubelet. Use os seguintes seletores de registros no Cloud Logging:

    resource.type="k8s_node"
log_name=~".*/logs/kubelet"
resource.labels.cluster_name="CLUSTER_NAME"

    Substitua CLUSTER_NAME pelo nome do cluster ou remova-o completamente para visualizar os registros de todos os clusters.

Problemas conhecidos

Problemas de conectividade intermitente relacionados a conflitos de intervalo NodePort no cluster do GKE Dataplane V2

Nos clusters do GKE Dataplane V2, podem ocorrer problemas de conectividade intermitente para tráfego mascarado ou com uso temporário de portas. Esses problemas são causados por possíveis conflitos de porta com o intervalo NodePort reservado e geralmente acontecem nos seguintes cenários:

  • ip-masq-agent personalizado: se você estiver usando um ip-masq-agent personalizado (versão 2.10 ou posterior), onde o cluster tem serviços NodePort ou de balanceador de carga, você pode ter problemas de conectividade intermitentes devido ao conflito com o intervalo NodePort. A partir da versão 2.10, ip-masq-agent tem o argumento --random-fully implementado internamente por padrão. Para mitigar isso, defina explicitamente --random-fully=false (aplicável desde a versão 2.11) em argumentos na configuração ip-masq-agent. Para detalhes de configuração, consulte Como configurar um agente de mascaramento de IP em clusters padrão.

  • Overlap de intervalo de porta temporário: se o intervalo de porta temporário definido por net.ipv4.ip_local_port_range nos nós do GKE se sobrepõem ao intervalo NodePort (30000-32767), o que também pode gerar problemas de conectividade. Para evitar esse problema, verifique se esses dois intervalos não se sobrepõem.

Revise a configuração de ip-masq-agent e as configurações do intervalo de porta temporário para garantir que elas não conflitem com o intervalo de NodePort. Se você encontrar problemas de conectividade intermitente, considere essas possíveis causas e ajuste sua configuração de acordo.

Os intervalos de portas da política de rede não entram em vigor

Se você especificar um campo endPort em uma política de rede em um cluster que tenha GKE Dataplane V2 ativado, ele não terá efeito.

A partir do GKE 1.22, a API Kubernetes Network Policy permite especificar um intervalo de portas em que a política de rede é aplicada. Essa API é compatível com clusters com a Política de rede do Calico, mas não com clusters que têm o GKE Dataplane V2.

Para verificar o comportamento dos objetos NetworkPolicy, leia-os depois de serem gravados no servidor da API. Se o objeto ainda contiver o campo endPort, o recurso será aplicado. Se o campo endPort estiver ausente, o recurso não será aplicado. Em todos os casos, o objeto armazenado no servidor de API é a fonte da verdade da política de rede.

Saiba mais em KEP-2079: política de rede compatível com intervalos de portas.

Os pods exibem a mensagem de erro failed to allocate for range 0: no IP addresses available in range set

Versões afetadas do GKE: de 1.22 a 1.25

Os clusters do GKE que executam pools de nós que usam containerd e têm o GKE Dataplane V2 ativado podem ter problemas de vazamento de endereço IP e esgotar todos os endereços de IP do pod em um nó. Um pod programado em um nó afetado exibe uma mensagem de erro semelhante a esta:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Saiba mais consultando o problema 5768 do containerd.

Versões corrigidas

Para corrigir esse problema, faça upgrade do cluster para uma das seguintes versões do GKE:

  • 1.22.17-gke.3100 ou mais recente.
  • 1.23.16-gke.200 ou mais recente.
  • 1.24.9-gke.3200 ou mais recente.
  • 1.25.6-gke.200 ou mais recentes.

A política de rede descarta uma conexão devido à pesquisa incorreta de acompanhamento de conexão

Quando um pod cliente se conecta a si mesmo por meio de um serviço ou endereço IP virtual de um balanceador de carga de rede de passagem interno, o pacote de resposta não é identificado como parte de uma conexão devido a uma pesquisa de conntrack incorreta no plano de dados. Isso significa que uma política de rede que restringe o tráfego de entrada do pod é aplicada incorretamente no pacote.

O impacto desse problema depende do número de pods configurados para o serviço. Por exemplo, se o serviço tiver um pod de back-end, a conexão sempre falhará. Se o serviço tiver dois pods de back-end, a conexão falhará 50% do tempo.

Versões corrigidas

Para corrigir esse problema, faça upgrade do cluster para uma das seguintes versões do GKE:

  • 1.28.3-gke.1090000 ou mais recente.

Alternativas

É possível atenuar esse problema configurando port e containerPort no manifesto do serviço com o mesmo valor.

Quedas de pacotes para fluxos de conexão com alça de cabelo

Quando um pod cria uma conexão TCP com ele mesmo, de modo que o pod é a origem e o destino da conexão, o rastreamento de conexão eBPF do GKE Dataplane V2 rastreia incorretamente os estados de conexão, levando a um vazamento{101 }conntrack entradas.

Quando uma tupla de conexão (protocolo, IP de origem/destino e porta de origem/destino) vaza, novas conexões que usam a mesma tupla de conexão podem resultar no descarte de pacotes de retorno.

Versões corrigidas

Para corrigir esse problema, faça upgrade do cluster para uma das seguintes versões do GKE:

  • 1.28.3-gke.1090000 ou mais recente
  • 1.27.11-gke.1097000 ou mais recente

Alternativas

Use uma das seguintes soluções alternativas:

  • Ative a reutilização de TCP (sinal de atividade) para aplicativos em execução em pods que podem se comunicar com eles mesmos usando um serviço. Isso impede que a sinalização TCP FIN seja emitida e evita o vazamento da entrada do conntrack.

  • Ao usar conexões de curta duração, exponha o pod usando um balanceador de carga de proxy, como o Gateway, para expor o serviço. Isso faz com que o destino da solicitação de conexão seja definido como o endereço IP do balanceador de carga, impedindo que o GKE Dataplane V2 execute SNAT no endereço IP de loopback.

A seguir