GKE Dataplane V2

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

Antes de ler esta página, é preciso entender 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:

  • 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 está ativado para todos os novos clusters do Autopilot nas versões 1.22.7-gke.1500 e posteriores, 1.23.4-gke.1500 e posteriores e todas as versões 1.24 e posteriores.

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 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 64.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 Google Distributed Cloud
Número de nós por cluster 5.000 500 500
Número de pods por cluster 50.000 15.000 27.500
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é 64.000 entradas. Se esse limite for excedido, talvez o cluster não funcione conforme o esperado.

Aumento do limite de nós na versão 1.23

A partir da versão 1.23 do Kubernetes, o limite de 500 nós por cluster do GKE Dataplane V2 foi elevado para 5.000, com as seguintes condições adicionais impostas aos clusters:

  • Clusters particulares ou públicos que usam o Private Service Connect. Para verificar se o cluster usa o Private Service Connect, consulte Clusters públicos com o Private Service Connect.
  • Somente clusters regionais
  • 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 CRDs do Cilium (CiliumNetworkPolicy e CiliumClusterwideNetworkPolicy) não podem ser escalonados para 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.

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.
  • 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.

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