Utilizzo di GKE Dataplane V2

Questa pagina spiega come attivare e risolvere i problemi relativi a GKE Dataplane V2 per i cluster Google Kubernetes Engine (GKE).

Nei nuovi cluster Autopilot è abilitato GKE Dataplane V2 nelle versioni 1.22.7-gke.1500 e successive e 1.23.4-gke.1500 e successive. Se hai riscontrato problemi con l'utilizzo di GKE Dataplane V2, vai alla sezione Risoluzione dei problemi.

Creazione di un cluster GKE con GKE Dataplane V2

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

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

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

Risoluzione dei problemi relativi a GKE Dataplane V2

Questa sezione mostra come esaminare 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 i servizi o l'applicazione dei criteri di rete, controlla i anetd log dei pod. Utilizza 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 va a buon fine, controlla i log di kubelet per trovare indizi. Utilizza i seguenti selezionatori 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

Problemi di connettività intermittenti relativi a conflitti di intervalli NodePort nel cluster GKE Dataplane V2

Nei cluster GKE Dataplane V2, possono verificarsi problemi di connettività intermittenti per il traffico mascherato o per l'utilizzo di porte effimere. Questi problemi sono dovuti a potenziali conflitti di porte con l'intervallo NodePort riservato e si verificano in genere nei seguenti scenari:

• ip-masq-agent personalizzato: se utilizzi un ip-masq-agent personalizzato (versione 2.10 o successiva) in cui il cluster dispone di servizi NodePort o Load Balancer, potresti riscontrare problemi di connettività intermittenti a causa del loro conflitto con l'intervallo NodePort. A partire dalla versione 2.10 e successive, ip-masq-agent ha l'argomento --random-fully implementato internamente per impostazione predefinita. Per attenuare il problema, imposta esplicitamente --random-fully=false (applicabile dalla versione 2.11) in "Argomenti" nella configurazione di ip-masq-agent. Per i dettagli sulla configurazione, consulta Configurare un agente di mascheramento IP nei cluster standard.

• Sovrapposizione dell'intervallo di porte effimere: se l'intervallo di porte effimere definito da net.ipv4.ip_local_port_range sui nodi GKE si sovrappone all'intervallo NodePort (30000-32767), possono verificarsi anche problemi di connettività. Per evitare questo problema, assicurati che questi due intervalli non si sovrappongano.

Controlla la configurazione di ip-masq-agent e le impostazioni dell'intervallo di porte effimere per assicurarti che non entrino in conflitto con l'intervallo NodePort. Se riscontri problemi di connettività intermittenti, valuta queste potenziali cause e modifica la configurazione di conseguenza.

Gli intervalli di porte del criterio di rete non vengono applicati

Se specifichi un campo endPort in un criterio di rete su un cluster in cui è attivo GKE Dataplane V2, il criterio 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 criteri di rete Calico, ma non nei cluster con GKE Dataplane V2.

Puoi verificare il comportamento degli oggetti NetworkPolicy rileggendoli dopo averli scritti sul server API. Se l'oggetto contiene ancora il endPort campo, la funzionalità viene applicata. Se il campo endPort è mancante, 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: Network Policy to support Port Ranges.

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

Versioni GKE interessate: da 1.22 a 1.25

I cluster GKE che eseguono pool di nodi che utilizzano containerd e hanno attivato GKE Dataplane V2 potrebbero riscontrare problemi di fuga 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 5768 di containerd.

Versioni corrette

Per risolvere il problema, esegui l'upgrade del cluster a una delle seguenti versioni 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 del pod trapelati per il nodo.

Per eliminare gli indirizzi IP dei pod trapelati, recupera le credenziali di autenticazione per il cluster ed esegui i seguenti passaggi per ripulire 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 del 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 per eseguirlo in parallelo su tutti i nodi contemporaneamente:

1. Salva il seguente manifest 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 disporre dell'accesso 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 di monitoraggio delle connessioni errata

Quando un pod client si connette a se stesso utilizzando 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. Ciò 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 riesce sempre. Se il servizio ha 2 pod di backend, la connessione non riesce nel 50% dei casi.

Versioni corrette

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

• 1.28.3-gke.1090000 o successiva.

Soluzioni alternative

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

Perdite di pacchetti per i flussi di connessione a tornanti

Quando un pod crea una connessione TCP con se stesso utilizzando un servizio, in modo che il pod sia sia la sorgente sia la destinazione della connessione, il monitoraggio delle connessioni eBPF di GKE Dataplane V2 monitora in modo errato gli stati di connessione, causando la fuga di voci conntrack.

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 comportare l'eliminazione dei pacchetti di ritorno.

Versioni corrette

Per risolvere il problema, esegui l'upgrade del cluster a una delle seguenti versioni 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 tra loro utilizzando un servizio. In questo modo, viene impedito l'emissione del flag TCP FIN ed evitata la fuga della voce conntrack.

• Quando utilizzi connessioni di breve durata, esponi il pod utilizzando un bilanciatore del carico proxy, come Gateway, per esporre il servizio. Di conseguenza, la destinazione della richiesta di connessione viene impostata sull'indirizzo IP del bilanciatore del carico, impedendo a GKE Dataplane V2 di eseguire SNAT sull'indirizzo IP loopback.

Passaggi successivi

• Utilizza il logging dei criteri di rete per registrare quando le connessioni ai pod sono consentite o negate dai criteri di rete del cluster.
• Scopri come funziona GKE Dataplane V2.