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

Lesedauer: 6 Minute
0

Ich möchte Amazon Elastic Block Store (Amazon EBS) -Volumes in meinen Amazon Elastic Kubernetes Service (Amazon EKS) -Cluster einbinden. Ich erhalte jedoch die Fehlermeldung „Timeout expired waiting for volumes to attach or mount for pod“.

Lösung

Bevor Sie mit den Schritten zur Fehlerbehebung beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

  • Die erforderlichen AWS Identity and Access Management (IAM) -Berechtigungen für Ihre IAM-Rolle für Ihr ebs-csi-controller-sa-Servicekonto.
    **Hinweis:**Informationen zur Behebung von Problemen mit Ihrem Servicekonto finden Sie im Abschnitt Überprüfen Sie die IAM-Rolle und die Berechtigungen des Amazon EBS CSI-Treiber-Controller-Servicekontos.
  • Ein gültiger PersistentVolumeClaim (PVC) (von der GitHub-Website) im selben Namespace wie der Pod.
  • Eine gültige EBS-Speicherklassendefinition, die den In-Tree-Provisioner kubernetes.io/aws-ebs (von derKubernetes-Website) verwendet. Oder eine Speicherklassendefinition, die den EBS Container Storage Interface (CSI) -Treiberprovider ebs.csi.aws.com verwendet (von der GitHub-Website).

Stellen Sie sicher, dass der Amazon EBS CSI-Treibercontroller und die Node-Pods laufen

Der EBS CSI-Treiber besteht aus Controller-Pods, die als Deployment ausgeführt werden, und Node-Pods, die als Daemon-Set ausgeführt werden. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob Ihr Cluster diese Pods ausführt:

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

**Hinweis:**Windows-Worker-Knoten und AWS Fargate unterstützen den EBS CSI-Treiber nicht.

Stellen Sie sicher, dass die installierte EBS CSI-Treiberversion mit der Kubernetes-Version Ihres Clusters kompatibel ist (von der GitHub-Website).

Prüfen Sie, ob das PVC bei der Bindung an das persistente EBS-Volume auf Probleme gestoßen ist

Um zu überprüfen, ob beim PVC Probleme auftreten, führen Sie den folgenden Befehl aus, um die Ereignisse anzuzeigen. Ersetzen Sie im folgenden Beispielbefehl PVC\ _NAME und NAMESPACE durch die richtigen Werte für Ihre Umgebung:

kubectl describe pvc PVC_NAME -n NAMESPACE

Wenn Sie Dynamic Volume Provisioning verwenden, überprüfen Sie anhand der zurückgegebenen Ereignisse, ob die Volume-Bereitstellung erfolgreich war oder nicht. Sie können auch den entsprechenden persistenten Volume-Namen sehen, an den das PVC gebunden ist, wie im folgenden Beispiel gezeigt:

Name:          ebs-claim
Namespace:     default
StorageClass:  ebs-sc
Status:        Bound
Volume:        pvc-5cbd76de-6f15-41e4-9948-2bba2574e205
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: ebs.csi.aws.com
               volume.kubernetes.io/selected-node: ip-10-0-2-57.ec2.internal
. . . . .
. . . . .
Events:
  Type    Reason                 Age                    From                                                                                      Message
  ----    ------                 ----                   ----                                                                                      -------
. . . . .
  Normal  Provisioning           5m22s                  ebs.csi.aws.com_ebs-csi-controller-57d4cbb9cc-dr9cd_8f0373e8-4e58-4dd0-b83c-da6f9ad5d5ce  External provisioner is provisioning volume for claim "default/ebs-claim"
  Normal  ProvisioningSucceeded  5m18s                  ebs.csi.aws.com_ebs-csi-controller-57d4cbb9cc-dr9cd_8f0373e8-4e58-4dd0-b83c-da6f9ad5d5ce  Successfully provisioned volume pvc-5cbd76de-6f15-41e4-9948-2bba2574e205

Wenn die Bereitstellung fehlgeschlagen ist, finden Sie die Fehlermeldung unter Ereignisse.

Überprüfen Sie die Protokolle der Amazon EBS CSI-Controller-Pods

Die Ursache der Mount-Fehler finden Sie in den Controller-Pod-Protokollen. Wenn das Volume bei der Erstellung ausfällt, sehen Sie in den Protokollen von ebs-Plugin ** und csi-Provisionen nach. Führen Sie die folgenden Befehle aus, um dieebs-Plugin**-Container-Logs abzurufen:

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

Führen Sie den folgenden Befehl aus, um die csi-Provisionen -Container-Logs abzurufen:

kubectl logs deployment/ebs-csi-controller -n kube-system -c csi-provisioner

Wenn die EBS-Volumes nicht an den Pod angeschlossen werden können, überprüfen Sie die csi-Attacher Protokolle. Führen Sie den folgenden Befehl aus, um die Csi-Attacher Container-Logs abzurufen:

kubectl logs deployment/ebs-csi-controller -n kube-system -c csi-attacher

Überprüfen Sie die IAM-Rolle und die Berechtigungen des Amazon EBS CSI-Treibercontroller-Servicekontos

**Hinweis:**Um die Debugging-Effizienz des EBS CSI-Treibers zu erhöhen, legen Sie die Debug-Log-Optionen fest (auf der GitHub-Website).

