GKE Dataplane V2

Esta página fornece uma vista geral do que o GKE Dataplane V2 faz e como funciona.

Esta página pressupõe que tem conhecimentos sobre a rede dentro dos clusters do GKE.

Vista geral do GKE Dataplane V2

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

  • Uma experiência do utilizador consistente para o trabalho em rede.
  • Visibilidade em tempo real da atividade da rede.
  • Uma arquitetura mais simples que facilita a gestão e a resolução de problemas dos clusters.

O GKE Dataplane V2 está ativado por predefinição para todos os novos clusters do Autopilot.

Como funciona o GKE Dataplane V2

O GKE Dataplane V2 é implementado através do eBPF. À medida que os pacotes chegam a um nó do GKE, os programas eBPF instalados no kernel decidem como encaminhar 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. Isto permite que o GKE Dataplane V2 processe pacotes de rede no kernel de forma mais eficiente e comunique ações anotadas ao espaço do utilizador para registo.

O diagrama seguinte mostra o caminho de um pacote através de um nó com o GKE Dataplane V2:

O caminho de um pacote através de um nó com o GKE Dataplane V2.

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

GKE Dataplane V2 e NetworkPolicy

O GKE Dataplane V2 é implementado através do Cilium. O plano de dados antigo para o GKE é implementado através do Calico.

Ambas as tecnologias gerem a NetworkPolicy do Kubernetes. O Cilium usa o eBPF e a interface de rede de contentores (CNI) do Calico usa o iptables no kernel do Linux.

Vantagens do GKE Dataplane V2

Escalabilidade

O GKE Dataplane V2 tem características de escalabilidade diferentes do dataplane antigo.

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

O GKE Dataplane V2 baseia-se em mapas eBPF que estão limitados a 260 000 pontos finais em todos os serviços.

Segurança

A NetworkPolicy do Kubernetes está sempre ativada em clusters com o GKE Dataplane V2. Não tem de instalar nem gerir suplementos de software de terceiros, como o Calico, para aplicar a política de rede.

Operações

Quando cria um cluster com o GKE Dataplane V2, o registo da política de rede está integrado. Configure o CRD de registo no seu cluster para ver quando as ligações são permitidas e recusadas pelos seus 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 suporta clusters com as seguintes especificações:

Especificação GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
Número de nós por cluster 7500 500 500
Número de pods por cluster 200 000 15 000 27 500
Número de pods atrás de um serviço 10 000 1000 1000
Número de serviços de IP de cluster 10 000 1000 1000
Número de serviços LoadBalancer por cluster 750 500 1000

O GKE Dataplane V2 mantém um mapa de serviços para monitorizar os serviços que se referem aos pods como respetivos back-ends. O número de back-ends de agrupamentos para cada serviço somado em todos os serviços tem de caber no mapa de serviços, que pode conter até 260 000 entradas. Se este limite for excedido, o cluster pode não funcionar como previsto.

Aumento do limite de nós para 7500 na versão 1.31

A partir das versões 1.31 do Kubernetes, o limite de 5000 nós por cluster do GKE Dataplane V2 foi aumentado para 7500. As condições anteriormente impostas aos clusters (limite de 5000 nós) continuam a aplicar-se.

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

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

  • Clusters que usam o Private Service Connect. Para verificar se o seu cluster usa o Private Service Connect, consulte o artigo Clusters com o Private Service Connect.
  • Apenas clusters regionais
  • Apenas os clusters criados com a versão 1.23 ou posterior do GKE têm um limite de 5000 nós aumentado. Os clusters criados com versões anteriores do GKE podem exigir o aumento de uma quota de tamanho do cluster.
  • Os clusters que usam o CRD CiliumNetworkPolicy (Cilium) não podem ser dimensionados para 5000 nós. O CRD CiliumClusterwideNetworkPolicy suporta até 5000 nós.

Serviços de LoadBalancer no Google Distributed Cloud

O número de serviços LoadBalancer suportados no Google Distributed Cloud depende do modo do balanceador de carga que está a ser usado. O Google Distributed Cloud suporta 500 serviços LoadBalancer quando usa o modo de balanceamento de carga integrado (Seesaw) e 250 quando usa o modo de balanceamento de carga integrado com o F5. Para mais informações, consulte o artigo Escalabilidade.

Implemente cargas de trabalho com SCTP

Pode implementar cargas de trabalho que usam o Protocolo de controlo de transmissão de streams (SCTP) em clusters ativados com o GKE Dataplane V2 (pré-visualização). O SCTP é um protocolo da camada de transporte que oferece uma transmissão fiável orientada por mensagens. Para mais informações, consulte o artigo Implemente cargas de trabalho com SCTP.

Limitações

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

  • O GKE Dataplane V2 só pode ser ativado quando cria um novo cluster. Não é possível atualizar os clusters existentes para usar o GKE Dataplane V2.
  • Nas versões do GKE anteriores à 1.20.12-gke.500, se ativar o GKE Dataplane V2 com o NodeLocal DNSCache, não pode configurar pods com dnsPolicy: ClusterFirstWithHostNet, ou os seus pods vão ter erros de resolução de DNS.
  • A partir da versão 1.21.5-gke.1300 do GKE, o GKE Dataplane V2 não suporta as APIs CRD CiliumNetworkPolicy nem CiliumClusterwideNetworkPolicy. A partir das versões 1.28.6-gke.1095000 e 1.29.1-gke.1016000 do GKE, pode ativar a CiliumClusterwideNetworkPolicy em clusters novos ou existentes.
  • Os balanceadores de carga de rede de encaminhamento interno criados manualmente associados a um serviço do tipo NodePort não são suportados.
  • Uma vez que o GKE Dataplane V2 otimiza o processamento de pacotes do kernel eBPF através da utilização do eBPF, o desempenho dos seus pods pode ser afetado se tiver cargas de trabalho com uma elevada rotatividade de pods. O foco principal do GKE Dataplane V2 é alcançar o eBPF ideal.
  • Existe um problema conhecido com os serviços de vários clusters com várias portas (TCP/UDP) no GKE Dataplane V2. Para mais informações, consulte o artigo Serviços MCS com várias portas.
  • O GKE Dataplane V2 usa o cilium em vez do kube-proxy para implementar os serviços do Kubernetes. kube-proxy é mantido e desenvolvido pela comunidade do Kubernetes, pelo que é mais provável que as novas funcionalidades dos serviços sejam implementadas no kube-proxy antes de serem implementadas no cilium para o GKE Dataplane V2. Um exemplo de uma funcionalidade de serviços que foi implementada pela primeira vez no kube-proxy é o KEP-1669: Proxy Terminating Endpoints.
  • Para os serviços NodePort que executam a versão 1.25 ou anterior com intervalos SNAT e PUPI predefinidos, tem de adicionar o intervalo PUPI dos pods em nonMasqueradeCIDRs no ip-masq-agent ConfigMap para evitar problemas de conetividade.
  • Em determinados casos, os pods do agente GKE Dataplane V2 (anetd) podem consumir uma quantidade significativa de recursos de CPU, até duas ou três vCPUs por instância. Isto ocorre quando existe um volume elevado de ligações TCP a serem abertas e fechadas rapidamente no nó. Para mitigar este problema, recomendamos que implemente keep-alives para chamadas HTTP e o agrupamento de ligações para as cargas de trabalho relevantes.

  • A utilização de memória comunicada dos pods do agente GKE Dataplane V2 (anetd) depende da memória total disponível no nó. Os nós com uma memória total mais elevada comunicam uma utilização de memória mais elevada para os pods anetd. Na verdade, os anetdpods não usam mais memória. A utilização comunicada aumenta porque esta 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ó. Pode ser reservada memória adicional para outras funcionalidades específicas do GKE.

  • Os clusters do GKE Dataplane V2 que executam a versão 1.27 ou inferior do plano de controlo não suportam o campo .spec.internalTrafficPolicy do serviço. A política de tráfego interno eficaz para um serviço é Cluster; os back-ends em qualquer nó são considerados candidatos para a resolução de serviços. Para mais informações sobre o campo, consulte a Política de Tráfego Interno de Serviços.

  • O GKE Dataplane V2 usa o eBPF para gerir o tráfego de rede do seu cluster. Se instalar uma aplicação de terceiros que também use o eBPF, esta pode interferir com o plano de dados V2 do GKE. Por exemplo, a utilização do Retina com o GKE Dataplane V2 pode impedir que os seus pods estabeleçam ligação aos serviços. Isto acontece porque os programas eBPF da Retina podem interromper a forma como o GKE Dataplane V2 encaminha o tráfego. Se vir mensagens de erro a indicar que o tráfego está a ser ignorado porque está a tentar alcançar diretamente o endereço IP do serviço, pode estar a deparar-se com este problema. Isto deve-se ao facto de os pods não poderem aceder diretamente ao endereço IP do serviço e o tráfego ter de passar pelos mecanismos de encaminhamento do Dataplane V2. Para mais informações, consulte o artigo Problemas de incompatibilidade com o Retina.

GKE Dataplane V2 e kube-proxy

O GKE Dataplane V2 não usa o kube-proxy, exceto em 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 o artigo Usar a aplicação da Política da Rede para obter instruções sobre como ativar a aplicação da Política da Rede em clusters que não usam o GKE Dataplane V2.

O que se segue?