Driver CSI per Amazon EFS - Amazon EKS

Driver CSI per Amazon EFS

Il driver Container Storage Interface (CSI) per Amazon EFS mette a disposizione un'interfaccia CSI che consente ai cluster Kubernetes in esecuzione su AWS di gestire il ciclo di vita dei file system Amazon EFS.

Questo argomento illustra come implementare il driver CSI per Amazon EFS nel cluster Amazon EKS e come verificarne il funzionamento.

Nota

Le caratteristiche alfa del driver CSI per Amazon EFS non sono supportate nei cluster Amazon EKS.

Per una descrizione dettagliata dei parametri disponibili e per esempi completi che illustrano le caratteristiche del driver, consultare il progetto Driver Container Storage Interface (CSI) per Amazon EFS su GitHub.

Considerazioni

  • Il driver CSI per Amazon EFS non è compatibile con le immagini container basate su Windows.

  • Non è possibile utilizzare il provisioning dinamico dei volumi persistenti con nodi Fargate, ma è possibile utilizzare il provisioning statico.

  • Il provisioning dinamico richiede la versione 1.2 o successiva del driver, che richiede, a sua volta, un cluster aggiornato alla versione 1.17 o successiva. È possibile eseguire il provisioning statico di volumi persistenti utilizzando la versione 1.1 del driver su qualsiasi versione del cluster Amazon EKS supportata.

  • La versione 1.3.2 o successiva di questo driver supporta l'architettura Arm64, incluse le istanze basate su Graviton di Amazon EC2.

Prerequisiti

Nota

Un pod in esecuzione su AWS Fargate monta automaticamente un file system Amazon EFS senza bisogno della procedura di installazione manuale del driver descritta in questa pagina.

Creare una policy IAM ed un ruolo IAM

Creare un policy IAM da assegnare ad un ruolo IAM. La policy permetterà al driver di Amazon EFS di interagire con il proprio file system.

Per implementare il driver CSI per Amazon EFS in un cluster Amazon EKS

  1. Creare una policy IAM che consenta all'account di servizio del driver CSI di effettuare chiamate alle API AWS per conto dell'utente.

    1. Eseguire il download del documento di policy IAM da GitHub. É possibile visualizzare il documento di policy.

      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. Creare la policy. È possibile modificare AmazonEKS_EFS_CSI_Driver_Policy con un nome diverso. Se lo si fa, assicurarsi di modificarlo anche nei passaggi successivi.

      aws iam create-policy \ --policy-name AmazonEKS_EFS_CSI_Driver_Policy \ --policy-document file://iam-policy-example.json
  2. Creare un ruolo IAM e collegarvi la policy IAM. Annotare l'account del servizio Kubernetes con l'ARN del ruolo IAM e il ruolo IAM con il nome dell'account di servizio Kubernetes. È possibile creare il ruolo utilizzando eksctl o la AWS CLI.

    eksctl

    Eseguire il comando seguente per creare il ruolo IAM e l'account di servizio Kubernetes. Allega inoltre la policy al ruolo, annota l'account di servizio Kubernetes con l'ARN del ruolo IAM e aggiunge il nome dell'account di servizio Kubernetes alla policy di trust per il ruolo IAM. Sostituisci my-cluster con il nome del cluster, 111122223333 con il tuo ID account e region-code con la Regione AWS in cui si trova il cluster.

    eksctl create iamserviceaccount \ --name efs-csi-controller-sa \ --namespace kube-system \ --cluster my-cluster \ --attach-policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_EFS_CSI_Driver_Policy \ --approve \ --override-existing-serviceaccounts \ --region region-code
    AWS CLI
    1. Determinare l'URL del provider OIDC del proprio cluster. Sostituire my-cluster con il nome del cluster. Se l'output dal comando è None, rivedere i Prerequisiti.

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

      Output

      https://oidc.eks.region-code.amazonaws.com/id/oidc-id
    2. Creare il ruolo IAM, concedendo all'account di servizio Kubernetes l'operazione AssumeRoleWithWebIdentity.

      1. Copiare i contenuti seguenti in un file denominato trust-policy.json. Sostituire 111122223333 con l'ID del proprio account. Sostituire oidc-id e region-code con i valori restituiti nella fase precedente.

        { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/oidc-id" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.region-code.amazonaws.com/id/oidc-id:sub": "system:serviceaccount:kube-system:efs-csi-controller-sa" } } } ] }
      2. Creare il ruolo. È possibile modificare AmazonEKS_EFS_CSI_DriverRole con un nome diverso. Se lo si fa, assicurarsi di modificarlo anche nei passaggi successivi.

        aws iam create-role \ --role-name AmazonEKS_EFS_CSI_DriverRole \ --assume-role-policy-document file://"trust-policy.json"
    3. Allegare la policy IAM al ruolo. Sostituire 111122223333 con l'ID del proprio account.

      aws iam attach-role-policy \ --policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_EFS_CSI_Driver_Policy \ --role-name AmazonEKS_EFS_CSI_DriverRole
    4. Creare un account di servizio Kubernetes annotato con l'ARN del ruolo IAM creato.

      1. Salvare i seguenti contenuti in un file denominato efs-service-account.yaml. Sostituire 111122223333 con l'ID del proprio account.

        --- 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::111122223333:role/AmazonEKS_EFS_CSI_DriverRole
      2. Applicare il file manifesto.

        kubectl apply -f efs-service-account.yaml

