Utilizzo di GKE Dataplane V2

Questa pagina spiega come abilitare GKE Dataplane V2 per i cluster Google Kubernetes Engine (GKE).

Nei nuovi cluster Autopilot è abilitata GKE Dataplane V2 nelle versioni 1.22.7-gke.1500 e successive e 1.23.4-gke.1500 e successive. Se riscontri problemi con l'utilizzo di GKE Dataplane V2, vai a Risoluzione dei problemi.

Creazione di un cluster GKE con GKE Dataplane V2

Puoi abilitare GKE Dataplane V2 quando crei nuovi cluster con GKE versione 1.20.6-gke.700 e successive utilizzando gcloud CLI o l'API Kubernetes Engine. Puoi anche abilitare GKE Dataplane V2 in Anteprima quando crei nuovi cluster con GKE versione 1.17.9 e successive.

Console

Per creare un nuovo cluster con GKE Dataplane V2, esegui queste attività:

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Fai clic su Configura per configurare un cluster Standard.

  4. Nella sezione Networking, seleziona la casella di controllo Abilita Dataplane V2. L'opzione Abilita criterio di rete Kubernetes viene disabilitata quando selezioni Abilita Dataplane V2 perché l'applicazione dei criteri di rete è integrata in GKE Dataplane V2.

  5. Fai clic su Crea.

gcloud

Per creare un nuovo cluster con GKE Dataplane V2, utilizza questo comando:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --release-channel CHANNEL_NAME \
    --location COMPUTE_LOCATION

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster.
  • CHANNEL_NAME: un canale di rilascio che include GKE versione 1.20.6-gke.700 o successiva. Se preferisci non utilizzare un canale di rilascio, puoi utilizzare anche il flag --cluster-version anziché --release-channel, specificando la versione 1.20.6-gke.700 o una versione successiva.
  • COMPUTE_LOCATION: la località di Compute Engine per il nuovo cluster.

API

Per creare un nuovo cluster con GKE Dataplane V2, specifica il campo datapathProvider nell'oggetto networkConfig nella richiesta create del cluster.

Il seguente snippet JSON mostra la configurazione necessaria per abilitare GKE Dataplane V2:

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

Sostituisci quanto segue:

  • VERSION: la versione del cluster, che deve essere GKE 1.20.6-gke.700 o successiva.
  • CHANNEL_NAME: un canale di rilascio che include GKE versione 1.20.6-gke.700 o successiva.

Risoluzione dei problemi con GKE Dataplane V2

Questa sezione mostra come indagare e risolvere i problemi relativi a GKE Dataplane V2.

  1. Verifica che GKE Dataplane V2 sia abilitato:

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

    Se GKE Dataplane V2 è in esecuzione, l'output include i pod con il prefisso anetd-. anetd è il controller di rete per GKE Dataplane V2.

  2. Se il problema riguarda l'applicazione dei criteri di rete o dei servizi, controlla i log dei pod anetd. Usa i seguenti selettori di log in Cloud Logging:

    resource.type="k8s_container"
labels."k8s-pod/k8s-app"="cilium"
resource.labels.cluster_name="CLUSTER_NAME"

  3. Se la creazione del pod non riesce, verifica la presenza di indizi nei log kubelet. Utilizza i seguenti selettori di log in Cloud Logging:

    resource.type="k8s_node"
log_name=~".*/logs/kubelet"
resource.labels.cluster_name="CLUSTER_NAME"

    Sostituisci CLUSTER_NAME con il nome del cluster o rimuovilo del tutto per visualizzare i log di tutti i cluster.

Problemi noti

Gli intervalli di porte del criterio di rete non hanno effetto

Se specifichi un campo endPort in un criterio di rete su un cluster in cui è abilitato GKE Dataplane V2, questo non verrà applicato.

A partire da GKE 1.22, l'API Kubernetes Network Policy consente di specificare un intervallo di porte in cui viene applicato il criterio di rete. Questa API è supportata nei cluster con Calico Network Policy, ma non è supportata nei cluster con GKE Dataplane V2.

Puoi verificare il comportamento degli oggetti NetworkPolicy rileggendoli dopo averli scritti nel server API. Se l'oggetto contiene ancora il campo endPort, la funzionalità viene applicata in modo forzato. Se il campo endPort non è presente, la funzionalità non viene applicata. In tutti i casi, l'oggetto archiviato nel server API è la fonte attendibile per il criterio di rete.

Per ulteriori informazioni, consulta KEP-2079: criterio di rete per supportare gli intervalli di porte.

I pod mostrano failed to allocate for range 0: no IP addresses available in range set messaggio di errore

Versioni GKE interessate: dalla 1.22 alla 1.25

I cluster GKE che eseguono pool di nodi che utilizzano containerd e in cui è abilitato GKE Dataplane V2 potrebbero riscontrare problemi di perdita di indirizzi IP ed esaurire tutti gli indirizzi IP dei pod su un nodo. Un pod pianificato su un nodo interessato mostra un messaggio di errore simile al seguente:

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

Per ulteriori informazioni sul problema, consulta il problema containerd n. 5768.

Versioni corrette

