Risolvi i problemi relativi a NFS e DataPlane v2 di GKE su VMware

Questo documento descrive una procedura manuale per GKE su VMware in caso di problemi con montaggi NFS con un volume o un pod bloccato e se hai creato il cluster con DataPlane v2 abilitato. Potresti riscontrare problemi se hai carichi di lavoro che utilizzano volumi ReadWriteMany basati su driver di archiviazione soggetti a questo problema, tra cui, a titolo esemplificativo:

  • Robin.io
  • Portworx (sharedv4 volume di servizio)
  • csi-nfs

I montaggi NFS su alcune architetture di archiviazione potrebbero bloccarsi quando sono connesse a un endpoint mediante un servizio Kubernetes (ClusterIP) e DataPlane v2. Questo comportamento è dovuto alle limitazioni nel modo in cui il codice del socket del kernel Linux interagisce con il programma eBPF di Cillium. I container potrebbero essere bloccati durante l'I/O o addirittura essere inarrestabili, poiché il montaggio NFS disattivato non può essere smontato.

Questo problema può verificarsi se utilizzi lo spazio di archiviazione RWX ospitato su server NFS in esecuzione su un nodo Kubernetes, comprese soluzioni di archiviazione software-defined o iperconvergenti come Ondat, Robin.io o Portworx.

Rivedi la configurazione del cluster esistente

Recupera alcuni valori di configurazione esistenti dal cluster. Utilizza i valori di questi passaggi per creare un manifest kube-proxy nella sezione successiva.

  1. Prendi il ClusterCIDR da cm/cilium-config:

    kubectl get cm -n kube-system cilium-config -o yaml | grep native-routing-cidr
    

    Il seguente output di esempio mostra che utilizzerai 192.168.0.0/16 come ClusterCIDR:

    ipv4-native-routing-cidr: 192.168.0.0/16
    native-routing-cidr: 192.168.0.0/16
    
  2. Scarica APIServerAdvertiseAddress e APIServerPort dal DaemonSet anetd:

    kubectl get ds -n kube-system  anetd -o yaml | grep KUBERNETES -A 1
    

    Il seguente output di esempio mostra che utilizzerai 21.1.4.119 come APIServerAdvertiseAddress e 443 come APIServerPort:

    - name: KUBERNETES_SERVICE_HOST
      value: 21.1.4.119
    - name: KUBERNETES_SERVICE_PORT
      value: "443"
    
  3. Prendi il RegistryCredentialsSecretName dal DaemonSet di anetd:

    kubectl get ds -n kube-system  anetd -o yaml | grep imagePullSecrets -A 1
    

    Il seguente output di esempio mostra che utilizzerai private-registry-creds come RegistryCredentialsSecretName:

    imagePullSecrets:
      - name: private-registry-creds
    
  4. Prendi il Registry da DameonSet di anetd:

    kubectl get ds -n kube-system  anetd -o yaml | grep image
    

    Il seguente output di esempio mostra che utilizzerai gcr.io/gke-on-prem-release come Registry:

    image: gcr.io/gke-on-prem-release/cilium/cilium:v1.12.6-anthos1.15-gke4.2.7
    
  5. Recupera KubernetesVersion dal tag immagine per kube-apiserver nello spazio dei nomi del cluster del cluster di amministrazione:

    KUBECONFIG=ADMIN_KUBECONFIG
    kubectl get sts -n CLUSTER_NAME kube-apiserver -o yaml | grep image
    

    Sostituisci ADMIN_KUBECONFIG con il file kubeconfig per il tuo cluster di amministrazione e CLUSTER_NAME con il nome del tuo cluster utente.

    Il seguente output di esempio mostra che utilizzerai v1.26.2-gke.1001 come KubernetesVersion:

    image: gcr.io/gke-on-prem-release/kube-apiserver-amd64:v1.26.2-gke.1001
    imagePullPolicy: IfNotPresent
    

Prepara kube-proxy manifest

