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à:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Fai clic su add_box Crea.
Fai clic su Configura per configurare un cluster Standard.
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.
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.
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.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"
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.
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
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:
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
Esegui il daemonset sul cluster:
kubectl apply -f cleanup-ips.yaml
Per eseguire questo comando, devi avere accesso a kubectl come amministratore del cluster.
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
- Utilizza il logging dei criteri di rete per registrare quando le connessioni ai pod vengono consentite o negate dai criteri di rete del cluster.
- Scopri come funziona GKE Dataplane V2.