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 esta página, debes comprender 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 de clústeres de GKE y GKE que está optimizado para las herramientas de redes de Kubernetes. GKE Dataplane V2 proporciona lo siguiente:

  • Una experiencia del usuario coherente para las redes en GKE y todos los entornos de clústeres de GKE Consulta Disponibilidad de GKE Dataplane V2 para obtener información sobre los entornos compatibles con GKE Dataplane V2.
  • 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 para todos los clústeres nuevos de Autopilot en las versiones 1.22.7-gke.1500 y posteriores, 1.23.4-gke.1500 y posteriores, y todas las versiones 1.24 y posteriores.

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 la funcionalidad 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, en la actualidad, 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.

Operations

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 está disponible y proporciona las mismas características en GKE y en otros entornos de clústeres de GKE. 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 GKE en VMware Nube virtual distribuida de Google para Bare Metal
Cantidad de nodos por clúster 5000* 500 500
Cantidad de Pods por clúster 50,000 15,000 27,500
Cantidad de servicios LoadBalancer por clúster 750 500 1,000

GKE Dataplane V2 mantiene un mapa de servicio para hacer un seguimiento de qué servicios hacen referencia a qué Pods son sus backends. La cantidad de backends del Pod para cada servicio sumado en todos los servicios debe caber en el mapa del servicio, 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.

* A partir de la versión 1.23 de Kubernetes, el límite de 500 nodos por clúster de 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 CRDs de Cilium (CiliumNetworkPolicy y CiliumClusterwideNetworkPolicy) no pueden escalar a 5,000 nodos.

La cantidad de servicios LoadBalancer compatibles con GKE en VMware depende del modo de balanceador de cargas que se usa. Se admiten 500 servicios LoadBalancer en clústeres de GKE alojados en VMware cuando se usa el modo de balanceo de cargas en paquetes (Seesaw) y se admiten 250 cuando se usa el modo de balanceo de cargas integrado con F5. Consulta Escalabilidad para obtener más información.

Limitaciones

Las siguientes limitaciones se aplican en GKE, GKE en VMware y todos los otros entornos:

  • 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.
  • 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. Esta limitación se quitó a partir de la versión 1.20.12-gke.500 (estable).
  • 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.
  • No se admiten los balanceadores de cargas de red de transferencia internos creados de forma manual asociados con un Service de tipo NodePort.
  • Existe un problema conocido con Services de varios clústeres con varios puertos (TCP/UDP) en GKE Dataplane V2. Para obtener más información, consulta Servicios de MCS con varios puertos.
  • GKE Dataplane V2 usa cilium en lugar de kube-proxy para implementar los servicios 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 servicios que se implementó por primera vez en kube-proxy es KEP-1669: extremos de finalización del proxy.
  • Para un Service de tipo NodePort creado en un clúster con GKE Dataplane V2 que ejecuta la versión 1.25 o anterior, rangos PUPI y SNAT predeterminados, es necesario agregar el rango PUPI de los Pods en nonMasqueradeCIDRs (ip-masq-agent ConfigMap) para evitar un problema 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. A fin de mitigar este problema, recomendamos implementar keep-alive para llamadas HTTP y agrupación de conexiones en las cargas de trabajo relevantes.

GKE Dataplane V2 y kube-proxy

GKE Dataplane V2 no usa kube-proxy, excepto en los grupos de nodos de Windows Server en versiones de GKE 1.25 y anteriores.

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?