Installare il driver Amazon EFS

Installazione del driver CSI per Amazon EFS utilizzando Helm o un manifesto.

Importante
  • La procedura seguente consente di installare la versione 1.3.2 del driver, che richiede un cluster alla versione 1.17 o successiva. Se si installa il driver in un cluster precedente alla versione 1.17, è necessario installare la versione 1.1 del driver. Per ulteriori informazioni, consultare Driver CSI per Amazon EFS su GitHub.

  • La crittografia dei dati in transito è abilitata per impostazione predefinita usando TLS. Utilizzo di crittografia in transito, i dati vengono crittografati durante la transizione attraverso la rete al servizio Amazon EFS. Per disabilitarlo e montare i volumi usando NFSv4, impostare la proprietà volumeAttributes da encryptInTransit a "false" nel manifesto del volume persistente. Per un manifesto di esempio, vedere Esempio di crittografia in transito su GitHub.

Helm

Questa procedura richiede Helm V3 o versione successiva. Per installare o aggiornare Helm, consultare Utilizzo di Helm con Amazon EKS.

Installazione del driver utilizzando Helm

  1. Aggiungere il repository Helm.

    helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
  2. Aggiornare il repository.

    helm repo update
  3. Installare una versione del driver utilizzando il grafico Helm. Sostituire l'indirizzo del repository con l'Indirizzo immagine container del cluster.

    helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \ --namespace kube-system \ --set image.repository=123456789012.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)

Se vuoi scaricare l'immagine con un manifesto, ti consigliamo di provare innanzitutto a eseguire questi passaggi per estrarre immagini protette dal registro privato Amazon ECR.

Installazione del driver utilizzando le immagini archiviate nel registro privato Amazon ECR

  1. Eseguire il download del manifesto.

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

    Se riscontri un problema che non riesci a risolvere aggiungendo le autorizzazioni IAM, prova invece a eseguire i passaggi "Manifest (public registry" ("Manifesto (registro pubblico)").

  2. Modificare il file e rimuovere le seguenti righe che creano un account di servizio Kubernetes. Non sono necessarie poiché l'account del servizio è stato creato in una fase precedente.

    apiVersion: v1 kind: ServiceAccount metadata: labels: app.kubernetes.io/name: aws-efs-csi-driver name: efs-csi-controller-sa namespace: kube-system ---
  3. Aggiungere la seguente riga. Sostituire il seguente indirizzo con l'indirizzo immagine container. Una volta apportata la modifica, salvare il manifesto modificato.

    image: 123456789012.dkr.ecr.region-code.amazonaws.com/eks/aws-efs-csi-driver:v1.3.2
  4. Applicare il file manifesto.

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

