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 riscontri problemi con l'utilizzo di GKE Dataplane V2, passa a 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.

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. La L'opzione Abilita criterio di rete di Kubernetes è disabilitata quando selezioni Abilita Dataplane V2 perché l'applicazione dei criteri di rete è integrata GKE Dataplane V2.

  5. Fai clic su Crea.

gcloud

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

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 la versione GKE 1.20.6-gke.700 o successive. Se preferisci non utilizzare un canale di rilascio, puoi anche usare il Flag --cluster-version anziché --release-channel, con l'indicazione della versione 1.20.6-gke.700 o versioni successive.
  • COMPUTE_LOCATION: la posizione 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.

Lo snippet JSON seguente mostra la configurazione necessaria per attivare 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 versioni successive.
  • CHANNEL_NAME: un canale di rilascio che include GKE versione 1.20.6-gke.700 o successive.

Risoluzione dei problemi relativi a GKE Dataplane V2

Questa sezione mostra come esaminare e risolvere i problemi relativi a GKE Dataplane 2.

  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 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, consulta anetd log dei pod. 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 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à intermittente con traffico mascherato o con un utilizzo temporaneo delle porte. Questi problemi sono dovuti 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 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, In ip-masq-agent è implementato l'argomento --random-fully 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 temporanea dell'intervallo di porte: se l'intervallo di porte temporanee definito dalla rete net.ipv4.ip_local_port_range sui tuoi nodi GKE si sovrappone con l'intervallo NodePort (30000-32767), può anche attivare la connettività che le applicazioni presentino problemi di prestazioni. 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, considera queste potenziali cause e la tua configurazione di conseguenza.

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 è 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. Questo L'API è supportata nei cluster con Calico Network Policy, ma non è supportata nei cluster con GKE Dataplane V2.

Puoi verificare il comportamento degli oggetti NetworkPolicy leggendo dopo averle scritte sul server API. Se l'oggetto contiene ancora il endPort campo, la funzionalità viene applicata. Se il campo endPort è mancante, la funzionalità non è applicata. In tutti i casi, l'oggetto archiviato il server API sia la fonte attendibile per i criteri di rete.

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

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

Versioni GKE interessate: dalla 1.22 alla 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 n. 5768 del container.

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 un indirizzo IP virtuale di un bilanciatore del carico di rete passthrough interno, il pacchetto di risposta non è identificato come parte di un connessione esistente a causa di una ricerca di connessione errata nel piano dati. 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 il Servizio. Ad esempio, se il servizio ha 1 pod di backend, la connessione non funziona sempre. 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 GKE:

  • 1.28.3-gke.1090000 o versioni successive.

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 a se stesso utilizzando un servizio, in modo che è sia l'origine che la destinazione della connessione, GKE Dataplane V2 eBPF il monitoraggio delle connessioni traccia in modo errato gli stati della connessione, causando una fuga di dati Collega le voci.

Quando una tupla di connessione (protocollo, IP di origine/destinazione e origine/destinazione porta) è stata divulgata, le nuove connessioni che utilizzano la stessa tupla di connessione potrebbero comportano 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 si impedisce l'emissione del flag TCP FIN ed evita la fuga della voce conntrack.

  • Quando utilizzi connessioni di breve durata, esponi il pod utilizzando un bilanciatore del carico proxy, ad esempio Gateway, per esporre assistenza. Questo fa sì che la destinazione della richiesta di connessione venga impostata su all'indirizzo IP del bilanciatore del carico, impedendo a GKE Dataplane V2 di eseguire SNAT l'indirizzo IP di loopback.

Passaggi successivi