GKE Dataplane V2

Esta página disponibiliza uma visão geral das funções do GKE Dataplane V2 e como ele funciona.

Esta página pressupõe que você conhece a rede nos clusters do GKE.

Visão geral do GKE Dataplane V2

O GKE Dataplane V2 é um plano de dados otimizado para a rede do Kubernetes. O GKE Dataplane V2 oferece o seguinte:

  • Experiência do usuário consistente na rede.
  • visibilidade em tempo real da atividade da rede;
  • arquitetura mais simples que facilita o gerenciamento e a solução de problemas de clusters.

O GKE Dataplane V2 é ativado por padrão para todos os novos clusters do Autopilot.

Como o GKE Dataplane V2 funciona

O GKE Dataplane V2 é implementado usando o eBPF. À medida que os pacotes chegam a um nó do GKE, os programas eBPF instalados no kernel decidem como rotear e processar os pacotes. Ao contrário do processamento de pacotes com iptables, os programas eBPF podem usar metadados específicos do Kubernetes no pacote. Isso permite que o GKE Dataplane V2 processe pacotes de rede no kernel com mais eficiência e relate ações anotadas de volta ao espaço do usuário para geração de registros.

O diagrama a seguir mostra o caminho de um pacote ao longo de um nó usando o GKE Dataplane V2:

O caminho de um pacote por um nó usando o GKE Dataplane V2.

O GKE implanta o controlador do GKE Dataplane V2 como um DaemonSet chamado anetd em cada nó no cluster. anetd interpreta objetos do Kubernetes e programa topologias de rede no eBPF. Os pods anetd são executados no namespace kube-system.

GKE Dataplane V2 e NetworkPolicy

O GKE Dataplane V2 é implementado usando o Cilium. O plano de dados legado do GKE é implementado usando o Calico.

Ambas as tecnologias gerenciam o NetworkPolicy do Kubernetes. O Cilium usa o eBPF e a interface de rede de contêiner (CNI, na sigla em inglês) do Calico usa a iptables no kernel do Linux.

Vantagens do GKE Dataplane V2

Escalonabilidade

O GKE Dataplane V2 tem características de escalonabilidade diferentes do plano de dados legado.

Para versões do GKE em que o GKE Dataplane V2 não usa kube-proxy e não depende do iptables para roteamento de serviço, o GKE remove alguns gargalos relacionados ao iptables, como o número de Serviços.

O GKE Dataplane V2 depende de mapas eBPF limitados a 260.000 endpoints em todos os serviços.

Segurança

A NetworkPolicy do Kubernetes está sempre ativada em clusters com o GKE Dataplane V2. Não é preciso instalar e gerenciar complementos de software de terceiros, como o Calico, para aplicar a política de rede.

Operações

Quando você cria um cluster com o GKE Dataplane V2, a geração de registros de política de rede é integrada. Configure a CRD da geração de registros no cluster para ver quando as conexões são permitidas e negadas pelos pods.

Consistência

O GKE Dataplane V2 oferece uma experiência de rede consistente.

Para mais informações, consulte Disponibilidade do GKE Dataplane V2.

Especificações técnicas do GKE Dataplane V2

O GKE Dataplane V2 aceita clusters com as seguintes especificações:

Especificação GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
Número de nós por cluster 7.500 500 500
Número de pods por cluster 200.000 15.000 27.500
Número de pods por trás de um serviço 10.000 1.000 1.000
Número de serviços de IP de cluster 10.000 1.000 1.000
Número de serviços do LoadBalancer por cluster 750 500 1.000

O GKE Dataplane V2 mantém um mapa de serviços para acompanhar quais serviços se referem a quais pods como back-ends. O número de back-ends de pods de cada serviço somado em todos os serviços precisa caber no mapa, que pode conter até 260.000 entradas. Se esse limite for excedido, talvez o cluster não funcione conforme o esperado.

Limites de nós

O número máximo de nós por cluster depende da versão e da localização do Kubernetes do cluster do GKE Dataplane V2:

  • Clusters regionais:
    • Kubernetes versão 1.31 ou mais recente: até 7.500 nós.
    • Kubernetes versão 1.23 ou mais recente: até 5.000 nós.
  • Clusters zonais: até 1.000 nós.
  • Todos os outros clusters: até 500 nós.

Para atingir os limites de nós mais altos (5.000 ou 7.500), seu cluster regional também precisa atender às seguintes condições:

  • O cluster precisa ter o Private Service Connect ativado. Para verificar se o cluster usa o Private Service Connect, consulte Clusters com o Private Service Connect.
  • Somente os clusters criados com o GKE versão 1.23 ou posterior têm um limite de 5.000 nós elevados. Para clusters criados com versões anteriores do GKE, pode ser necessário aumentar a cota de tamanho do cluster. Entre em contato com o suporte para receber ajuda.
  • Os clusters que usam a CRD CiliumNetworkPolicy (Cilium) não podem ser escalonados para 5.000 nós. O CRD CiliumClusterwideNetworkPolicy aceita até 5.000 nós.

Serviços LoadBalancer no Google Distributed Cloud

O número de serviços LoadBalancer aceitos no Google Distributed Cloud depende as modo do balanceador de carga que está sendo usado. O Google Distributed Cloud oferece suporte a 500 serviços LoadBalancer ao usar modo de balanceamento de carga em pacote (Seesaw) e 250 ao usar a carga integrada de balanceamento de carga com F5. Para mais informações, consulte Escalonabilidade.