In alcune situazioni, potresti non essere in grado di aggiungere le autorizzazioni IAM necessarie per estrarre dal registro Amazon ECR privato. Un esempio di questo scenario è se l'utente o il ruolo IAM non è autorizzato ad autenticarsi con l'account di qualcun altro. In questo caso è possibile utilizzare il registro pubblico Amazon ECR.

Installazione del driver utilizzando le immagini archiviate nel registro pubblico Amazon ECR

  1. Eseguire il download del manifesto.

    kubectl kustomize \ "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.3" > public-ecr-driver.yaml
  2. Modificare il file e rimuovere le seguenti righe che creano un account di servizio Kubernetes. Non è necessario poiché l'account di servizio è stato creato in una fase precedente.

    apiVersion: v1 kind: ServiceAccount metadata: labels: app.kubernetes.io/name: aws-efs-csi-driver name: efs-csi-controller-sa namespace: kube-system ---
  3. Applicare il file manifesto.

    kubectl apply -f public-ecr-driver.yaml

Creare un file system Amazon EFS

Il driver CSI per Amazon EFS supporta punti di accesso Amazon EFS, ovvero punti di accesso specifici dell'applicazione in un file system Amazon EFS che semplificano la condivisione di un file system tra più pod. I punti di accesso possono applicare un'identità utente per tutte le richieste al file system effettuate tramite il punto di accesso e applicare una directory root per ogni pod. Per ulteriori informazioni, consultare Punti di accesso Amazon EFS su GitHub.

Importante

È necessario completare i seguenti passaggi nello stesso terminale perché le variabili vengono impostate e utilizzate nel corso dei vari passaggi.

Per creare un file system Amazon EFS per il cluster Amazon EKS

  1. Recuperare l'ID VPC in cui si trova il cluster e memorizzarlo in una variabile per l'utilizzo in un passaggio successivo. Sostituire my-cluster con il nome del cluster.

    vpc_id=$(aws eks describe-cluster \ --name my-cluster \ --query "cluster.resourcesVpcConfig.vpcId" \ --output text)
  2. Recuperare l'intervallo CIDR per il VPC del cluster e archiviarlo in una variabile da utilizzare in un passaggio successivo.

    cidr_range=$(aws ec2 describe-vpcs \ --vpc-ids $vpc_id \ --query "Vpcs[].CidrBlock" \ --output text)
  3. Creare un gruppo di sicurezza che consenta il traffico NFS in entrata per i punti di montaggio Amazon EFS.

    1. Creare un gruppo di sicurezza. Sostituire il example values con quello in proprio possesso.

      security_group_id=$(aws ec2 create-security-group \ --group-name MyEfsSecurityGroup \ --description "My EFS security group" \ --vpc-id $vpc_id \ --output text)
    2. Creare una regola in ingresso che consenta il traffico NFS in ingresso dal CIDR per il VPC del cluster.

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

      Per limitare ulteriormente l'accesso al file system, è possibile utilizzare il CIDR per la sottorete anziché il VPC.

  4. Creazione di un file system Amazon EFS per il cluster Amazon EKS.

    1. Creare un file system. Sostituisci region-code con la Regione AWS in cui si trova il cluster.

      file_system_id=$(aws efs create-file-system \ --region region-code \ --performance-mode generalPurpose \ --query 'FileSystemId' \ --output text)
    2. Creare delle destinazioni di montaggio.

      1. Determinare l'indirizzo IP dei nodi del cluster.

        kubectl get nodes

        Output

        NAME STATUS ROLES AGE VERSION ip-192-168-56-0.region-code.compute.internal Ready <none> 19m v1.19.6-eks-49a6c0
      2. Determinare gli ID delle sottoreti nel VPC e in quale zona di disponibilità si trova la sottorete.

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

        Output

        | 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. Aggiungere destinazioni di montaggio per le sottoreti in cui si trovano i nodi. Dall'output nei due passaggi precedenti, il cluster ha un nodo con un indirizzo IP di 192.168.56.0. Tale indirizzo IP si trova all'interno del CidrBlock della sottorete con l'ID subnet-EXAMPLEe2ba886490. Di conseguenza, il comando seguente crea una destinazione di montaggio per la sottorete in cui si trova il nodo. Se ci fossero più nodi nel cluster, sarebbe necessario eseguire il comando una volta per una sottorete in ogni AZ in cui si disponeva di un nodo, sostituendo subnet-EXAMPLEe2ba886490 con l'ID di sottorete appropriato.

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

