Amazon EFS-CSI-Treiber - Amazon EKS

Amazon EFS-CSI-Treiber

Der Amazon EFS Container Storage Interface (CSI)-Treiber bietet eine CSI-Schnittstelle, die es Kubernetes-Clustern, die auf AWS ausgeführt werden, ermöglicht, den Lebenszyklus von Amazon EFS-Dateisystemen zu verwalten.

In diesem Thema erfahren Sie, wie Sie den Amazon-EFS-CSI-Treiber für Ihren Amazon-EKS-Cluster bereitstellen und überprüfen, ob er funktioniert.

Anmerkung

Alpha-Funktionen des Amazon-EFS-CSI-Treibers werden auf Amazon-EKS-Clustern nicht unterstützt.

Detaillierte Beschreibungen der verfügbaren Parameter und vollständige Beispiele, die die Funktionen des Treibers demonstrieren, finden Sie im Projekt Amazon EFS Container Storage Interface (CSI)-Treiber auf GitHub.

Überlegungen

  • Der Amazon-EFS-CSI-Treiber ist nicht mit Windows-basierten Container-Images kompatibel.

  • Sie können die dynamische Bereitstellung von persistenten Volumes nicht mit Fargate-Knoten verwenden, aber Sie können die statische Bereitstellung verwenden.

  • Die dynamische Bereitstellung erfordert 1.2 oder höher des Treibers, was einen Cluster 1.17 oder höher erfordert. Sie können persistente Volumes statisch mit Version 1.1 des Treibers auf jeder unterstützten Amazon-EKS-Clusterversion bereitstellen.

  • Version 1.3.2 oder höher dieses Treibers unterstützt die Arm64-Architektur, einschließlich auf Amazon EC2 Graviton basierenden Instances.

Voraussetzungen

  • Ein vorhandener Anbieter für AWS Identity and Access Management (IAM) OpenID Connect (OIDC) für Ihren Cluster. Informationen zum Feststellen, ob Sie bereits über einen verfügen oder einen erstellen müssen, finden Sie unter Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster.

  • Version 2.6.3 oder höher oder 1.23.11 oder höher der auf Ihrem Computer oder AWS CloudShell installierten und konfigurierten AWS CLI. Weitere Informationen finden Sie unter Installation, Aktualisierung und Deinstallation der AWS CLI und Schnellkonfiguration mit aws configure im AWS Command Line Interface-Benutzerhandbuch.

  • Das kubectl-Befehlszeilen-Tool ist auf Ihrem Computer oder AWS CloudShell installiert. Die Version kann der Kubernetes-Version Ihres Clusters entsprechen oder eine Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise 1.21 ist, können Sie kubectl-Version 1.20, 1.21 oder 1.22 damit verwenden. Informationen zum Installieren oder Aktualisieren von kubectl finden Sie unter Installieren von kubectl.

Anmerkung

Ein auf AWS Fargate ausgeführter Pod mountet automatisch ein Amazon EFS-Dateisystem, ohne die auf dieser Seite beschriebenen manuellen Treiberinstallationsschritte zu benötigen.

Erstellen Sie eine IAM-Richtlinie und -Rolle

Erstellen Sie eine IAM-Richtlinie und weisen Sie sie einer IAM-Rolle zu. Die Richtlinie ermöglicht es dem Amazon-EFS-Treiber, mit Ihrem Dateisystem zu interagieren.

So stellen Sie den Amazon-EFS-CSI-Treiber für einen Amazon-EKS-Cluster bereit

  1. Erstellen Sie eine IAM-Richtlinie, mit welcher das Service-Konto des CSI-Treibers in Ihrem Namen Aufrufe an AWS-APIs tätigen kann.

    1. Laden Sie das IAM-Richtliniendokument von GitHub herunter. Sie können auch das Richtliniendokument anzeigen.

      curl -o iam-policy-example.json https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/docs/iam-policy-example.json
    2. Erstellen Sie die Richtlinie. Sie können AmazonEKS_EFS_CSI_Driver_Policy in einen anderen Namen ändern, aber wenn Sie dies tun, stellen Sie sicher, dass Sie ihn auch in späteren Schritten ändern.

      aws iam create-policy \ --policy-name AmazonEKS_EFS_CSI_Driver_Policy \ --policy-document file://iam-policy-example.json
  2. Erstellen Sie eine IAM-Rolle und fügen Sie ihr die IAM-Richtlinie an. Versehen Sie das Kubernetes-Servicekonto mit dem IAM-Rollen-ARN und die IAM-Rolle mit dem Kubernetes-Servicekontonamen. Sie können die Rolle mit eksctl oder AWS CLI erstellen.

    eksctl

    Führen Sie den folgenden Befehl aus, um die IAM-Rolle und das Kubernetes-Servicekonto zu erstellen. Außerdem wird die Richtlinie an die Rolle angehängt, das Kubernetes-Servicekonto mit dem IAM-Rollen-ARN versehen und der Kubernetes-Servicekontoname zur Vertrauensrichtlinie für die IAM-Rolle hinzugefügt. Ersetzen Sie my-cluster durch Ihren Cluster und 111122223333 durch Ihre Konto-ID. Ersetzen Sie den region-code durch die AWS-Region, in der sich Ihr Cluster befindet. Wenn sich Ihr Cluster in den AWS-Regionen AWS GovCloud (USA Ost) oder AWS GovCloud (USA West) befindet, ersetzen Sie arn:aws: durch arn:aws-us-gov:.

    eksctl create iamserviceaccount \ --cluster my-cluster \ --namespace kube-system \ --name efs-csi-controller-sa \ --attach-policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_EFS_CSI_Driver_Policy \ --approve \ --region region-code
    AWS CLI
    1. Bestimmen Sie die OIDC-Anbieter-URL Ihres Clusters. Ersetzen Sie my-cluster durch Ihren Clusternamen. Wenn die Ausgabe des Befehls None ist, überprüfen Sie die Voraussetzungen.

      aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text

      Die Beispielausgabe lautet wie folgt.

      https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
    2. Erstellen Sie die IAM-Rolle und weisen Sie dem Kubernetes-Servicekonto die AssumeRoleWithWebIdentity-Aktion zu.

      1. Kopieren Sie den folgenden Inhalt in eine Datei namens trust-policy.json. Ersetzen Sie 111122223333 durch Ihre Konto-ID. Ersetzen Sie EXAMPLED539D4633E53DE1B71EXAMPLE und region-code mit den im vorherigen Schritt zurückgegebenen Werten. Wenn sich Ihr Cluster in den AWS-Regionen AWS GovCloud (USA Ost) oder AWS GovCloud (USA West) befindet, ersetzen Sie arn:aws: durch arn:aws-us-gov:.

        { "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": { "StringEquals": { "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:efs-csi-controller-sa" } } } ] }
      2. Erstellen Sie die -Rolle. Sie können AmazonEKS_EFS_CSI_DriverRole in einen anderen Namen ändern, aber wenn Sie dies tun, stellen Sie sicher, dass Sie ihn auch in späteren Schritten ändern.

        aws iam create-role \ --role-name AmazonEKS_EFS_CSI_DriverRole \ --assume-role-policy-document file://"trust-policy.json"
    3. Fügen Sie die IAM-Richtlinie an die Rolle an. Ersetzen Sie 111122223333 durch Ihre Konto-ID. Wenn sich Ihr Cluster in den AWS-Regionen AWS GovCloud (USA Ost) oder AWS GovCloud (USA West) befindet, ersetzen Sie arn:aws: durch arn:aws-us-gov:, bevor Sie folgenden Befehl ausführen.

      aws iam attach-role-policy \ --policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_EFS_CSI_Driver_Policy \ --role-name AmazonEKS_EFS_CSI_DriverRole
    4. Erstellen Sie ein Kubernetes-Servicekonto, das mit dem ARN der von Ihnen erstellten IAM-Rolle versehen ist.

      1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen efs-service-account.yaml. Ersetzen Sie 111122223333 durch Ihre Konto-ID. Wenn sich Ihr Cluster in den AWS-Regionen AWS GovCloud (USA Ost) oder AWS GovCloud (USA West) befindet, ersetzen Sie arn:aws: durch arn:aws-us-gov:.

        --- apiVersion: v1 kind: ServiceAccount metadata: labels: app.kubernetes.io/name: aws-efs-csi-driver name: efs-csi-controller-sa namespace: kube-system annotations: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/AmazonEKS_EFS_CSI_DriverRole
      2. Erstellen Sie das Kubernetes-Servicekonto in Ihrem Cluster. Das Kubernetes-Servicekonto namens efs-csi-controller-sa wird mit der von Ihnen erstellten IAM-Rolle namens AmazonEKS_EFS_CSI_DriverRole annotiert.

        kubectl apply -f efs-service-account.yaml

