GKE Dataplane V2

En esta página, se ofrece una descripción general de lo que hace GKE Dataplane V2 y cómo funciona.

Antes de leer este documento, asegúrate de conocer las herramientas de redes dentro de los clústeres de GKE.

Descripción general de GKE Dataplane V2

GKE Dataplane V2 es un plano de datos optimizado para las herramientas de redes de Kubernetes. GKE Dataplane V2 proporciona lo siguiente:

  • Una experiencia del usuario coherente para las herramientas de redes
  • Visibilidad en tiempo real de la actividad de red.
  • Una arquitectura más simple que facilita la administración y la solución de problemas de los clústeres.

GKE Dataplane V2 está habilitado de forma predeterminada para todos los clústeres nuevos de Autopilot.

Cómo funciona GKE Dataplane V2

GKE Dataplane V2 se implementa mediante eBPF. A medida que los paquetes llegan a un nodo de GKE, los programas de eBPF instalados en el kernel deciden cómo enrutar y procesar los paquetes. A diferencia del procesamiento de paquetes con iptables, los programas de eBPF pueden usar metadatos específicos de Kubernetes en el paquete. Esto permite que GKE Dataplane V2 procese paquetes de red en el kernel de manera más eficiente y, luego, informe acciones anotadas al espacio del usuario para el registro.

En el siguiente diagrama, se muestra la ruta de un paquete a través de un nodo con GKE Dataplane V2:

GKE implementa el controlador de GKE Dataplane V2 como un DaemonSet llamado anetd en cada nodo del clúster. anetd interpreta los objetos de Kubernetes y programa las topologías de red en eBPF. Los Pods anetd se ejecutan en el espacio de nombres kube-system.

GKE Dataplane V2 y NetworkPolicy

GKE Dataplane V2 se implementa con Cilium. El plano de datos heredado para GKE se implementa mediante Calico.

Ambas tecnologías administran NetworkPolicy de Kubernetes. Cilium usa eBPF y la interfaz de red de contenedor (CNI) Calico usa iptables en el kernel de Linux.

Ventajas de GKE Dataplane V2

Escalabilidad

GKE Dataplane V2 tiene características de escalabilidad diferentes a la de los planos de datos heredados.

Para las versiones de GKE en las que GKE Dataplane V2 no usa kube-proxy y no se basa en iptables para el enrutamiento de servicios, GKE quita algunos cuellos de botella relacionados con iptables, como la cantidad de servicios.

GKE Dataplane V2 se basa en mapas de eBPF que están limitados a 64,000 extremos en todos los servicios.

Seguridad

La política de red de Kubernetes siempre está activada en clústeres con GKE Dataplane V2. No es necesario que instales y administres complementos de software de terceros, como Calico, para aplicar la política de red.

Operaciones

Cuando creas un clúster con GKE Dataplane V2, el registro de políticas de red está integrado. Configura la CRD de registro en tu clúster para ver cuándo los Pods permiten y rechazan las conexiones.

Coherencia

GKE Dataplane V2 proporciona una experiencia de red coherente.

Para obtener más información, consulta Disponibilidad de GKE Dataplane V2.

Especificaciones técnicas de GKE Dataplane V2

GKE Dataplane V2 admite clústeres con las siguientes especificaciones:

Especificación GKE Google Distributed Cloud Google Distributed Cloud
Cantidad de nodos por clúster 5,000 500 500
Cantidad de Pods por clúster 50,000 15,000 27,500
Cantidad de Services LoadBalancer por clúster 750 500 1,000

GKE Dataplane V2 mantiene un mapa de Services para hacer un seguimiento de qué Services hacen referencia a qué Pods como sus backends. La cantidad de backends de Pods para cada Service sumado en todos los Services debe caber en el mapa de Services, que puede contener hasta 64,000 entradas. Si se excede este límite, es posible que tu clúster no funcione según lo previsto.

Aumento del límite de nodos en la versión 1.23

