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.

Considerations

  • 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 1.1 des Treibers auf jeder unterstützten Amazon-EKS-Clusterversion bereitstellen.

  • Sie können Version 1.3.2 oder höher des Treibers mit Amazon EC2 Arm-Knoten verwenden.

Prerequisites

  • Vorhandener Cluster mit einem OIDC-Anbieter – Wenn Sie keinen Cluster haben, können Sie einen mithilfe einer der Erste Schritte mit Amazon EKS-Leitfäden erstellen. Um zu ermitteln, ob Sie einen OIDC-Anbieter für einen vorhandenen Cluster haben oder einen solchen erstellen möchten, lesen Sie Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster.

  • AWS CLI – Ein Befehlszeilen-Tool für die Arbeit mit AWS-Services, einschließlich Amazon EKS. Dieses Handbuch erfordert, dass Sie Version 2.2.37 oder höher oder 1.20.40 oder höher verwenden. Weitere Informationen finden Sie unter Installieren, Aktualisieren und Deinstallieren von AWS CLI im AWS Command Line Interface-Benutzerhandbuch. Nach der Installation des AWS CLI empfehlen wir, es auch zu konfigurieren. Weitere Informationen finden Sie unter Schnellkonfiguration mit aws configure im AWS Command Line Interface-Benutzerhandbuch.

  • kubectl – Ein Befehlszeilentool für die Arbeit mit Kubernetes-Clustern. Dieses Handbuch erfordert, dass Sie Version 1.21 oder höher verwenden. Weitere Informationen finden Sie unter Installieren von kubectl.

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/v1.3.2/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-Dienstkonto mit dem IAM-Rollen-ARN und die IAM-Rolle mit dem Kubernetes-Dienstkontonamen. Sie können die Rolle mit eksctl oder AWS CLI erstellen.

    eksctl

    Der folgende Befehl erstellt die IAM-Rolle und das Kubernetes-Dienstkonto. Außerdem wird die Richtlinie an die Rolle angehängt, das Kubernetes-Dienstkonto mit dem IAM-Rollen-ARN versehen und der Kubernetes-Dienstkontoname zur Vertrauensrichtlinie für die IAM-Rolle hinzugefügt. Wenn Sie keinen IAM-OIDC-Anbieter für Ihren Cluster haben, erstellt der Befehl auch den IAM-OIDC-Anbieter.

    eksctl create iamserviceaccount \ --name efs-csi-controller-sa \ --namespace kube-system \ --cluster <cluster-name> \ --attach-policy-arn arn:aws:iam::<Account ID>:policy/AmazonEKS_EFS_CSI_Driver_Policy \ --approve \ --override-existing-serviceaccounts \ --region <your-region-code>
    AWS CLI
    1. Bestimmen Sie die OIDC-Anbieter-URL Ihres Clusters. Ersetzen Sie <cluster_name> (einschließlich <>) durch Ihren Clusternamen. Wenn die Ausgabe des Befehls None ist, überprüfen Sie die Voraussetzungen.

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

      Ausgabe

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

      1. Kopieren Sie den folgenden Inhalt in eine Datei namens trust-policy.json. Ersetzen Sie <ACCOUNT_ID> (einschließlich <>) durch Ihre Konto-ID und <EXAMPLEXXX45D83924220DC4815XXXXX> und <your-region-code> durch den im vorherigen Schritt zurückgegebenen Wert.

        { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<your-region-code>.amazonaws.com/id/<EXAMPLEXXX45D83924220DC4815XXXXX>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.<your-region-code>.amazonaws.com/id/<EXAMPLEXXX45D83924220DC4815XXXXX>: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 <ACCOUNT_ID> (einschließlich <>) durch Ihre Konto-ID.

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

      1. Speichern Sie den folgenden Inhalt in einer Datei namens efs-service-account.yaml.

        --- apiVersion: v1 kind: ServiceAccount metadata: name: efs-csi-controller-sa namespace: kube-system labels: app.kubernetes.io/name: aws-efs-csi-driver annotations: eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/AmazonEKS_EFS_CSI_DriverRole
      2. Das Manifest anwenden.

        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 installieren die Version 1.3.2 des Treibers, die einen Cluster 1.17 oder höher erfordert. 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.

  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 das Diagramm. Wenn sich Ihr Cluster nicht in der us-west-2-Region befindet, ändern Sie 602401143452.dkr.ecr.us-west-2.amazonaws.com auf die Adresse für Ihre Region.

    helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \ --namespace kube-system \ --set image.repository=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/aws-efs-csi-driver \ --set controller.serviceAccount.create=false \ --set controller.serviceAccount.name=efs-csi-controller-sa
Manifest
  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" > driver.yaml
  2. Bearbeiten Sie die Datei und entfernen Sie die folgenden Zeilen, die ein Kubernetes-Dienstkonto erstellen. Dies ist nicht erforderlich, da das Service-Konto 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. Suchen Sie die folgende Zeile. Wenn sich Ihr Cluster nicht in der us-west-2 Region befindet, ersetzen Sie die folgende Adresse durch die Adresse für Ihre Region. Nachdem Sie die Änderung vorgenommen haben, speichern Sie Ihr geändertes Manifest.

    image: 602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/aws-efs-csi-driver:v1.3.2
  4. Das Manifest anwenden.

    kubectl apply -f 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 <cluster-name> (einschließlich <>) durch Ihren Clusternamen.

    vpc_id=$(aws eks describe-cluster \ --name <cluster-name> \ --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.

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

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

        kubectl get nodes

        Ausgabe

        NAME STATUS ROLES AGE VERSION ip-192-168-56-0.us-west-2.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

        Ausgabe

        | DescribeSubnets | +------------------+--------------------+----------------------------+ | AvailabilityZone | CidrBlock | SubnetId | +------------------+--------------------+----------------------------+ | us-west-2c | 192.168.128.0/19 | subnet-EXAMPLE6e421a0e97 | | us-west-2b | 192.168.96.0/19 | subnet-EXAMPLEd0503db0ec | | us-west-2c | 192.168.32.0/19 | subnet-EXAMPLEe2ba886490 | | us-west-2b | 192.168.0.0/19 | subnet-EXAMPLE123c7c5182 | | us-west-2a | 192.168.160.0/19 | subnet-EXAMPLE0416ce588p | | us-west-2a | 192.168.64.0/19 | subnet-EXAMPLE12c68ea7fb | +------------------+--------------------+----------------------------+
      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

(Optional) 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.

Dynamic
Wichtig

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

Prerequisite

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 eines Clusters.

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. 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
    2. Bearbeiten Sie die Datei und ersetzen Sie den Wert für fileSystemId durch Ihre Dateisystem-ID.

    3. 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

    Ausgabe

    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

    Ausgabe

    ... 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

    Ausgabe

    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

    Ausgabe

    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 Beispiel-App-Pods an.

    kubectl get pods -o wide

    Ausgabe

    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.us-west-2.compute.internal <none> <none>

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

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

    Ausgabe

    ... 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 ...
  8. (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. Schließen Sie Schritt 7 erneut ab und bestätigen Sie, 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

    Ausgabe:

    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

    Ausgabe:

    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

    Ausgabe:

    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

    Ausgabe:

    ... 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

    Ausgabe:

    ... 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.