Installieren Sie den Amazon-EFS-Treiber

Installieren Sie den Amazon-EFS-CSI-Treiber mit Helm oder einem Manifest.

Wichtig
  • Die folgenden Schritte erfordern einen Cluster mit Version 1.17 oder höher. Wenn Sie den Treiber auf einem Cluster vor Version 1.17 installieren, müssen Sie Version 1.1 des Treibers installieren. Weitere Informationen finden Sie unter Amazon EFS CSI-Treiber auf GitHub.

  • Die Verschlüsselung von Daten während der Übertragung mit TLS ist standardmäßig aktiviert. Durch die Verschlüsselung bei der Übertragung werden Daten während des Übergangs über das Netzwerk zum Amazon-EFS-Service verschlüsselt. Um es zu deaktivieren und Volumes mit NFSv4 zu binden, setzen Sie das volumeAttributes-Feld encryptInTransit auf "false" in Ihrem persistenten Volume-Manifest. Ein Beispielmanifest finden Sie unter Beispiel für Verschlüsselung in Übertragung auf GitHub.

Helm

Dieses Verfahren erfordert Helm V3 oder höher. Informationen zum Installieren oder Aktualisieren von Helm finden Sie unter Verwendung von Helm mit Amazon EKS.

So installieren Sie den Treiber mit Helm

  1. Fügen Sie das Helm-Repository hinzu.

    helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
  2. Aktualisieren Sie das Repository.

    helm repo update
  3. Installieren Sie eine Version des Treibers mithilfe des Helm-Charts. Ersetzen Sie die Repository-Adresse durch die Container-Image-Adresse des Clusters.

    helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \ --namespace kube-system \ --set image.repository=602401143452.dkr.ecr.region-code.amazonaws.com/eks/aws-efs-csi-driver \ --set controller.serviceAccount.create=false \ --set controller.serviceAccount.name=efs-csi-controller-sa
Manifest (private registry)

Wenn Sie das Image mit einem Manifest herunterladen möchten, sollten Sie zunächst die folgenden Schritte ausprobieren, um gesicherte Images aus der privaten Amazon-ECR-Registrierung abzurufen.

So installieren Sie den Treiber mit Images aus der privaten Amazon-ECR-Registrierung

  1. Laden Sie das Manifest herunter.

    kubectl kustomize \ "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/ecr?ref=release-1.3" > private-ecr-driver.yaml
    Anmerkung

    Wenn ein Problem auftritt, das Sie durch Hinzufügen von IAM-Berechtigungen nicht beheben können, versuchen Sie stattdessen die Schritte unter „Manifest (öffentliche Registrierung)“.

  2. Ersetzen Sie im folgenden Befehl region-code durch die AWS-Region, in der sich Ihr Cluster befindet, und führen Sie dann den geänderten Befehl aus, um us-west-2 in der Datei durch Ihre AWS-Region zu ersetzen.

    sed -i.bak -e 's|us-west-2|region-code|' private-ecr-driver.yaml
  3. Ersetzen Sie account im folgenden Befehl durch das Konto aus Registrierungen für Amazon-Container-Images für die AWS-Region, in der sich Ihr Cluster befindet, und führen Sie dann den geänderten Befehl aus, um 602401143452 in der Datei zu ersetzen.

    sed -i.bak -e 's|602401143452|account|' private-ecr-driver.yaml
  4. Bearbeiten Sie die private-ecr-driver.yaml-Datei und entfernen Sie die folgenden Zeilen, die ein Kubernetes-Servicekonto erstellen. Diese Zeilen werden nicht benötigt, da das Servicekonto in einem vorherigen Schritt erstellt wurde.

    apiVersion: v1 kind: ServiceAccount metadata: labels: app.kubernetes.io/name: aws-efs-csi-driver name: efs-csi-controller-sa namespace: kube-system ---
  5. Das Manifest anwenden.

    kubectl apply -f private-ecr-driver.yaml
Manifest (public registry)

In einigen Situationen lassen sich die erforderlichen IAM-Berechtigungen für das Abrufen aus der privaten Amazon-ECR-Registrierung möglicherweise nicht hinzufügen. Das ist zum Beispiel der Fall, wenn sich der IAM-Benutzer oder die IAM-Rolle nicht mit dem Konto einer anderen Person authentifizieren darf. In einem solchen Fall können Sie die öffentliche Amazon-ECR-Registrierung verwenden.

So installieren Sie den Treiber mit Images aus der öffentlichen Amazon-ECR-Registrierung

  1. Laden Sie das Manifest herunter.

    kubectl kustomize \ "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.3" > public-ecr-driver.yaml
  2. Bearbeiten Sie die -Datei und entfernen Sie die folgenden Zeilen, die ein Kubernetes-Servicekonto erstellen. Dies ist nicht erforderlich, da das Servicekonto in einem vorherigen Schritt erstellt wurde.

    apiVersion: v1 kind: ServiceAccount metadata: labels: app.kubernetes.io/name: aws-efs-csi-driver name: efs-csi-controller-sa namespace: kube-system ---
  3. Das Manifest anwenden.

    kubectl apply -f public-ecr-driver.yaml

Erstellen eines Amazon EFS-Dateisystems

Der Amazon EFS CSI-Treiber unterstützt Amazon-EFS-Zugriffspunkte, bei denen es sich um anwendungsspezifische Einstiegspunkte in ein Amazon EFS-Dateisystem handelt, die die gemeinsame Nutzung eines Dateisystems durch mehrere Pods erleichtern. Zugriffspunkte können eine Benutzeridentität für alle Dateisystemanforderungen erzwingen, die über den Zugriffspunkt gestellt werden, und ein Stammverzeichnis für jeden Pod erzwingen. Weitere Informationen finden Sie unter Amazon-EFS-Zugriffspunkte auf GitHub.

Wichtig

Sie müssen die folgenden Schritte im selben Terminal ausführen, da Variablen in den Schritten festgelegt und verwendet werden.

So erstellen Sie ein Amazon-EFS-Dateisystem für Ihren Amazon-EKS-Cluster

  1. Rufen Sie die VPC-ID ab, in der sich Ihr Cluster befindet, und speichern Sie sie zur Verwendung in einem späteren Schritt in einer Variable. Ersetzen Sie my-cluster mit Ihrem Clusternamen.

    vpc_id=$(aws eks describe-cluster \ --name my-cluster \ --query "cluster.resourcesVpcConfig.vpcId" \ --output text)
  2. Rufen Sie den CIDR-Bereich für die VPC Ihres Clusters ab und speichern Sie ihn zur Verwendung in einem späteren Schritt in einer Variablen.

    cidr_range=$(aws ec2 describe-vpcs \ --vpc-ids $vpc_id \ --query "Vpcs[].CidrBlock" \ --output text)
  3. Erstellen Sie eine Sicherheitsgruppe mit einer eingehenden Regel, die eingehenden NFS-Datenverkehr für Ihre Amazon-EFS-Bindungsbereitstellungs-Punkte zulässt.

    1. Erstellen einer Sicherheitsgruppe. Ersetzen Sie das example values durch Ihr eigenes.

      security_group_id=$(aws ec2 create-security-group \ --group-name MyEfsSecurityGroup \ --description "My EFS security group" \ --vpc-id $vpc_id \ --output text)
    2. Erstellen Sie eine eingehende Regel, die eingehenden NFS-Traffic vom CIDR für die VPC Ihres Clusters zulässt.

      aws ec2 authorize-security-group-ingress \ --group-id $security_group_id \ --protocol tcp \ --port 2049 \ --cidr $cidr_range
      Wichtig

      Um den Zugriff auf Ihr Dateisystem weiter einzuschränken, können Sie anstelle der VPC das CIDR für Ihr Subnetz verwenden.

  4. Erstellen eines Amazon-EFS-Dateisystem für Ihren Amazon EKS-Cluster.

    1. Erstellen eines Dateisystems. Ersetzen Sie den region-code durch die AWS-Region, in der sich Ihr Cluster befindet.

      file_system_id=$(aws efs create-file-system \ --region region-code \ --performance-mode generalPurpose \ --query 'FileSystemId' \ --output text)
    2. Erstellen von Bindungsbereitstellungs-Zielen.

      1. Ermitteln von IP-Adressen Ihrer Cluster-Knoten.

        kubectl get nodes

        Die Beispielausgabe lautet wie folgt.

        NAME STATUS ROLES AGE VERSION ip-192-168-56-0.region-code.compute.internal Ready <none> 19m v1.19.6-eks-49a6c0
      2. Ermitteln Sie die IDs der Subnetze in Ihrer VPC und in welcher Availability Zone sich das Subnetz befindet.

        aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=$vpc_id" \ --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \ --output table

        Die Beispielausgabe lautet wie folgt.

        | DescribeSubnets | +------------------+--------------------+----------------------------+ | AvailabilityZone | CidrBlock | SubnetId | +------------------+--------------------+----------------------------+ | region-codec | 192.168.128.0/19 | subnet-EXAMPLE6e421a0e97 | | region-codeb | 192.168.96.0/19 | subnet-EXAMPLEd0503db0ec | | region-codec | 192.168.32.0/19 | subnet-EXAMPLEe2ba886490 | | region-codeb | 192.168.0.0/19 | subnet-EXAMPLE123c7c5182 | | region-codea | 192.168.160.0/19 | subnet-EXAMPLE0416ce588p | +------------------+--------------------+----------------------------+
      3. Fügen Sie Bindungsbereitstellungs-Ziele für die Subnetze hinzu, in denen sich Ihre Knoten befinden. Aus der Ausgabe in den vorherigen beiden Schritten geht hervor, dass der Cluster einen Knoten mit der IP-Adresse 192.168.56.0 hat. Diese IP-Adresse befindet sich im CidrBlock des Subnetzes mit der ID subnet-EXAMPLEe2ba886490. Als Ergebnis erstellt der folgende Befehl ein Bindungsbereitstellungs-Ziel für das Subnetz, in dem sich der Knoten befindet. Wenn der Cluster mehr Knoten enthält, führen Sie den Befehl einmal für ein Subnetz in jeder AZ aus, in der sich ein Knoten befindet, und ersetzen Sie subnet-EXAMPLEe2ba886490 durch die entsprechende Subnetz-ID.

        aws efs create-mount-target \ --file-system-id $file_system_id \ --subnet-id subnet-EXAMPLEe2ba886490 \ --security-groups $security_group_id

Bereitstellen einer -Beispielanwendung

Sie können eine Beispiel-App bereitstellen, die dynamisch ein persistentes Volume erstellt, oder Sie können ein persistentes Volume manuell erstellen. Sie können die in diesem Abschnitt angegebenen Beispiele durch eine andere Anwendung ersetzen.

Dynamic
Wichtig

Sie können die dynamische Bereitstellung nicht mit Fargate-Knoten verwenden.

Voraussetzung

Sie müssen Version 1.2x oder höher des Amazon-EFS-CSI-Treibers verwenden, für den ein Cluster 1.17 oder höher erforderlich ist. Informationen zum Aktualisieren Ihres Clusters finden Sie unter Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version.

So stellen Sie eine Beispielanwendung bereit, die ein vom Controller erstelltes persistentes Volume verwendet

Dieses Verfahren verwendet das Dynamische Bereitstellungs-Beispiel aus dem GitHub-Repository des Amazon EFS Container Storage Interface (CSI)-Treibers. Es erstellt dynamisch ein persistentes Volume über Amazon-EFS-Zugriffspunkte und einen Persistent Volume Claim (PVC), der von einem Pod genutzt wird.

  1. Erstellen Sie eine Speicherklasse für EFS. Alle Parameter und Konfigurationsoptionen finden Sie unter Amazon EFS CSI Treiber auf GitHub.

    1. Rufen Sie Ihre Amazon-EFS-Dateisystem-ID ab. Sie finden diese in der Amazon-EFS-Konsole oder verwenden den folgenden AWS CLI-Befehl.

      aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text

      Die Beispielausgabe lautet wie folgt.

      fs-582a03f3
    2. Laden Sie ein StorageClass-Manifest für Amazon EFS herunter.

      curl -o storageclass.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
    3. Bearbeiten Sie die -Datei. Suchen Sie die folgende Zeile und ersetzen Sie den Wert für fileSystemId durch die ID Ihres Dateisystems.

      fileSystemId: fs-582a03f3
    4. Stellen Sie die Speicherklasse bereit.

      kubectl apply -f storageclass.yaml
  2. Testen Sie die automatische Bereitstellung, indem Sie einen Pod bereitstellen, der das PersistentVolumeClaim verwendet:

    1. Laden Sie ein Manifest herunter, das einen Pod und einen PersistentVolumeClaim bereitstellt.

      curl -o pod.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
    2. Stellen Sie den Pod mit einer Beispiel-App und dem vom Pod verwendeten PersistentVolumeClaim bereit.

      kubectl apply -f pod.yaml
  3. Bestimmen Sie die Namen der Pods, auf denen der Controller ausgeführt wird.

    kubectl get pods -n kube-system | grep efs-csi-controller

    Die Beispielausgabe lautet wie folgt.

    efs-csi-controller-74ccf9f566-q5989 3/3 Running 0 40m efs-csi-controller-74ccf9f566-wswg9 3/3 Running 0 40m
  4. Nach einigen Sekunden können Sie beobachten, wie der Controller die Änderung aufnimmt (aus Gründen der Lesbarkeit bearbeitet). Ersetzen Sie 74ccf9f566-q5989 durch einen Wert aus einem der Pods in Ihrer Ausgabe des vorherigen Befehls.

    kubectl logs efs-csi-controller-74ccf9f566-q5989 \ -n kube-system \ -c csi-provisioner \ --tail 10

    Die Beispielausgabe lautet wie folgt.

    ... 1 controller.go:737] successfully created PV pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca for PVC efs-claim and csi volume name fs-95bcec92::fsap-02a88145b865d3a87

    Wenn die vorherige Ausgabe nicht angezeigt wird, führen Sie den vorherigen Befehl mit einem der anderen Controller-Pods aus.

  5. Bestätigen Sie, dass ein persistentes Volume mit einem Status von Bound bis PersistentVolumeClaim erstellt wurde:

    kubectl get pv

    Die Beispielausgabe lautet wie folgt.

    NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca 20Gi RWX Delete Bound default/efs-claim efs-sc 7m57s
  6. Zeigen Sie Details zum erstellten PersistentVolumeClaim an.

    kubectl get pvc

    Die Beispielausgabe lautet wie folgt.

    NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE efs-claim Bound pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca 20Gi RWX efs-sc 9m7s
  7. Zeigen Sie den Status des Pods der Beispiel-App an, bis aus STATUS Running wird.

    kubectl get pods -o wide

    Die Beispielausgabe lautet wie folgt.

    NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES efs-example 1/1 Running 0 10m 192.168.78.156 ip-192-168-73-191.region-code.compute.internal <none> <none>
    Anmerkung

    Wenn für einen Pod keine IP-Adresse aufgeführt ist, vergewissern Sie sich, dass Sie ein Mountingziel für das Subnetz hinzugefügt haben, in dem sich Ihr Knoten befindet (wie am Ende von Erstellen eines Amazon EFS-Dateisystems beschrieben). Ansonsten bleibt der Pod im Status ContainerCreating. Wenn eine IP-Adresse aufgeführt ist, kann es einige Minuten dauern, bis ein Pod den Status Running erreicht.

  8. Bestätigen Sie, dass die Daten auf das Volume geschrieben wurden.

    kubectl exec efs-app -- bash -c "cat data/out"

    Die Beispielausgabe lautet wie folgt.

    ... Tue Mar 23 14:29:16 UTC 2021 Tue Mar 23 14:29:21 UTC 2021 Tue Mar 23 14:29:26 UTC 2021 Tue Mar 23 14:29:31 UTC 2021 ...
  9. (Optional) Beenden Sie den Amazon-EKS-Knoten, auf dem Ihr Pod ausgeführt wird, und warten Sie, bis der Pod neu geplant wird. Alternativ können Sie den Pod löschen und erneut bereitstellen. Führen Sie den vorherigen Schritt erneut durch und vergewissern Sie sich, dass die Ausgabe die vorherige Ausgabe enthält.

Static

So stellen Sie eine Beispielanwendung bereit, die ein von Ihnen erstelltes persistentes Volume verwendet

Dieses Verfahren verwendet das Beispiel Multiple Pods Read Write Many aus dem GitHub-Repository des Amazon EFS Container Storage Interface (CSI)-Treibers, um ein statisch bereitgestelltes persistentes Amazon-EFS-Volume zu nutzen und von mehreren Pods mit dem ReadWriteMany-Zugriffsmodus darauf zuzugreifen.

  1. Klonen Sie das GitHub-Repository des Amazon EFS Container Storage Interface (CSI)-Treibers auf Ihr lokales System.

    git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git
  2. Navigieren Sie zum multiple_pods-Beispielverzeichnis.

    cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/
  3. Rufen Sie Ihre Amazon-EFS-Dateisystem-ID ab. Sie finden diese in der Amazon-EFS-Konsole oder verwenden den folgenden AWS CLI-Befehl.

    aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text

    Die Beispielausgabe lautet wie folgt.

    fs-582a03f3
  4. Bearbeiten Sie die specs/pv.yaml-Datei und ersetzen Sie den volumeHandle-Wert durch Ihre Amazon-EFS-Dateisystem-ID.

    apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-sc csi: driver: efs.csi.aws.com volumeHandle: fs-582a03f3
    Anmerkung

    Da Amazon EFS ein elastisches Dateisystem ist, werden keine Kapazitätsgrenzen für das Dateisystem erzwungen. Der tatsächliche Speicherkapazitätswert in persistenten Volumes und Ansprüchen für persistente Volumes wird beim Erstellen des Dateisystems nicht verwendet. Da die Speicherkapazität in Kubernetes jedoch ein Pflichtfeld ist, müssen Sie in diesem Beispiel einen gültigen Wert angeben, z. B. 5Gi. Dieser Wert begrenzt nicht die Größe Ihres Amazon-EFS-Dateisystems.

  5. Stellen Sie die Speicherklasse efs-sc, den persistenten Datenträgeranspruch efs-claim und den persistenten Datenträger efs-pv aus dem Verzeichnis specs bereit.

    kubectl apply -f specs/pv.yaml kubectl apply -f specs/claim.yaml kubectl apply -f specs/storageclass.yaml
  6. Listen Sie die persistenten Volumes im Standard-Namespace auf. Suchen Sie nach einem persistenten Volume mit dem default/efs-claim-Anspruch.

    kubectl get pv -w

    Die Beispielausgabe lautet wie folgt.

    NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE efs-pv 5Gi RWX Retain Bound default/efs-claim efs-sc 2m50s

    Fahren Sie nicht mit dem nächsten Schritt fort, bis STATUS die Bound.

  7. Stellen Sie die app1- und app2-Beispielanwendungen aus dem specs-Verzeichnis bereit.

    kubectl apply -f specs/pod1.yaml kubectl apply -f specs/pod2.yaml
  8. Beobachten Sie die Pods im Standard-Namespace und warten Sie, bis das STATUS der app1- und app2-Pods Running wird.

    kubectl get pods --watch
    Anmerkung

    Es kann einige Minuten dauern, bis die Pods den Running-Status erreichen.

  9. Beschreiben Sie das persistente Volume.

    kubectl describe pv efs-pv

    Die Beispielausgabe lautet wie folgt.

    Name: efs-pv Labels: none Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"name":"efs-pv"},"spec":{"accessModes":["ReadWriteMany"],"capaci... pv.kubernetes.io/bound-by-controller: yes Finalizers: [kubernetes.io/pv-protection] StorageClass: efs-sc Status: Bound Claim: default/efs-claim Reclaim Policy: Retain Access Modes: RWX VolumeMode: Filesystem Capacity: 5Gi Node Affinity: none Message: Source: Type: CSI (a Container Storage Interface (CSI) volume source) Driver: efs.csi.aws.com VolumeHandle: fs-582a03f3 ReadOnly: false VolumeAttributes: none Events: none

    Die Amazon EFS-Dateisystem-ID wird als VolumeHandle aufgeführt.

  10. Überprüfen Sie, ob der app1-Pod erfolgreich Daten auf das Volume schreibt.

    kubectl exec -ti app1 -- tail /data/out1.txt

    Die Beispielausgabe lautet wie folgt.

    ... Mon Mar 22 18:18:22 UTC 2021 Mon Mar 22 18:18:27 UTC 2021 Mon Mar 22 18:18:32 UTC 2021 Mon Mar 22 18:18:37 UTC 2021 ...
  11. Stellen Sie sicher, dass der app2-Pod die gleichen Daten im Volume anzeigt, die app1 auf das Volume geschrieben hat.

    kubectl exec -ti app2 -- tail /data/out1.txt

    Die Beispielausgabe lautet wie folgt.

    ... Mon Mar 22 18:18:22 UTC 2021 Mon Mar 22 18:18:27 UTC 2021 Mon Mar 22 18:18:32 UTC 2021 Mon Mar 22 18:18:37 UTC 2021 ...
  12. Wenn Sie das Experimentieren abgeschlossen haben, löschen Sie die Ressourcen für diese Beispielanwendung, um sie zu bereinigen.

    kubectl delete -f specs/

    Sie können das Dateisystem und die Sicherheitsgruppe, die Sie erstellt haben, auch manuell löschen.