Probleme mit NFS- und DataPlane v2 von GKE on VMware beheben

Version 1.28 

• Neueste Version
• Version 1.16
• Frühere Versionen (nicht unterstützt)

In diesem Dokument wird ein manuelles Verfahren für GKE on VMware beschrieben, wenn Sie Probleme mit NFS-Bereitstellungen mit einem hängen gebliebenen Volume oder Pod haben und Ihren Cluster mit aktiviertem DataPlane v2 erstellt haben. Probleme können auftreten, wenn Sie Arbeitslasten mit ReadWriteMany-Volumes haben, die von Speichertreibern betrieben werden, die anfällig für dieses Problem sind, z. B.:

• Robin.io
• Portworx (sharedv4 Dienst-Volumes)
• csi-nfs

NFS-Bereitstellungen auf einigen Speicherarchitekturen können hängen bleiben, wenn sie über einen Kubernetes-Dienst (ClusterIP) und DataPlane v2 mit einem Endpunkt verbunden werden. Dieses Verhalten beruht auf den Einschränkungen bei der Interaktion des Linux-Kernel-Socket-Codes mit dem eBPF-Programm von Cillium. Container können bei E/A-Vorgängen blockiert oder sogar nicht mehr unterstützt werden, da die eingestellte NFS-Bereitstellung nicht getrennt werden kann.

Dieses Problem kann auftreten, wenn Sie RWX-Speicher verwenden, der auf NFS-Servern gehostet wird, die auf einem Kubernetes-Knoten ausgeführt werden, einschließlich softwarebasierter oder hyperkonvergenter Speicherlösungen wie Ondat, Robin.io oder Portworx.

Vorhandene Clusterkonfiguration prüfen

Rufen Sie einige vorhandene Konfigurationswerte aus dem Cluster ab. Sie verwenden die Werte aus diesen Schritten, um im nächsten Abschnitt ein kube-proxy-Manifest zu erstellen.

1. Rufen Sie die ClusterCIDR von cm/cilium-config ab:

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

   Die folgende Beispielausgabe zeigt, dass Sie 192.168.0.0/16 als ClusterCIDR verwenden würden:

   ipv4-native-routing-cidr: 192.168.0.0/16
   native-routing-cidr: 192.168.0.0/16
   

2. Rufen Sie APIServerAdvertiseAddress und APIServerPort aus dem DaemonSet anetd ab:

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

   Die folgende Beispielausgabe zeigt, dass Sie 21.1.4.119 als APIServerAdvertiseAddress und 443 als APIServerPort verwenden würden:

   - name: KUBERNETES_SERVICE_HOST
     value: 21.1.4.119
   - name: KUBERNETES_SERVICE_PORT
     value: "443"
   

3. Rufen Sie das RegistryCredentialsSecretName aus dem DaemonSet anetd ab:

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

   Die folgende Beispielausgabe zeigt, dass Sie private-registry-creds als RegistryCredentialsSecretName verwenden würden:

   imagePullSecrets:
     - name: private-registry-creds
   

4. Rufen Sie Registry aus dem DameonSet von anetd ab:

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

   Die folgende Beispielausgabe zeigt, dass Sie gcr.io/gke-on-prem-release als Registry verwenden würden:

   image: gcr.io/gke-on-prem-release/cilium/cilium:v1.12.6-anthos1.15-gke4.2.7
   

5. Rufen Sie das KubernetesVersion aus dem Image-Tag für kube-apiserver im Cluster-Namespace des Administratorclusters ab:

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

   Ersetzen Sie ADMIN_KUBECONFIG durch die kubeconfig-Datei für Ihren Administratorcluster und CLUSTER_NAME durch den Namen Ihres Nutzerclusters.

   Die folgende Beispielausgabe zeigt, dass Sie v1.26.2-gke.1001 als KubernetesVersion verwenden würden:

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

kube-proxy Manifest vorbereiten

Verwenden Sie die im vorherigen Abschnitt abgerufenen Werte, um ein YAML-Manifest zu erstellen und anzuwenden, das kube-proxy in Ihrem Cluster bereitstellt.

1. Erstellen Sie im Editor Ihrer Wahl ein Manifest mit dem Namen kube-proxy.yaml:

   nano kube-proxy.yaml
   

2. Kopieren Sie die folgende YAML-Definition und fügen Sie sie ein:

   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
   

   Legen Sie in diesem YAML-Manifest die folgenden Werte fest:

   • APIServerAdvertiseAddress: der Wert von KUBERNETES_SERVICE_HOST, z. B. 21.1.4.119.
   • APIServerPort: der Wert von KUBERNETES_SERVICE_PORT, z. B. 443.
   • Registry: das Präfix des Cilium-Images, z. B. gcr.io/gke-on-prem-release.
   • RegistryCredentialsSecretName ist der Name des Image-Pull-Secrets, z. B. private-registry-creds.

3. Speichern und schließen Sie die Manifestdatei in Ihrem Editor.

anetd-Patch vorbereiten

Erstellen Sie ein Update für anetd und bereiten Sie es vor:

1. Erstellen Sie im Editor Ihrer Wahl ein Manifest mit dem Namen cilium-config-patch.yaml:

   nano cilium-config-patch.yaml
   

2. Kopieren Sie die folgende YAML-Definition und fügen Sie sie ein:

   data:
     kube-proxy-replacement: "disabled"
     kube-proxy-replacement-healthz-bind-address: ""
     retry-kube-proxy-healthz-binding: "false"
     enable-host-reachable-services: "false"
   

3. Speichern und schließen Sie die Manifestdatei in Ihrem Editor.

kube-proxy bereitstellen und anetd neu konfigurieren

Wenden Sie Ihre Konfigurationsänderungen auf den Cluster an. Erstellen Sie Sicherungen Ihrer vorhandenen Konfiguration, bevor Sie die Änderungen anwenden.

1. Sichern Sie Ihre aktuelle Konfiguration für anetd und 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. Wenden Sie kube-proxy.yaml mit kubectl an:

   kubectl apply -f kube-proxy.yaml
   

3. Prüfen Sie, ob die Pods Running sind:

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

   Das folgende komprimierte Beispiel zeigt, dass die Pods korrekt ausgeführt werden:

   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. Patchen Sie die ConfigMap cilium-config mit kubectl:

   kubectl patch cm -n kube-system cilium-config --patch-file cilium-config-patch.yaml
   

5. anetd mit kubectl bearbeiten:

   kubectl edit ds -n kube-system anetd
   

   Bearbeiten Sie in dem Editor, der geöffnet wird, die Spezifikation von anetd. Fügen Sie Folgendes als erstes Element unter initContainers ein:

   - 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
   

   Ersetzen Sie Image durch dasselbe Image, das in den anderen Cilium-Containern im DaemonSet anetd verwendet wird, z. B. gcr.io/gke-on-prem-release/cilium/cilium:v1.12.6-anthos1.15-gke4.2.7.

6. Speichern und schließen Sie die Manifestdatei in Ihrem Editor.

7. Starten Sie alle Knoten im Cluster neu, um diese Änderungen zu übernehmen. Um Unterbrechungen zu minimieren, können Sie versuchen, jeden Knoten vor dem Neustart zu leeren. Pods, die RWX-Volumes verwenden, können jedoch aufgrund von fehlerhaften NFS-Bereitstellungen, die den Verbindungsausgleich blockieren, im Status Terminating hängen bleiben.

   Sie können das Löschen blockierter Pods erzwingen und den Knoten ordnungsgemäß per Drain beenden:

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

   Ersetzen Sie POD_NAME durch den Pod, den Sie löschen möchten, und POD_NAMESPACE durch seinen Namespace.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an Cloud Customer Care .