Implementare un'applicazione di esempio

È possibile implementare un'app di esempio che crea dinamicamente un volume persistente oppure creare manualmente un volume persistente. È possibile sostituire gli esempi forniti in questa sezione con un'applicazione diversa.

Dynamic
Importante

Non è possibile utilizzare il provisioning dinamico con i nodi Fargate.

Prerequisito

È necessario utilizzare la versione 1.2x o successiva del driver CSI per Amazon EFS, che richiede un cluster aggiornato alla versione 1.17 o successiva. Per aggiornare il cluster, consultare Aggiornamento di un cluster.

Implementazione di un'applicazione di esempio che utilizza un volume persistente creato dal controller

Questa procedura utilizza l'esempio di Provisioning di volumi dinamici disponibile nel repository GitHub del driver Container Storage Interface (CSI) per Amazon EFS. Crea dinamicamente un volume persistente attraverso i punti di accesso Amazon EFS e una dichiarazione di volume persistente (PVC) che viene consumata da un pod.

  1. Creazione di una classe di archiviazione per EFS. Per tutti i parametri e le opzioni di configurazione, consultare Driver CSI per Amazon EFS su GitHub.

    1. Recuperare l'ID del file system Amazon EFS. Questa informazione è disponibile nella console Amazon EFS oppure mediante il comando AWS CLI seguente.

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

      Output:

      fs-582a03f3
    2. Eseguire il download di un manifesto StorageClass per Amazon EFS.

      curl -o storageclass.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
    3. Modifica il file. Trova la riga seguente e sostituisci il valore fileSystemId con l'ID del file system.

      fileSystemId: fs-582a03f3
    4. Implementare la classe di archiviazione.

      kubectl apply -f storageclass.yaml
  2. Testare il provisioning automatico mediante l'implementazione di un Pod che utilizza il PersistentVolumeClaim:

    1. Eseguire il download di un manifesto che implementa un pod e una Persistent Volume Claim (Richiesta di Volume Persistente).

      curl -o pod.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
    2. Implementare il pod con un'app di esempio e il PersistentVolumeClaim utilizzato dal pod.

      kubectl apply -f pod.yaml
  3. Determinare i nomi dei pod che eseguono il controller.

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

    Output

    efs-csi-controller-74ccf9f566-q5989 3/3 Running 0 40m efs-csi-controller-74ccf9f566-wswg9 3/3 Running 0 40m
  4. Dopo alcuni secondi è possibile osservare il controller che rileva la modifica (modificata per la leggibilità). Sostituire 74ccf9f566-q5989 con un valore da uno dei pod nell'output del comando precedente.

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

    Output

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

    Se l'output precedente non viene visualizzato, eseguire il comando precedente utilizzando uno degli altri pod del controller.

  5. Confermare che sia stato creato un volume persistente con lo stato Bound ad un PersistentVolumeClaim:

    kubectl get pv

    Output

    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. Visualizzare i dettagli relativi al PersistentVolumeClaim che è stato creato.

    kubectl get pvc

    Output

    NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE efs-claim Bound pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca 20Gi RWX efs-sc 9m7s
  7. Visualizza lo stato del pod dell'app di esempio fino a quando lo STATUS diventa Running.

    kubectl get pods -o wide

    Output

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

    Se un pod non ha un indirizzo IP elencato, assicurati di aver aggiunto una destinazione di montaggio per la sottorete in cui si trova il nodo (come descritto alla fine di Creare un file system Amazon EFS), altrimenti il pod continuerà ad avere lo stato ContainerCreating. Quando viene elencato un indirizzo IP, potrebbero essere necessari alcuni minuti prima che il pod passi nello stato Running.

  8. Confermare che i dati siano scritti nel volume.

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

    Output

    ... 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. (Facoltativo) Terminare il nodo Amazon EKS su cui è in esecuzione il pod e attendere che il pod venga riprogrammato. In alternativa, è possibile eliminare il pod e implementarlo di nuovo. Completa nuovamente il passaggio precedente, confermando che il nuovo output includa l'output precedente.

