GKE Dataplane V2

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

En esta página se da por hecho que conoces las redes de los clústeres de GKE.

Descripción general de GKE Dataplane V2

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

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

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

Cómo funciona GKE Dataplane V2

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

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

Ruta de un paquete a través de un nodo mediante GKE Dataplane V2.

GKE despliega 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 topologías de red en eBPF. Los anetdpods se ejecutan en el espacio de nombres kube-system.

GKE Dataplane V2 y NetworkPolicy

GKE Dataplane V2 se implementa mediante Cilium. El plano de datos antiguo de GKE se implementa mediante Calico.

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

Ventajas de GKE Dataplane V2

Escalabilidad

GKE Dataplane V2 tiene características de escalabilidad diferentes a las del plano de datos antiguo.

En las versiones de GKE en las que GKE Dataplane V2 no usa kube-proxy y no depende de iptables para el enrutamiento de servicios, GKE elimina algunos cuellos de botella relacionados con iptables, como el número de servicios.

GKE Dataplane V2 se basa en mapas eBPF que están limitados a 260.000 endpoints en todos los servicios.

Seguridad

Kubernetes NetworkPolicy está siempre activado en los clústeres con GKE Dataplane V2. No tienes que instalar ni gestionar 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 el CRD de registro en tu clúster para ver cuándo permiten y deniegan las conexiones tus pods.

Coherencia

GKE Dataplane V2 ofrece 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:

Especificaciones GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
Número de nodos por clúster 7,500 500 500
Número de pods por clúster 200.000 15.000 27.500
Número de pods detrás de un servicio 10.000 1000 1000
Número de servicios ClusterIP 10.000 1000 1000
Número de servicios de tipo LoadBalancer por clúster 750 500 1000

GKE Dataplane V2 mantiene un mapa de servicios para hacer un seguimiento de los servicios que hacen referencia a los pods como sus backends. El número de backends de Pod de cada servicio sumado en todos los servicios debe caber en el mapa de servicios, que puede contener hasta 260.000 entradas. Si se supera este límite, es posible que tu clúster no funcione correctamente.

Aumento del límite de nodos a 7500 en la versión 1.31

A partir de la versión 1.31 de Kubernetes, el límite de 5000 nodos por clúster de GKE Dataplane V2 se ha aumentado a 7500. Se siguen aplicando las condiciones impuestas anteriormente a los clústeres (límite de 5000 nodos).

Aumento del límite de nodos a 5000 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 ha aumentado a 5000, y se han impuesto las siguientes condiciones adicionales a los clústeres:

  • Clústeres que usan Private Service Connect. Para comprobar si tu clúster usa Private Service Connect, consulta Clústeres con Private Service Connect.
  • Solo clústeres regionales
  • Solo los clústeres creados con la versión 1.23 de GKE o posterior tienen un límite de 5000 nodos. Es posible que los clústeres creados con versiones anteriores de GKE requieran aumentar la cuota de tamaño del clúster.
  • Los clústeres que usan el CRD CiliumNetworkPolicy (Cilium) no pueden escalar a 5000 nodos. La CRD CiliumClusterwideNetworkPolicy admite hasta 5000 nodos.

Servicios LoadBalancer en Google Distributed Cloud

El número de servicios LoadBalancer admitidos en Google Distributed Cloud depende del modo de balanceador de carga que se esté usando. Google Distributed Cloud admite 500 servicios LoadBalancer cuando se usa el modo de balanceo de carga incluido (Seesaw) y 250 cuando se usa el modo de balanceo de carga integrado con F5. Para obtener más información, consulta Escalabilidad.

Desplegar cargas de trabajo con SCTP

Puedes desplegar cargas de trabajo que usen el protocolo de transmisión de control de flujo (SCTP) en clústeres que tengan habilitado Dataplane V2 de GKE (versión preliminar). SCTP es un protocolo de capa de transporte que proporciona una transmisión fiable orientada a mensajes. Para obtener más información, consulta Implementar cargas de trabajo con SCTP.

Limitaciones