Implantar cargas de trabalho com SCTP

É possível implantar cargas de trabalho que usam o protocolo de transmissão de controle de fluxo (SCTP) em clusters ativados com o GKE Dataplane V2 (pré-lançamento). O SCTP é um protocolo da camada de transporte que oferece transmissão confiável e orientada a mensagens. Para mais informações, consulte Implantar cargas de trabalho com SCTP.

Limitações

O GKE Dataplane V2 tem as seguintes limitações:

  • O GKE Dataplane V2 só pode ser ativado ao criar um novo cluster. Os clusters atuais não podem ser atualizados para usar o GKE Dataplane V2.
  • Em versões do GKE anteriores à 1.20.12-gke.500, se você ativar o GKE Dataplane V2 com o DNSCache NodeLocal, não será possível configurar pods com dnsPolicy: ClusterFirstWithHostNet. seus pods vão passar por erros de resolução de DNS.
  • A partir da versão 1.21.5-gke.1300 do GKE, o GKE Dataplane V2 não oferece suporte às APIs CRD CiliumNetworkPolicy ou CiliumClusterwideNetworkPolicy. A partir das versões 1.28.6-gke.1095000 e 1.29.1-gke.1016000 do GKE, é possível ativar o CiliumClusterwideNetworkPolicy em clusters novos ou atuais.
  • Os balanceadores de carga de rede de passagem internos que foram criados manualmente e associados a um serviço do tipo NodePort não são compatíveis.
  • Como o GKE Dataplane V2 otimiza o processamento de pacotes do kernel eBPF usando eBPF, o desempenho do seu pod poderá ser afetado se você tiver cargas de trabalho com um alto desligamento de pods. O foco principal do GKE Dataplane V2 é alcançar o eBPF ideal.
  • Há um problema conhecido com serviços de vários clusters com várias portas (TCP/UDP) no GKE Dataplane V2. Para mais informações, consulte Serviços MCS com várias portas.
  • O GKE Dataplane V2 usa cilium em vez de kube-proxy para implementar os serviços do Kubernetes. O kube-proxy é mantido e desenvolvido pela comunidade do Kubernetes. Portanto, é mais provável que novos recursos para serviços sejam implementados em kube-proxy antes de serem implementados em cilium para o GKE Dataplane V2. Um exemplo de recurso para serviços que foi implementado primeiro em kube-proxy é o KEP-1669: endpoints de encerramento de proxy.
  • Para serviços NodePort que executam a versão 1.25 ou anterior usando intervalos SNAT e PUPI padrão, adicione o intervalo de PUPI dos pods em nonMasqueradeCIDRs no ConfigMap ip-masq-agent para evitar problemas de conectividade.
  • Em alguns casos, os pods do agente do GKE Dataplane V2 (anetd) podem consumir uma quantidade significativa de recursos de CPU, até duas ou três vCPUs por instância. Isso ocorre quando há um grande volume de conexões TCP abertas e fechadas rapidamente no nó. Para atenuar esse problema, recomendamos a implementação de sinais de atividade para chamadas HTTP e o pool de conexões para as cargas de trabalho relevantes.

  • O uso de memória informado dos pods do agente do GKE Dataplane V2 (anetd) depende da memória total disponível no nó. Os nós com maior memória total informam um uso maior de memória para os pods anetd. Os pods anetd não usam mais memória. O uso informado aumenta porque essa métrica inclui a reserva de memória do mapa eBPF.

    No GKE, a reserva de memória para os maiores mapas eBPF é de 0,25% da memória total do nó. Mais memória pode ser reservada para outros recursos específicos do GKE.

  • Os clusters do GKE Dataplane V2 que executam a versão 1.27 ou anterior do plano de controle não são compatíveis com o campo .spec.internalTrafficPolicy do serviço. A política de tráfego interno efetiva de um serviço é Cluster. Os back-ends em qualquer nó são considerados como candidatos para resolução de serviço. Para mais informações sobre o campo, consulte Política de tráfego interno do serviço.

  • O GKE Dataplane V2 usa o eBPF para gerenciar o tráfego de rede do cluster. Se você instalar um aplicativo de terceiros que também usa eBPF, ele poderá interferir no GKE Dataplane V2. Por exemplo, usar o Retina com o GKE Dataplane V2 pode impedir que seus pods se conectem aos serviços. Isso acontece porque os programas eBPF do Retina podem prejudicar a forma como o GKE Dataplane V2 roteia o tráfego. Se você receber mensagens de erro indicando que o tráfego está sendo descartado porque está tentando acessar o endereço IP do serviço diretamente, talvez você esteja enfrentando esse problema. Isso acontece porque os pods não podem acessar diretamente o endereço IP do serviço, e o tráfego precisa passar pelos mecanismos de roteamento do Dataplane V2. Para mais informações, consulte Problemas de incompatibilidade com a tela Retina.

GKE Dataplane V2 e kube-proxy

O GKE Dataplane V2 não usa o kube-proxy, exceto nos pools de nós do Windows Server nas versões 1.25 e anteriores do GKE.

Aplicação da política de rede sem o GKE Dataplane V2

Consulte Como usar a aplicação de política de rede para instruções sobre como ativar a aplicação de política de rede em clusters que não usam o GKE Dataplane V2.

A seguir