Static

Implementazione di un'applicazione di esempio che utilizza un volume persistente creato

Questa procedura utilizza l'esempio Multiple Pods Read Write Many disponibile nel repository GitHub del driver Container Storage Interface (CSI) per Amazon EFS, dove viene utilizzato un volume Amazon EFS persistente con provisioning statico, al quale accede da più pod con la modalità di accesso ReadWriteMany.

  1. Clonare il repository GitHub del driver Container Storage Interface (CSI) per Amazon EFS nel sistema locale.

    git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git
  2. Passare alla directory di esempio multiple_pods.

    cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/
  3. Recuperare l'ID del file system Amazon EFS. Questa informazione è disponibile nella console Amazon EFS oppure mediante il comando AWS CLI seguente.

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

    Output:

    fs-582a03f3
  4. Modificare il file specs/pv.yaml e sostituire il valore volumeHandle con l'ID del file system Amazon EFS.

    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
    Nota

    Poiché Amazon EFS è un file system elastico, non viene applicato alcun limite di capacità. Il valore effettivo della capacità di archiviazione nei volumi persistenti e nelle dichiarazioni di volume persistente non viene utilizzato durante la creazione del file system. Tuttavia, poiché la capacità di archiviazione è un campo obbligatorio in Kubernetes, è necessario specificare un valore valido come 5Gi riportato nell'esempio. Questo valore non limita le dimensioni del file system Amazon EFS.

  5. Implementare la classe di archiviazione efs-sc, la dichiarazione di volume persistente efs-claim e il volume persistente efs-pv dalla directory specs.

    kubectl apply -f specs/pv.yaml kubectl apply -f specs/claim.yaml kubectl apply -f specs/storageclass.yaml
  6. Elencare i volumi persistenti nello spazio dei nomi predefinito. Cercare un volume persistente con la richiesta default/efs-claim.

    kubectl get pv -w

    Output:

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

    Non andare al passaggio successivo finché lo STATUS non è Bound.

  7. Implementare le applicazioni di esempio app1 e app2 dalla directory specs.

    kubectl apply -f specs/pod1.yaml kubectl apply -f specs/pod2.yaml
  8. Monitorare i pod nello spazio dei nomi di default e attendere che i app1 e app2 i STATUS dei pod diventino Running.

    kubectl get pods --watch
    Nota

    Potrebbero essere necessari alcuni minuti prima che i pod raggiungano lo stato Running.

  9. Descrivere il volume persistente.

    kubectl describe pv efs-pv

    Output:

    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

    L'ID del file system Amazon EFS viene riportato come VolumeHandle.

  10. Verificare che il pod app1 scriva correttamente i dati nel volume.

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

    Output:

    ... 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. Verificare che il pod app2 mostri gli stessi dati nel volume scritti da app1 nel volume.

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

    Output:

    ... 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. Al termine, eliminare le risorse per questa applicazione di esempio in modo da liberare spazio.

    kubectl delete -f specs/

    È inoltre possibile eliminare manualmente il file system e il gruppo di sicurezza creato.