GKE Dataplane V2

Esta página oferece 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 em 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:

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

Programas eBPF personalizados

O GKE Dataplane V2 usa programas eBPF para gerenciar o tráfego de rede, incluindo roteamento, balanceamento de carga e aplicação de políticas de rede. Como esses programas são essenciais para a conectividade de rede, o GKE não oferece suporte à instalação de programas eBPF personalizados em nós que usam o GKE Dataplane V2. Os programas eBPF personalizados podem interferir nos programas do GKE Dataplane V2 e interromper a rede do cluster.

Vantagens do GKE Dataplane V2

O GKE Dataplane V2 oferece os seguintes benefícios:

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 15.000 500 500
Número de pods por cluster 400.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 localização do cluster do GKE Dataplane V2:

  • Clusters regionais: até 5.000, 15.000 ou 65.000 nós por cluster. Nem todos os aumentos de nós são automáticos. Dependendo da contagem de nós de destino, há requisitos de infraestrutura específicos, e talvez seja necessário entrar em contato com o Cloud Customer Care. O escalonamento para 65.000 nós requer o modo otimizado para escalonamento do Dataplane V2, que desativa a aplicação da política de rede. Para informações detalhadas, consulte Limites e requisitos de tamanho do cluster.
  • Clusters zonais: até 1.000 nós.

Para atingir limites de escalonamento de nós além de 5.000 nós em clusters regionais, seu ambiente 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.
  • Os clusters que usam a CRD CiliumNetworkPolicy são restritos a limites de cluster zonais de até 1.000 nós. Use a CRD CiliumClusterwideNetworkPolicy para oferecer suporte ao escalonamento de 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.

Suporte ao Maglev

Para clusters do GKE que executam a versão 1.36.0-gke.2882000 e mais recentes, é possível configurar serviços para usar o algoritmo hashing consistente Maglev para seleção de back-end.

Por padrão, os serviços do Kubernetes usam o algoritmo random para selecionar back-ends. O algoritmo random pode fazer com que conexões íntegras sejam redirecionadas e redefinidas quando o conjunto de pods de back-end muda (por exemplo, durante eventos de escalonamento). O Maglev atenua isso continuando a rotear o tráfego para o back-end atribuído de uma conexão enquanto ele permanecer íntegro, mesmo quando outros pods forem adicionados ou removidos.

Benefícios de usar o algoritmo Maglev

O uso do algoritmo Maglev oferece os seguintes benefícios:

  • Ele pode melhorar a estabilidade da conexão direcionando o tráfego de uma conexão para o mesmo back-end.
  • Ele pode atenuar problemas de conexão quando os pods de back-end são adicionados ou removidos, por exemplo, durante reinicializações de pods.

Limitações do uso do algoritmo Maglev

O uso do algoritmo Maglev pode ser intensivo em recursos:

  • Ele pode causar aumento do uso da memória no anetd em todos os clusters. Para mais informações, consulte a próxima seção, "Considerações sobre o uso da memória do Maglev".
  • Ele pode estar conectado a um uso maior da CPU anetd (até três vezes mais) durante as mudanças de back-end.

Considerações sobre o uso da memória do Maglev

Para rastrear conexões e back-ends, o algoritmo Maglev usa uma tabela de hash: ele faz o hash da tupla de 5 pacotes (endereço IP de origem, endereço IP de destino, porta de origem, porta de destino e protocolo).

O tamanho da tabela de pesquisa é configurado para 16.381 entradas. Como cada entrada tem um tamanho de 4 bytes, um serviço configurado para usar o algoritmo Maglev requer 65,5 KB (16.381 × 4 bytes) da memória alocável de cada nó.

Número de serviços com o Maglev ativado Uso da memória adicional
100 6,5 MB
1.000 65 MB
10.000 650 MB

Como aplicar o algoritmo Maglev

Para aplicar o algoritmo Maglev a um serviço do tipo NodePort ou LoadBalancer, adicione a anotação gke.networking.io/lb-algorithm: "maglev" aos metadados do serviço durante a criação dele.

Exemplo:

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

A anotação gke.networking.io/lb-algorithm entra em vigor durante a criação do serviço. Para mudar o algoritmo de um serviço atual, é necessário excluir e recriar o serviço. A mudança do valor da anotação sem recriação causa um comportamento inconsistente. anetd em novos nós tenta usar o algoritmo recém-configurado, enquanto os pods atuais continuam usando o algoritmo anterior.

Implantar cargas de trabalho com SCTP

É possível implantar cargas de trabalho que usam o Stream Control Transmission Protocol (SCTP) em clusters ativados com o GKE Dataplane V2. O SCTP é um protocolo de 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.
  • 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.
  • 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.
  • 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 da memória informado dos pods do agente do GKE Dataplane V2 (anetd) depende da memória total disponível no nó. Os nós que têm maior memória total informam maior uso da memória para os anetd Pods. 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ó. Memória adicional pode ser reservada para outros recursos específicos do GKE.

  • 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 o eBPF, ele poderá interferir no GKE Dataplane V2. Por exemplo, o uso do Retina com o GKE Dataplane V2 pode impedir que os pods se conectem aos serviços. Isso acontece porque os programas eBPF do Retina podem interromper a maneira 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 esteja enfrentando esse problema. Isso ocorre porque os pods não têm permissão para 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 do Retina.

  • Pacotes ICMP fragmentados não são aceitos e são descartados pelo GKE Dataplane V2.

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