Per risolvere questo problema, esegui l'upgrade del cluster a una delle seguenti versioni di GKE:

  • 1.22.17-gke.3100 o versioni successive.
  • 1.23.16-gke.200 o versioni successive.
  • 1.24.9-gke.3200 o versioni successive.
  • 1.25.6-gke.200 o versioni successive.

Soluzioni alternative per i cluster GKE standard

Puoi mitigare questo problema eliminando gli indirizzi IP dei pod divulgati per il nodo.

Per eliminare gli indirizzi IP dei pod divulgati, recupera le credenziali di autenticazione per il cluster ed esegui i passaggi seguenti per eseguire la pulizia di un singolo nodo, se ne conosci il nome.

  1. Salva il seguente script shell in un file denominato 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 hash="${hash%%[[:space:]]}"; 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 -r rm

  2. Esegui lo script su un nodo cluster:

    gcloud compute ssh --zone "ZONE" --project "PROJECT" NODE_NAME --command "$(cat cleanup.sh)"

    Sostituisci NODE_NAME con il nome del nodo.

Puoi anche eseguire una versione DaemonSet di questo script da eseguire in parallelo su tutti i nodi contemporaneamente:

  1. Salva il manifest seguente in un file denominato cleanup-ips.yaml:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cleanup-ipam-dir
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: cleanup-ipam
  template:
    metadata:
      labels:
        name: cleanup-ipam
    spec:
      hostNetwork: true
      securityContext:
        runAsUser: 0
        runAsGroup: 0
      containers:
      - name: cleanup-ipam
        image: gcr.io/gke-networking-test-images/ubuntu-test:2022
        command:
          - /bin/bash
          - -c
          - |
            while true; do
            for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do
            hash="${hash%%[[:space:]]}"
            if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then
            grep -ilr $hash /hostipam
            fi
            done | xargs -r rm
            echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)"
            sleep 120s
            done
        volumeMounts:
        - name: host-ipam
          mountPath: /hostipam
        - name: host-ctr
          mountPath: /run/containerd
      volumes:
      - name: host-ipam
        hostPath:
          path: /var/lib/cni/networks/gke-pod-network
      - name: host-ctr
        hostPath:
          path: /run/containerd

  2. Esegui il daemonset sul cluster:

    kubectl apply -f cleanup-ips.yaml

    Per eseguire questo comando, devi avere accesso a kubectl come amministratore del cluster.

  3. Controlla i log del DaemonSet in esecuzione:

    kubectl -n kube-system logs -l name=cleanup-ipam

Il criterio di rete interrompe una connessione a causa di una ricerca errata del monitoraggio delle connessioni

Quando un pod client si connette a se stesso tramite un servizio o l'indirizzo IP virtuale di un bilanciatore del carico di rete passthrough interno, il pacchetto di risposta non viene identificato come parte di una connessione esistente a causa di una ricerca conntrack errata nel dataplane. Questo significa che un criterio di rete che limita il traffico in entrata per il pod viene applicato in modo errato al pacchetto.

L'impatto di questo problema dipende dal numero di pod configurati per il servizio. Ad esempio, se il servizio ha un pod di backend, la connessione non va sempre a buon fine. Se il servizio ha 2 pod di backend, la connessione non riesce il 50% delle volte.

Versioni corrette

Per risolvere il problema, esegui l'upgrade del cluster a una delle seguenti versioni di GKE:

  • 1.28.3-gke.1090000 o versioni successive.

Soluzioni alternative

Puoi limitare questo problema configurando port e containerPort nel file manifest del servizio in modo che abbiano lo stesso valore.

Gocce di pacchetti per i flussi di connessione a forcella

Quando un pod crea una connessione TCP a se stessa utilizzando un servizio, in modo che il pod sia l'origine e la destinazione della connessione, il monitoraggio della connessione eBPF di GKE Dataplane V2 monitora in modo errato gli stati della connessione, causando la perdita di voci di connessione.

Quando una tupla di connessione (protocollo, IP di origine/destinazione e porta di origine/destinazione) è stata divulgata, le nuove connessioni che utilizzano la stessa tupla di connessione potrebbero causare la perdita di pacchetti di ritorno.

Versioni corrette

Per risolvere il problema, esegui l'upgrade del cluster a una delle seguenti versioni di GKE:

  • 1.28.3-gke.1090000 o versioni successive
  • 1.27.11-gke.1097000 o versioni successive

Soluzioni alternative

Utilizza una delle seguenti soluzioni alternative:

  • Abilita il riutilizzo TCP (keep-alive) per le applicazioni in esecuzione nei pod che potrebbero comunicare con se stesse utilizzando un servizio. In questo modo si impedisce l'emissione del flag FIN TCP e si evita la perdita della voce di connessione.

  • Quando utilizzi connessioni di breve durata, esponi il pod utilizzando un bilanciatore del carico proxy, come Gateway, per esporre il servizio. Questo comporta l'impostazione della destinazione della richiesta di connessione sull'indirizzo IP del bilanciatore del carico, impedendo a GKE Dataplane V2 di eseguire SNAT all'indirizzo IP di loopback.

Passaggi successivi