Stellen Sie sicher, dass das EBS CSI-Treiber-Controller-Dienstkonto mit der richtigen IAM-Rolle versehen ist. Stellen Sie außerdem sicher, dass die IAM-Rolle über die erforderlichen Berechtigungen verfügt.

Die folgenden Probleme führen zu unbefugten Fehlern in Ihren PVC-Ereignissen oder in Ihren ebs-csi-Controller Protokollen:

1.   Führen Sie den folgenden Befehl aus, um festzustellen, ob das Dienstkonto der ebs-csi-Controller Pods die richtige Anmerkung hat:

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

2.    Stellen Sie sicher, dass die folgende Anmerkung vorhanden ist:

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

3.    Stellen Sie sicher, dass Sie den IAM OpenID Connect (OIDC) -Anbieter für den Cluster erstellt haben. Stellen Sie außerdem sicher, dass die IAM-Rolle über die erforderlichen Berechtigungen verfügt , um EBS-API-Aufrufe auszuführen. Stellen Sie sicher, dass die Vertrauensrichtlinie der IAM-Rolle dem Dienstkonto ebs-csi-controller-sa vertraut.

3.    Stellen Sie sicher, dass AWS CloudTrail die CreateVolume-, ** AttachVolume** und DetachVolumeausführt. Überprüfen Sie dazu die CloudTrail-Protokolle. Überprüfen Sie außerdem die Protokolle, um festzustellen, welcher Principal die Anrufe tätigt. Auf diese Weise können Sie feststellen, ob der Controller- oder der Worker-Knoten-IAM-Rolle die IAM-Rolle des Dienstkontos verwendet.

Überprüfen Sie die Knotenaffinität des persistenten Volumes

Jedes persistente Volume hat eine Knotenaffinität, die das Anhängen persistenter Volumes an Knoten innerhalb einer einzelnen Availability Zone begrenzt. Dies liegt daran, dass Sie EBS-Volumes nur an Pods oder Knoten anhängen können, die in derselben Availability Zone ausgeführt werden, in der Sie diese erstellt haben. Wenn die geplanten Pods für Knoten in einer Availability Zone das persistente EBS-Volume in einer anderen Availability Zone verwenden, wird dieser Fehler angezeigt:

„Fehlgeschlagene Planung: 1 Knoten hatte einen Volumenknoten-Affinitätskonflikt"

Um dies zu vermeiden, verwenden Sie StatefulSets (von der Kubernetes-Website) anstelle von Deployment. Dadurch wird ein eindeutiges EBS-Volume für jeden Pod der StatefulSets in derselben Availability Zone wie der Pod erstellt.

Führen Sie den folgenden Befehl aus, um die Knotenaffinität des persistenten Volumes zu überprüfen. Ersetzen Sie PERSISTENT\ _VOLUME\ _NAME durch den Namen Ihres Volumes:

kubectl describe pv PERSISTENT_VOLUME_NAME

**Hinweis:**Sie können ein EBS-Volume nicht auf zwei verschiedene Pods mounten, die auf zwei verschiedenen Worker-Knoten laufen. Sie können das EBS-Volume an Pods anhängen, die auf einem Knoten laufen, aber Sie können es nicht gleichzeitig an einen anderen Knoten anhängen. Wenn Sie versuchen, Ihr EBS-Volume an zwei Pods auf verschiedenen Worker-Knoten anzuschließen, schlägt der Pod fehl und Sie erhalten folgenden Fehler:

„Warnung FailedAttachVolume 2m38s attachdetach-controller Multi-Attach-Controller Multi-Attach-Fehler für Volume „pvc-1cccsdfdc8-fsdf6-43d6-a1a9-ea837hf7h57fa“ Volume ist bereits exklusiv an einen Knoten angeschlossen und kann nicht an einen anderen angeschlossen werden"

Stellen Sie sicher, dass Ihre EBS-Controller-Pods mit der Amazon Elastic Compute Cloud (Amazon EC2) API verbunden sind

Wenn in den EBS-CSI-Controller Protokollen Fehler für Verbindungs-Timeouts angezeigt werden, ist der EBS CSI-Controller möglicherweise nicht mit der Amazon EC2-API verbunden. Wenn die Controller-Pods beim Erstellen Ihres PCs Verbindungsprobleme haben, wird dieser Fehler angezeigt:

„Warnung provisioningFailed persistentvolumeclaim/storage-volume-1 konnte das Volume mit StorageClass „ebs-sc“ nicht bereitstellen: RPC-Fehler: Code = DeadlineExceed desc = Kontext-Frist überschritten"

Um diesen Fehler zu beheben, überprüfen Sie, ob die Subnetze der EBS-Controller-Pods über eine Verbindung zur EC2-API verfügen. Wenn Sie einen privaten Cluster mit einem HTTP/HTTPS-Proxy ausführen, stellen Sie sicher, dass Ihre EBS CSI-Controller-Pods den HTTP/HTTPS-Proxy verwenden können. Die Helminstallation des EBS CSI-Treibers unterstützt die Einrichtung eines HTTP/HTTPS-Proxys (von der Kubernetes-Website).

Diese Meldung könnte sich auch auf ein Problem mit OIDC beziehen. Informationen zur Behebung von OIDC-Problemen finden Sie unter Wie behebe ich Probleme bei einem OIDC-Anbieter und IRSA in Amazon EKS?

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr