Usa GKE Dataplane V2

En esta página, se explica cómo habilitar GKE Dataplane V2 para clústeres de Google Kubernetes Engine (GKE).

Los clústeres Autopilot nuevos tienen GKE Dataplane V2 habilitado en las versiones 1.22.7-gke.1500 y posteriores, y las versiones 1.23.4-gke.1500 y posteriores.

Crea un clúster de GKE con GKE Dataplane V2

Puedes habilitar GKE Dataplane V2 cuando creas clústeres nuevos con la versión de GKE 1.20.6-gke.700 y versiones posteriores mediante la CLI de gcloud o la API de Kubernetes Engine. También puedes habilitar GKE Dataplane V2 en vista previa cuando creas clústeres nuevos con la versión de GKE 1.17.9 y posteriores.

Console

Para crear un clúster nuevo con GKE Dataplane V2, realiza las siguientes tareas:

  1. Ve a la página de Google Kubernetes Engine en la consola de Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. Haz clic en Configurar para configurar un clúster estándar.

  4. En la sección Herramientas de redes, selecciona la casilla de verificación Habilitar Dataplane V2. La opción Habilitar la política de red de Kubernetes se inhabilita cuando seleccionas Habilitar Dataplane V2 porque la aplicación de la política de red está integrada en GKE Dataplane V2.

  5. Haga clic en Crear.

gcloud

Para crear un clúster nuevo con GKE Dataplane V2, usa el siguiente comando:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --release-channel CHANNEL_NAME \
    --region COMPUTE_REGION

Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre del clúster nuevo.
  • CHANNEL_NAME: Un canal de versiones que incluye la versión 1.20.6-gke.700 de GKE o una posterior. Si prefieres no usar un canal de versiones, también puedes usar la marca --version en lugar de --release-channel, con la especificación de la versión 1.20.6-gke.700 o posterior.
  • COMPUTE_REGION: es la región de Compute Engine del clúster. Para los clústeres zonales, usa --zone=COMPUTE_ZONE.

API

Para crear un clúster nuevo con GKE Dataplane V2, especifica el campo datapathProvider en el objeto networkConfig, en la solicitud create del clúster.

En el siguiente fragmento de código JSON, se muestra la configuración necesaria para habilitar GKE Dataplane V2:

"cluster":{
   "initialClusterVersion":"VERSION",
   "ipAllocationPolicy":{
      "useIpAliases":true
   },
   "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
   },
   "releaseChannel":{
      "channel":"CHANNEL_NAME"
   }
}

Reemplaza lo siguiente:

  • VERSION: Tu versión del clúster, que debe ser GKE 1.20.6-gke.700 o posterior.
  • CHANNEL_NAME: Un canal de versiones que incluye la versión 1.20.6-gke.700 de GKE o una posterior.

Soluciona problemas con GKE Dataplane V2

  1. Comprueba el estado de los Pods del sistema:

    kubectl -n kube-system get pods -l k8s-app=cilium -o wide
    

    Si GKE Dataplane V2 está en ejecución, el resultado incluye Pods con el prefijo anetd-. anetd es el controlador de herramientas de redes para GKE Dataplane V2.

  2. Si el problema es con los servicios o la aplicación de la política de red, verifica los registros del Pod anetd:

    kubectl -n kube-system get events --field-selector involvedObject.name=anetd
    kubectl -n kube-system logs -l k8s-app=cilium
    
  3. Si falla la creación de un Pod, revisa los registros de kubelet para obtener pistas. Puedes hacer esto en GKE mediante ssh:

    gcloud compute ssh NODE -- sudo journalctl -u kubelet
    

    Reemplaza NODE con el nombre de la instancia de VM.

Problemas conocidos

No se aplican los rangos de puertos de la Política de red

Si especificas un campo endPort en una política de red en un clúster que tiene habilitado GKE Dataplane V2, no se aplicará

A partir de GKE 1.22, la API de Kubernetes Network Policy te permite especificar un rango de puertos en los que se aplica la política de red. Esta API es compatible con clústeres con la política de red Calico, pero no con clústeres con GKE Dataplane V2.

Puedes verificar el comportamiento de tus objetos NetworkPolicy si los vuelves a leer después de escribirlos en el servidor de la API. Si el objeto todavía contiene el campo endPort, la función se aplica. Si falta el campo endPort, la función no se aplica. En todos los casos, el objeto almacenado en el servidor de la API es la fuente de información de la política de red.

Para obtener más información, consulta KEP-2079: Política de red que admite rangos de puertos.

Los Pods muestran un mensaje de error de failed to allocate for range 0: no IP addresses available in range set

Versiones de GKE afectadas: 1.18 y posteriores

Los clústeres de GKE que ejecutan grupos de nodos que usan containerd y tienen GKE Dataplane V2 habilitado pueden experimentar problemas de filtración de direcciones IP y agotar todas las direcciones IP de Pods en un nodo. Un Pod programado en un nodo afectado muestra un mensaje de error similar al siguiente:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Para obtener más información sobre el problema, consulta el problema número 5768 de containerd.

Para solucionar este problema, actualiza tu clúster a una de las siguientes versiones de GKE:

  • 1.23.4-gke.1600 o posterior.
  • 1.22.8-gke.200 o posterior.
  • 1.21.11-gke.1100 o posterior.
  • 1.20.15-gke.5200 o posterior.

Soluciones alternativas

Puedes mitigar este problema si borras las direcciones IP de Pods que se filtraron del nodo.

Para borrar las direcciones IP de Pods que se filtraron, obtén credenciales de autenticación para el clúster y realiza los siguientes pasos:

  1. Guarda el siguiente manifiesto como una secuencia de comandos de shell llamada cleanup.sh:

    for hash in $(sudo find /var/lib/cni/networks/gke-pod-network -iregex '/var/lib/cni/networks/gke-pod-network/[0-9].*' -exec head -n1 {} \;); do if [ -z $(sudo ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then sudo grep -ilr $hash /var/lib/cni/networks/gke-pod-network; fi; done | sudo xargs rm
    
    sudo systemctl restart kubelet containerd;
    
  2. Ejecuta la secuencia de comandos en todos los nodos del clúster que podrían verse afectados:

    for node in `kubectl get nodes -o wide | grep Ready | awk '{print $1}' | sort -u`; do gcloud compute ssh --zone "ZONE" --project "PROJECT" $node --command "$(cat cleanup.sh)"; done
    

La política de red descarta una conexión debido a una búsqueda de seguimiento de conexión incorrecta

Cuando un Pod de cliente se conecta consigo mismo a través de un Service o la dirección IP virtual de un balanceador de cargas TCP/UDP interno, el paquete de respuesta no se identifica como parte de una conexión existente debido a una búsqueda de conntrack incorrecta en el plano de datos. Esto significa que una política de red que restringe el tráfico de entrada para el Pod se aplica de forma incorrecta en el paquete.

El impacto de este problema depende de la cantidad de Pods configurados para el Service. Por ejemplo, si el Service tiene 1 Pod de backend, la conexión siempre falla. Si el Service tiene 2 Pods de backend, la conexión falla el 50% del tiempo.

Soluciones alternativas

Puedes mitigar este problema si configuras port y containerPort en el manifiesto del Service para que tengan el mismo valor.

¿Qué sigue?