Utilizza i valori ottenuti nella sezione precedente per creare e applicare un manifest YAML che eseguirà il deployment di kube-proxy nel tuo cluster.

  1. Crea un manifest denominato kube-proxy.yaml nell'editor che preferisci:

    nano kube-proxy.yaml
    
  2. Copia e incolla la definizione YAML seguente:

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      labels:
        k8s-app: kube-proxy
      name: kube-proxy
      namespace: kube-system
    spec:
      selector:
        matchLabels:
          k8s-app: kube-proxy
      template:
        metadata:
          annotations:
            scheduler.alpha.kubernetes.io/critical-pod: ""
          labels:
            k8s-app: kube-proxy
        spec:
          containers:
          - command:
            - kube-proxy
            - --v=2
            - --profiling=false
            - --iptables-min-sync-period=10s
            - --iptables-sync-period=1m
            - --oom-score-adj=-998
            - --ipvs-sync-period=1m
            - --ipvs-min-sync-period=10s
            - --cluster-cidr=ClusterCIDR
            env:
            - name: KUBERNETES_SERVICE_HOST
              value:APIServerAdvertiseAddress
            - name: KUBERNETES_SERVICE_PORT
              value: "APIServerPort"
            image: Registry/kube-proxy-amd64:KubernetesVersion
            imagePullPolicy: IfNotPresent
            name: kube-proxy
            resources:
              requests:
                cpu: 100m
                memory: 15Mi
            securityContext:
              privileged: true
            volumeMounts:
            - mountPath: /run/xtables.lock
              name: xtables-lock
            - mountPath: /lib/modules
              name: lib-modules
          imagePullSecrets:
          - name: RegistryCredentialsSecretName
          nodeSelector:
            kubernetes.io/os: linux
          hostNetwork: true
          priorityClassName: system-node-critical
          serviceAccount: kube-proxy
          serviceAccountName: kube-proxy
          tolerations:
          - effect: NoExecute
            operator: Exists
          - effect: NoSchedule
            operator: Exists
          volumes:
          - hostPath:
              path: /run/xtables.lock
              type: FileOrCreate
            name: xtables-lock
          - hostPath:
              path: /lib/modules
              type: DirectoryOrCreate
            name: lib-modules
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: system:kube-proxy
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: system:node-proxier
      subjects:
        - kind: ServiceAccount
          name: kube-proxy
          namespace: kube-system
      ---
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: kube-proxy
        namespace: kube-system
    

    In questo manifest YAML, imposta i seguenti valori:

    • APIServerAdvertiseAddress: il valore di KUBERNETES_SERVICE_HOST, ad esempio 21.1.4.119.
    • APIServerPort: il valore di KUBERNETES_SERVICE_PORT, ad esempio 443.
    • Registry: il prefisso dell'immagine Cilium, ad esempio gcr.io/gke-on-prem-release.
    • RegistryCredentialsSecretName: il nome del secret del pull dell'immagine, ad esempio private-registry-creds.
  3. Salva e chiudi il file manifest nell'editor.

Prepara anetd patch

Crea e prepara un aggiornamento per anetd:

  1. Crea un file manifest denominato cilium-config-patch.yaml nell'editor di tua scelta:

    nano cilium-config-patch.yaml
    
  2. Copia e incolla la definizione YAML seguente:

    data:
      kube-proxy-replacement: "disabled"
      kube-proxy-replacement-healthz-bind-address: ""
      retry-kube-proxy-healthz-binding: "false"
      enable-host-reachable-services: "false"
    
  3. Salva e chiudi il file manifest nell'editor.

Esegui il deployment di kube-proxy e riconfigura anetd

Applica le modifiche alla configurazione al cluster. Crea dei backup della configurazione esistente prima di applicare le modifiche.

  1. Esegui il backup della configurazione attuale di anetd e cilium-config:

    kubectl get ds -n kube-system anetd > anetd-original.yaml
    kubectl get cm -n kube-system cilium-config > cilium-config-original.yaml
    
  2. Applica kube-proxy.yaml utilizzando kubectl:

    kubectl apply -f kube-proxy.yaml
    
  3. Verifica che i pod siano Running:

    kubectl get pods -n kube-system -o wide | grep kube-proxy
    

    L'output ridotto di esempio seguente mostra che i pod vengono eseguiti correttamente:

    kube-proxy-f8mp9    1/1    Running   1 (4m ago)    [...]
    kube-proxy-kndhv    1/1    Running   1 (5m ago)    [...]
    kube-proxy-sjnwl    1/1    Running   1 (4m ago)    [...]
    
  4. Applica una patch al ConfigMap cilium-config utilizzando kubectl:

    kubectl patch cm -n kube-system cilium-config --patch-file cilium-config-patch.yaml
    
  5. Modifica anetd utilizzando kubectl:

    kubectl edit ds -n kube-system anetd
    

    Nell'editor che si apre, modifica la specifica di anetd. Inserisci quanto segue come primo elemento in initContainers:

    - name: check-kube-proxy-rules
      image: Image
      imagePullPolicy: IfNotPresent
      command:
      - sh
      - -ec
      - |
        if [ "$KUBE_PROXY_REPLACEMENT" != "strict" ]; then
          kube_proxy_forward() { iptables -L KUBE-FORWARD; }
          until kube_proxy_forward; do sleep 2; done
        fi;
      env:
      - name: KUBE_PROXY_REPLACEMENT
        valueFrom:
          configMapKeyRef:
            key: kube-proxy-replacement
            name: cilium-config
            optional: true
      securityContext:
        privileged: true
    

    Sostituisci Image con la stessa immagine utilizzata negli altri container Cilium nel DaemonSet anetd, ad esempio gcr.io/gke-on-prem-release/cilium/cilium:v1.12.6-anthos1.15-gke4.2.7.

  6. Salva e chiudi il file manifest nell'editor.

  7. Per applicare queste modifiche, riavvia tutti i nodi nel cluster. Per ridurre al minimo i problemi, puoi tentare di svuotare ogni nodo prima del riavvio. Tuttavia, i pod che utilizzano volumi RWX potrebbero rimanere bloccati in uno stato Terminating a causa di montaggi NFS non funzionanti che bloccano il processo di svuotamento.

    Puoi forzare l'eliminazione dei pod bloccati e consentire al nodo di svuotare correttamente:

    kubectl delete pods -–force -–grace-period=0 --namespace POD_NAMESPACE POD_NAME
    

    Sostituisci POD_NAME con il pod che stai cercando di eliminare e POD_NAMESPACE con il relativo spazio dei nomi.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud .