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).

I nuovi cluster Autopilot hanno GKE Dataplane V2 abilitato nelle versioni 1.22.7-gke.1500 e successive e nelle versioni 1.23.4-gke.1500 e successive. Se riscontri 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 versione 1.20.6-gke.700 e successive utilizzando gcloud CLI o l'API GKE. Puoi anche abilitare 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 l'applicazione di servizi o policy di rete, controlla i log dei pod anetd. 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 kubelet per trovare indizi. 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 completamente per visualizzare i log di tutti i cluster.

4. Se i pod anetd non sono in esecuzione, esamina ConfigMap cilium-config per eventuali modifiche. Evita di modificare i campi esistenti all'interno di questo ConfigMap, perché tali modifiche possono destabilizzare il cluster e interrompere anetd. Il ConfigMap viene ripristinato allo stato predefinito solo se vengono aggiunti nuovi campi. Le modifiche ai campi esistenti non vengono applicate e ti consigliamo di non modificare o personalizzare ConfigMap.

Problemi noti

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

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

• ip-masq-agent personalizzato:se utilizzi un ip-masq-agent personalizzato (versione 2.10 o successive), in cui il cluster ha servizi NodePort o Load Balancer, potresti riscontrare problemi di connettività intermittenti a causa del conflitto con l'intervallo NodePort. A partire dalla versione 2.10, ip-masq-agent ha l'argomento --random-fully implementato internamente per impostazione predefinita. Per risolvere questo problema, imposta esplicitamente --random-fully=false (applicabile dalla versione 2.11) negli argomenti della configurazione di ip-masq-agent. Per i dettagli della configurazione, vedi Configurazione di 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), può anche causare problemi di connettività. Per evitare questo problema, assicurati che questi due intervalli non si sovrappongano.

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

Problemi di connettività con hostPort nei cluster GKE Dataplane V2

Versioni di GKE interessate: 1.29 e successive

Nei cluster che utilizzano GKE Dataplane V2, potresti riscontrare errori di connettività quando il traffico ha come target l'IP:Porta di un nodo, dove porta è hostPort definito nel pod. Questi problemi si verificano in due scenari principali:

• Nodi con hostPort dietro un bilanciatore del carico di rete passthrough:

  hostPort collega un pod alla porta di un nodo specifico e un bilanciatore del carico di rete passthrough distribuisce il traffico su tutti i nodi. Quando esponi i pod a internet utilizzando hostPort e un bilanciatore del carico di rete passthrough, il bilanciatore del carico potrebbe inviare traffico a un nodo in cui il pod non è in esecuzione, causando errori di connessione. Ciò è dovuto a una limitazione nota in GKE Dataplane V2, in cui il traffico del bilanciatore del carico di rete passthrough non viene inoltrato in modo coerente ai pod hostPort.

  Soluzione alternativa:quando esponi hostPort di un pod sul nodo con un bilanciatore del carico di rete passthrough, specifica l'indirizzo IP interno o esterno del bilanciatore del carico di rete nel campo hostIP del pod.

  ports:
  - containerPort: 62000
    hostPort: 62000
    protocol: TCP
    hostIP: 35.232.62.64
  - containerPort: 60000
    hostPort: 60000
    protocol: TCP
    hostIP: 35.232.62.64
    # Assuming 35.232.62.64 is the external IP address of a passthrough Network Load Balancer.
  

• hostPort in conflitto con l'intervallo riservato NodePort:

  Se il hostPort di un pod è in conflitto con l'intervallo NodePort riservato (30000-32767), Cilium potrebbe non riuscire a inoltrare il traffico al pod. Questo comportamento è stato osservato nelle versioni del cluster 1.29 e successive, poiché ora Cilium gestisce le funzionalità hostPort, sostituendo il precedente metodo Portmap. Questo è un comportamento previsto per Cilium ed è menzionato nella documentazione pubblica.

Non prevediamo di risolvere queste limitazioni nelle versioni successive. La causa principale di questi problemi è correlata al comportamento di Cilium ed è al di fuori del controllo diretto di GKE.

Consiglio:ti consigliamo di eseguire la migrazione ai servizi NodePort anziché a hostPort per una maggiore affidabilità. NodePort I servizi forniscono funzionalità simili.

Gli intervalli di porte dei criteri di rete non vengono applicati

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

A partire da GKE 1.22, l'API Kubernetes Network Policy ti 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 leggendoli dopo averli scritti sul server API. Se l'oggetto contiene ancora il campo endPort, la funzionalità viene applicata. 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: 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 di GKE interessate: da 1.22 a 1.25

I cluster GKE che eseguono node pool che utilizzano containerd e hanno GKE Dataplane V2 abilitato 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 saperne di più sul problema, consulta l'issue #5768 di containerd.

Versioni corrette

Per risolvere il 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 compromessi, recupera le credenziali di autenticazione per il cluster ed esegui i seguenti passaggi per pulire 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
   

Network Policy interrompe una connessione a causa di una ricerca di tracciamento 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 pass-through 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 due 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 risolvere questo problema configurando port e containerPort nel manifest del servizio in modo che abbiano lo stesso valore.

Pacchetti eliminati per i flussi di connessione hairpin

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

Quando una tupla di connessione (protocollo, IP di origine/destinazione e porta di origine/destinazione) è stata compromessa, 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 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 di 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 TCP FIN e si evita la perdita 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 di loopback.

L'upgrade del control plane GKE causa il deadlock del pod anetd

Quando esegui l'upgrade di un cluster GKE con GKE Dataplane V2 (datapath avanzato) abilitato dalla versione 1.27 alla 1.28, potresti riscontrare una situazione di deadlock. I workload potrebbero subire interruzioni a causa dell'impossibilità di terminare i pod precedenti o pianificare i componenti necessari come anetd.

Causa

Il processo di upgrade del cluster aumenta il requisito di risorse per i componenti GKE Dataplane V2. Questo aumento potrebbe portare a una contesa delle risorse, che interrompe la comunicazione tra il plug-in Cilium Container Network Interface (CNI) e il daemon Cilium.

Sintomi

Potresti notare i seguenti sintomi:

• I pod anetd rimangono bloccati nello stato Pending.
• I pod del workload si bloccano nello stato Terminating.
• Errori che indicano errori di comunicazione di Cilium, ad esempio failed to connect to Cilium daemon.

• Errori durante la pulizia delle risorse di rete per i sandbox dei pod, ad esempio:

  1rpc error: code = Unknown desc = failed to destroy network for sandbox "[sandbox_id]": plugin type="cilium-cni" failed (delete): unable to connect to Cilium daemon... connection refused
  

Soluzione alternativa

Cluster standard: per risolvere il problema e consentire la pianificazione del pod anetd, aumenta temporaneamente le risorse allocabili sul nodo interessato.

1. Per identificare il nodo interessato e controllare la CPU e la memoria allocabili, esegui questo comando:

   kubectl get nodes $NODE_NAME -o json | jq '.status.allocatable | {cpu, memory}'
   

2. Per aumentare temporaneamente la CPU e la memoria allocabili, esegui questo comando:

   kubectl patch
   

Cluster Autopilot: per risolvere il problema di deadlock sui cluster Autopilot, libera risorse eliminando forzatamente il pod interessato:

kubectl delete pod POD_NAME -n NAMESPACE --grace-period=0 --force

Sostituisci quanto segue:

• POD_NAME: il nome del pod.
• NAMESPACE: lo spazio dei nomi del pod.

Dopo aver aumentato le risorse allocabili sul nodo e al termine dell'upgrade dalla versione 1.27 alla 1.28 di GKE, il pod anetd viene eseguito sulla versione più recente.

Passaggi successivi

• Utilizza la registrazione 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.