A partir de la versión 1.23 de Kubernetes, el límite de 500 nodos por clúster de GKE Dataplane V2 se aumentó a 5,000, con las siguientes condiciones adicionales impuestas a los clústeres:

  • Clústeres privados o públicos que usan Private Service Connect Para verificar si tu clúster usa Private Service Connect, consulta Clústeres públicos con Private Service Connect.
  • Solo clústeres regionales
  • Solo los clústeres que se crearon con la versión 1.23 o posterior de GKE tienen un límite de 5,000 nodos elevados. Los clústeres que se crearon con versiones anteriores de GKE pueden requerir elevar una cuota de tamaño del clúster. Comunícate con el equipo de asistencia para recibir ayuda.
  • Los clústeres que usan CRD de Cilium (CiliumNetworkPolicy y CiliumClusterwideNetworkPolicy) no pueden escalar a 5,000 nodos.

Objetos Service LoadBalancer en Google Distributed Cloud

La cantidad de objetos Service LoadBalancer compatibles con Google Distributed Cloud depende del modo de balanceador de cargas que se usa. Google Distributed Cloud admite 500 objetos Service LoadBalancer cuando se usa el modo de balanceo de cargas agrupado (Seesaw) y 250 cuando se usa el modo de balanceo de cargas integrado con F5. Para obtener más información, consulta Escalabilidad.

Limitaciones

GKE Dataplane V2 tiene las siguientes limitaciones:

  • GKE Dataplane V2 solo se puede habilitar cuando se crea un clúster nuevo. Los clústeres existentes no pueden actualizarse para usar GKE Dataplane V2.
  • En las versiones de GKE anteriores a 1.20.12-gke.500, si habilitas GKE Dataplane V2 con NodeLocal DNSCache, no puedes configurar Pods con dnsPolicy: ClusterFirstWithHostNet, o tus Pods experimentarán errores de resolución de DNS.
  • A partir de la versión 1.21.5-gke.1300 de GKE, GKE Dataplane V2 no es compatible con las APIs de CRD de CiliumNetworkPolicy o CiliumClusterwideNetworkPolicy. A partir de las versiones 1.28.6-gke.1095000 y 1.29.1-gke.1016000 de GKE, puedes habilitar CiliumClusterwideNetworkPolicy en clústeres nuevos o existentes.
  • No se admiten los balanceadores de cargas de red de transferencia internos creados de forma manual asociados con un Service de tipo NodePort.
  • Debido a que GKE Dataplane V2 optimiza el procesamiento de paquetes del kernel de eBPF a través de eBPF, el rendimiento de tu Pod podría verse afectado si tienes cargas de trabajo con una alta deserción de Pods. El enfoque principal de GKE Dataplane V2 es lograr un eBPF óptimo.
  • GKE Dataplane V2 usa cilium en lugar de kube-proxy para implementar lo objetos Service de Kubernetes. La comunidad de Kubernetes mantiene y desarrolla kube-proxy, por lo que es más probable que las funciones nuevas de los objetos Service se implementen en kube-proxy antes de que se implementen en cilium para GKE Dataplane V2. Un ejemplo de una función de Services que se implementó por primera vez en kube-proxy es KEP-1669: extremos de finalización del proxy.
  • Para los Services de NodePort que ejecutan la versión 1.25 o anteriores con rangos de SNAT y PUPI predeterminados, debes agregar el rango de PUPI de los Pods en nonMasqueradeCIDRs en elip-masq-agent ConfigMap para evitar problemas de conectividad.
  • En algunos casos, los Pods del agente de GKE Dataplane V2 (anetd) pueden consumir una cantidad significativa de recursos de CPU, hasta dos o tres CPU virtuales por instancia. Esto ocurre cuando hay un gran volumen de conexiones TCP que se abren y cierran con rapidez en el nodo. Para mitigar este problema, recomendamos implementar mensajes keep-alive para llamadas HTTP y agrupación de conexiones en las cargas de trabajo relevantes.
  • Los clústeres de GKE Dataplane V2 que ejecutan la versión 1.27 o anterior del plano de control no son compatibles con el campo .spec.internalTrafficPolicy del Service. La política de tráfico interno vigente para un Service es Cluster. Los backends en cualquier nodo se consideran como candidatos para la resolución del Service. Para obtener más información sobre el campo, consulta Política de tráfico interno del Service.

GKE Dataplane V2 y kube-proxy

GKE Dataplane V2 no usa kube-proxy.

Aplicación de la política de red sin GKE Dataplane V2

Consulta Usa la aplicación de la política de red para obtener instrucciones sobre cómo habilitar la aplicación de la política de red en clústeres que no usan GKE Dataplane V2.

¿Qué sigue?