GKE Dataplane V2 tiene las siguientes limitaciones:

  • GKE Dataplane V2 solo se puede habilitar al crear un clúster. Los clústeres no se pueden actualizar para usar GKE Dataplane V2.
  • En las versiones de GKE anteriores a la 1.20.12-gke.500, si habilitas GKE Dataplane V2 con NodeLocal DNSCache, no podrás configurar pods con dnsPolicy: ClusterFirstWithHostNet o tus pods tendrán errores de resolución de DNS.
  • A partir de la versión 1.21.5-gke.1300 de GKE, GKE Dataplane V2 no admite las APIs de CRD 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 ya creados.
  • No se admiten los balanceadores de carga de red de paso a través internos creados manualmente y asociados a un servicio de tipo NodePort.
  • Como GKE Dataplane V2 optimiza el procesamiento de paquetes del kernel eBPF mediante eBPF, el rendimiento de tus pods puede verse afectado si tienes cargas de trabajo con una alta rotación de pods. El objetivo principal de GKE Dataplane V2 es conseguir un eBPF óptimo.
  • Hay un problema conocido con los servicios de varios clústeres con varios puertos (TCP/UDP) en GKE Dataplane V2. Para obtener más información, consulta Servicios MCS con varios puertos.
  • GKE Dataplane V2 usa cilium en lugar de kube-proxy para implementar servicios de Kubernetes. kube-proxy lo mantiene y desarrolla la comunidad de Kubernetes, por lo que es más probable que las funciones nuevas de los servicios se implementen en kube-proxy antes de que se implementen en cilium para GKE Dataplane V2. Un ejemplo de función de servicios que se implementó por primera vez en kube-proxy es KEP-1669: Proxy Terminating Endpoints.
  • En el caso de los servicios NodePort que ejecuten la versión 1.25 o una anterior y que usen los intervalos predeterminados de SNAT y PUPI, debes añadir el intervalo PUPI de los pods en nonMasqueradeCIDRs en el ip-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 vCPUs por instancia. Esto ocurre cuando se abre y se cierra un gran volumen de conexiones TCP rápidamente en el nodo. Para mitigar este problema, te recomendamos que implementes keep-alives para las llamadas HTTP y la agrupación de conexiones para las cargas de trabajo pertinentes.

  • El uso de memoria notificado de los pods del agente de GKE Dataplane V2 (anetd) depende de la memoria total disponible en el nodo. Los nodos que tienen más memoria total registran un mayor uso de memoria para los pods anetd. Los anetd pods no usan más memoria, sino que el uso registrado aumenta porque esta métrica incluye la reserva de memoria del mapa eBPF.

    En GKE, la reserva de memoria para los mapas eBPF más grandes es el 0,25% de la memoria total del nodo. Es posible que se reserve memoria adicional para otras funciones específicas de GKE.

  • Los clústeres de GKE Dataplane V2 que ejecutan la versión 1.27 o inferior del plano de control no admiten el campo Servicio .spec.internalTrafficPolicy. La política de tráfico interno efectiva de un servicio es Cluster; los back-ends de cualquier nodo se consideran candidatos para la resolución de servicios. Para obtener más información sobre el campo, consulta la política de tráfico interno de servicios.

  • GKE Dataplane V2 usa eBPF para gestionar el tráfico de red de tu clúster. Si instalas una aplicación de terceros que también usa eBPF, puede interferir con GKE Dataplane V2. Por ejemplo, si usas Retina con GKE Dataplane V2, puedes evitar que tus pods se conecten a los servicios. Esto ocurre porque los programas eBPF de Retina pueden alterar la forma en que Dataplane V2 de GKE enruta el tráfico. Si ves mensajes de error que indican que se está descartando tráfico porque se está intentando acceder directamente a la dirección IP del servicio, es posible que tengas este problema. Esto se debe a que los pods no pueden acceder directamente a la dirección IP del servicio y el tráfico debe pasar por los mecanismos de enrutamiento de Dataplane V2. Para obtener más información, consulta Problemas de incompatibilidad con Retina.

GKE Dataplane V2 y kube-proxy

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

Aplicación de políticas de red sin GKE Dataplane V2

Consulta las instrucciones para habilitar la implementación obligatoria de la política de red en clústeres que no usen GKE Dataplane V2 en la sección Usar la implementación obligatoria de la política de red.

Siguientes pasos