Wie behebe ich Probleme mit meinen Amazon EFS-Volume-Mounts in Amazon EKS?

Lösung

Voraussetzungen:

• Stelle sicher, dass dein Amazon EFS-Dateisystem ein Mount-Ziel in jedem der Worker-Knoten-Subnetze für die Availability Zone hat.
• Stelle sicher, dass du efs.csi.aws.com für die Amazon EFS-Speicherklassendefinition verwendest. Weitere Informationen findest du unter EFS-Speicherklasse auf der GitHub-Website.
• Stelle sicher, dass du PersistentVolumeClaim und PersistentVolume verwendest. Weitere Informationen findest du unter PersistentVolumeClaim und PersistentVolume auf der GitHub-Website.
  Hinweis: Wenn du dynamische Bereitstellung verwendest, musst du PersistentVolumeClaim und PersistentVolume nicht verwenden. Weitere Informationen findest du unter Dynamische Bereitstellung auf der GitHub-Website.
• Stelle sicher, dass du das Amazon EFS-CSI-Treiber-Add-On im EKS-Cluster installiert hast.

Stelle sicher, dass du das Netzwerk von deinen EKS-Worker-Knoten zur Amazon EFS-API korrekt konfiguriert hast

Stelle sicher, dass du von den EFS-Worker-Knoten und EFS-Controller-Pods aus Zugriff auf die Amazon EFS-API hast.

Wenn du das Netzwerk nicht so konfigurierst, dass es die Amazon EFS-API erreicht, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

• „failed to provision volume with StorageClass "xxxx": rpc error: code = DeadlineExceeded desc = context deadline exceeded“
• „Could not start amazon-efs-mount-watchdog, unrecognized init system "bash" Mount attempt x/3 failed due to timeout after 15 sec“
• „Unable to attach or mount volumes: timed out waiting for the condition“

Wenn du einen privaten Cluster ohne ausgehenden Internetzugang verwendest, musst du den Virtual Private Cloud (VPC)-Endpunkt com.amazonaws.region.elasticfilesystem in deine VPC aufnehmen. Erstelle eine eingehende Regel für die Sicherheitsgruppe des VPC-Endpunkts, die den Datenverkehr von deinen Worker-Knoten und Pod-Subnetzen an Port 443 zulässt. Stelle sicher, dass die Richtlinie, die an den VPC-Endpunkt angehängt ist, über die erforderlichen Berechtigungen verfügt.

Stelle sicher, dass du die Amazon EFS-Mount-Ziele korrekt konfiguriert hast

Stelle sicher, dass du die Amazon EFS-Mount-Ziele in jeder Availability Zone erstellt hast, in der die EKS-Knoten ausgeführt werden. Wenn du beispielsweise deine Worker-Knoten auf us-east-1a und us-east-1b verteilt hast, erstelle in beiden Availability Zones Mount-Ziele für das EFS-Dateisystem, das du mounten möchtest.

Wenn du die Mount-Ziele nicht richtig konfigurierst, wird möglicherweise die folgende Fehlermeldung angezeigt:

„Output: „fs-xxxxxx.efs.us-east-1.amazonaws.com" - The file system mount target ip address cannot be found“ konnte nicht gelöst werden

Stelle sicher, dass die deinem Amazon EFS-Dateisystem und deinen Worker-Knoten zugeordnete Sicherheitsgruppe NFS-Verkehr zulässt

Wenn die Sicherheitsgruppe keinen Verkehr zulässt, erhältst du möglicherweise eine der folgenden Fehlermeldungen:

• „Could not start amazon-efs-mount-watchdog, unrecognized init system "bash" Mount attempt x/3 failed due to timeout after 15 sec“
• „failed to provision volume with StorageClass "xxxx": rpc error: code = DeadlineExceeded desc = context deadline exceeded“
• „Unable to attach or mount volumes: timed out waiting for the condition“

Die Sicherheitsgruppe des Amazon EFS-Dateisystems muss über eine eingehende Regel verfügen, die NFS-Datenverkehr (Network File System) vom Classless Inter-Domain Routing (CIDR) für die VPC deines Clusters zulässt. Erlaube Port 2049 für eingehenden Datenverkehr.

Die Sicherheitsgruppe, die dem Worker-Knoten zugeordnet ist, auf denen die Pods das EFS-Volume nicht mounten können, muss über eine Regel für ausgehenden Datenverkehr verfügen. Die Regel für ausgehenden Datenverkehr muss den NFS-Verkehr von Port 2049 zum EFS-Dateisystem zulassen.

Stelle sicher, dass du den Unterverzeichnispfad in deinem Amazon EFS-Dateisystem erstellt hast

Wenn du Unterverzeichnispfade in persistenten Volumes hinzufügst, erstellt der Amazon EFS-CSI-Treiber den Unterverzeichnispfad nicht im Dateisystem. Du musst das Unterverzeichnis bereits im Dateisystem haben, damit der Mount-Vorgang erfolgreich ist. Wenn sich das Unterverzeichnis nicht im Dateisystem befindet, wird möglicherweise die folgende Fehlermeldung angezeigt:

„Output: mount.nfs4: mounting fs-18xxxxxx.efs.us-east-1.amazonaws.com:/path-in-dir:/ failed, reason given by server: No such file or directory“

Um zu überprüfen, ob das Unterverzeichnis im EFS-Dateisystem existiert, mounte das EFS-Dateisystem auf einer EC2-Instance und liste dessen Inhalt auf. Wenn das Unterverzeichnis nicht existiert, verwende den Befehl mkdir, um es zu erstellen.

Sicherstellen, dass die VPC des Clusters den Amazon DNS-Server verwendet

Wenn du das EFS-Volume mit dem Amazon EFS-CSI-Treiber mountest, musst du den Amazon DNS-Server für die VPC verwenden.

Hinweis: Nur das von Amazon bereitgestellte DNS kann das Dateisystem-DNS des Amazon EFS-Diensts auflösen.

Um den DNS-Server zu überprüfen, melde dich beim Worker-Knoten an und führe den folgenden Befehl aus:

nslookup fs-4fxxxxxx.efs.region.amazonaws.com AMAZON_PROVIDED_DNS_IP

Hinweis: Ersetze die Region durch deine AWS-Region. Ersetze AMAZON_PROVIDED_DNS_IP durch deine DNS-IP-Adresse.

Wenn der benutzerdefinierte DNS-Server die Anfragen nicht weiterleitet, erhältst du möglicherweise die folgende Fehlermeldung:

„Output: „fs-xxxxxx.efs.us-west-2.amazonaws.com" - The file system mount target ip address cannot be found“ konnte nicht gelöst werden

Wenn die Cluster-VPC einen benutzerdefinierten DNS-Server verwendet, konfiguriere diesen DNS-Server so, dass er alle***.amazonaws.com**-Anforderungen an den Amazon DNS-Server weiterleitet.

Vergewissere dich, dass die PersistentVolume-Definition die Mount-Optionen „iam“ enthält, wenn du eine restriktive Dateisystemrichtlinie verwendest

Wenn du die Mount-Option iam nicht mit einer restriktiven Dateisystemrichtlinie hinzufügst, schlagen die Pods mit der folgenden Fehlermeldung fehl:

„mount.nfs4: access denied by server while mounting 127.0.0.1:/“

Wenn du das Amazon EFS-Dateisystem so konfiguriert hast, dass die Mount-Berechtigungen auf bestimmte AWS Identity and Access Management (IAM)-Rollen beschränkt werden, verwende den Mount -o iam. Füge die Eigenschaft spec.mountOptions hinzu, damit der CSI-Treiber die IAM-Mount-Option hinzufügen kann.

Beispiel:

apiVersion: v1  
kind: PersistentVolume  
metadata:  
  name: efs-pv1  
spec:  
  mountOptions:  
    - iam

Stelle sicher, dass du das Amazon EFS-CSI-Treiber-Controller-Dienstkonto mit der richtigen IAM-Rolle versehen hast, die über die erforderlichen Berechtigungen verfügt.

Führe den folgenden Befehl aus, um zu überprüfen, ob das von den efs-csi-controller-Pods verwendete Dienstkonto die richtige Anmerkung enthält:

kubectl describe sa efs-csi-controller-sa -n kube-system

Beispielausgabe:

eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/AmazonEKS_EFS_CSI_DriverRole

Um zu bestätigen, dass das Konto über die richtigen Rollen und Berechtigungen für AWS Identity and Access Management (IAM) verfügt, überprüfe den IAM-OIDC-Anbieter für den Cluster. Stelle sicher, dass die IAM-Rolle, die dem Dienstkonto efs-csi-controller-sa zugeordnet ist, über die erforderlichen Berechtigungen zum Ausführen von EFS-API-Aufrufen verfügt. Stelle dann sicher, dass die Vertrauensrichtlinie der IAM-Rolle dem Dienstkonto efs-csi-controller-sa vertraut.

Beispiel für eine Vertrauensrichtlinie für IAM-Rollen:

{  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Effect": "Allow",  
      "Principal": {  
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"  
      },  
      "Action": "sts:AssumeRoleWithWebIdentity",  
      "Condition": {  
        "StringLike": {  
          "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:efs-csi-*",  
          "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"  
        }  
      }  
    }  
  ]  
}

Sicherstellen, dass die EFS-CSI-Treiber-Pods ausgeführt werden

Führe den folgenden Befehl aus, um zu überprüfen, ob diese Pods in deinem Cluster aktiv sind:

kubectl get all -l app.kubernetes.io/name=aws-efs-csi-driver -n kube-system

Überprüfe den EFS-Mount-Vorgang vom EC2-Worker-Knoten aus, auf dem der Pod das Dateisystem nicht mounten kann

Melde dich beim Amazon EKS-Worker-Knoten des Pods an. Verwende dann den EFS-Mount-Helper, um das EFS-Dateisystem manuell auf dem Worker-Knoten zu mounten. Führe den folgenden Befehl aus, um den Mount-Vorgang zu testen:

sudo mount -t efs -o tls file-system-dns-name efs-mount-point/

Wenn der Worker-Knoten das Dateisystem mounten kann, überprüfe die EFS-Plugin-Protokolle des CSI-Controllers und der CSI-Knoten-Pods.

Überprüfe die Pod-Protokolle des EFS-CSI-Treibers, um die Ursache der Mount-Fehler zu ermitteln.

Wenn das Volume nicht gemountet werden kann, überprüfe die EFS-Plugin-Protokolle. Führe die folgenden Befehle aus, um die EFS-Plugin-Container-Protokolle abzurufen:

kubectl logs deployment/efs-csi-controller -n kube-system -c efs-plugin  
kubectl logs daemonset/efs-csi-node -n kube-system -c efs-plugin