**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo dell’archiviazione di dati delle applicazioni per il tuo cluster
Puoi utilizzare una gamma di servizi di AWS storage con Amazon EKS per le esigenze di storage delle tue applicazioni. Grazie a un' AWS ampia gamma di driver CSI (Container Storage Interface) supportati, puoi utilizzare facilmente Amazon EBS, Amazon S3, Amazon EFS, Amazon FSX e Amazon File Cache per le esigenze di storage delle tue applicazioni in esecuzione su Amazon EKS. Per gestire i backup del tuo cluster Amazon EKS, consulta [Supporto di AWS backup per Amazon EKS](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-supported-services.html#working-with-eks).
Questo capitolo illustra le opzioni di archiviazione per i cluster Amazon EKS.
**Topics**
+ [Utilizzare il volume di archiviazione Kubernetes con Amazon EBS](ebs-csi.md)
+ [Utilizzo dell’archiviazione di file system elastici con Amazon EFS](efs-csi.md)
+ [Usa l’archiviazione delle app ad alte prestazioni con Amazon FSx per Lustre](fsx-csi.md)
+ [Usa l’archiviazione delle app ad alte prestazioni con FSx per NetApp ONTAP](fsx-ontap.md)
+ [Usa l’archiviazione di dati con Amazon FSx per OpenZFS](fsx-openzfs-csi.md)
+ [Riduci al minimo la latenza con Amazon File Cache](file-cache-csi.md)
+ [Accedere agli oggetti Amazon S3 con il driver CSI Mountpoint per Amazon S3](s3-csi.md)
+ [Abilitare la funzionalità snapshot per i volumi CSI](csi-snapshot-controller.md)
# Utilizzare il volume di archiviazione Kubernetes con Amazon EBS
**Nota**
**Novità:** la modalità automatica di Amazon EKS automatizza le attività di routine per l’archiviazione a blocchi. Informazioni su come [Implementazione di un carico di lavoro stateful esemplificativo in modalità automatica EKS](sample-storage-workload.md).
Il [driver Container Storage Interface (CSI) di Amazon Elastic Block Store (Amazon EBS)](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/) gestisce il ciclo di vita dei volumi Amazon EBS come archiviazione per i volumi Kubernetes creati. Il driver CSI di Amazon EBS crea volumi Amazon EBS per questi tipi di volumi Kubernetes: [volumi generici effimeri](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) e [volumi persistenti](https://kubernetes.io/docs/concepts/storage/persistent-volumes/).
## Considerazioni
+ Non è necessario installare il controller CSI di Amazon EBS sui cluster della modalità automatica EKS.
+ Non è possibile montare volumi Amazon EBS sui pod Fargate.
+ Puoi eseguire il controller Amazon EBS CSI sui nodi Fargate, ma sul nodo Amazon EBS CSI `DaemonSet` può essere eseguito solo su istanze Amazon EC2.
+ I volumi Amazon EBS e il driver CSI di Amazon EBS non sono compatibili con Amazon EKS Hybrid Nodes.
+ Verrà fornito supporto per la versione più recente del componente aggiuntivo e per una versione precedente. Le correzioni per bug o vulnerabilità rilevate nell'ultima versione verranno riportate alla versione precedente come nuova versione secondaria.
+ La modalità automatica EKS richiede classi di archiviazione per utilizzare `ebs.csi.eks.amazonaws.com` come provisioner. Il driver CSI di Amazon EBS standard (`ebs.csi.aws.com`) gestisce i propri volumi separatamente. Per utilizzare i volumi esistenti con la modalità automatica EKS, eseguirne la migrazione tramite snapshot del volume verso una classe di archiviazione che utilizza il provisioner della modalità automatica.
**Importante**
Per utilizzare la funzionalità snapshot del driver CSI di Amazon EBS, è prima necessario installare il controller di snapshot CSI. Per ulteriori informazioni, consulta [Abilitare la funzionalità snapshot per i volumi CSI](csi-snapshot-controller.md).
## Prerequisiti
+ Un cluster esistente. Per visualizzare la versione della piattaforma richiesta, esegui il comando seguente.
```
aws eks describe-addon-versions --addon-name aws-ebs-csi-driver
```
+ Il driver CSI EBS richiede le autorizzazioni IAM. AWS
+ AWS suggerisce di utilizzare EKS Pod Identities. Per ulteriori informazioni, consulta [Panoramica sulla configurazione delle associazioni EKS Pod Identity](pod-identities.md#pod-id-setup-overview).
+ Per ulteriori informazioni sui ruoli IAM per gli account di servizio, consultare [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
## Passaggio 1: Creazione di un ruolo IAM
Il plug-in Amazon EBS CSI richiede le autorizzazioni IAM per effettuare chiamate per tuo AWS APIs conto. Se non viene soddisfatto questo prerequisito, il tentativo di installare il componente aggiuntivo e l’esecuzione di `kubectl describe pvc` riporteranno `failed to provision volume with StorageClass` insieme a un errore `could not create volume in EC2: UnauthorizedOperation`. Per ulteriori informazioni, consulta [Configurazione dell'autorizzazione driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#set-up-driver-permissions) su GitHub.
**Nota**
I pod avranno accesso alle autorizzazioni assegnate al ruolo IAM, a meno che non si blocchi l’accesso a IMDS. Per ulteriori informazioni, consulta [Protezione dei cluster Amazon EKS con le best practice](security-best-practices.md).
La procedura seguente mostra come creare un ruolo IAM e allegare ad esso la policy AWS gestita. Per implementare questa procedura, è possibile utilizzare uno dei seguenti strumenti:
+ [`eksctl`](#eksctl_store_app_data)
+ [Console di gestione AWS](#console_store_app_data)
+ [AWS CLI](#awscli_store_app_data)
**Nota**
È possibile creare una policy autogestita con autorizzazioni limitate. Rivedere [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html) e creare una policy IAM personalizzata con autorizzazioni ridotte.
**Nota**
I passaggi specifici di questa procedura sono stati scritti per l'utilizzo del driver come componente aggiuntivo di Amazon EKS. Per utilizzare il driver come componente aggiuntivo autogestito occorre una procedura differente. Per ulteriori informazioni, consulta [Configurare le autorizzazioni dei driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#set-up-driver-permissions) su GitHub.
### `eksctl`
1. Crea un ruolo IAM e allega una policy. AWS mantiene una politica AWS gestita oppure puoi creare la tua politica personalizzata. È possibile creare un ruolo IAM e allegare la policy AWS gestita con il seguente comando. Sostituisci *my-cluster* con il nome del cluster. Il comando distribuisce uno AWS CloudFormation stack che crea un ruolo IAM e vi allega la policy IAM.
```
eksctl create iamserviceaccount \
--name ebs-csi-controller-sa \
--namespace kube-system \
--cluster my-cluster \
--role-name AmazonEKS_EBS_CSI_DriverRole \
--role-only \
--attach-policy-arn arn:aws: iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--approve
```
1. È possibile saltare questo passaggio se non si utilizza una [chiave KMS](https://aws.amazon.com/kms/) personalizzata. Nel caso se ne utilizzi una per la crittografia dei volumi Amazon EBS, personalizzare il ruolo IAM secondo necessità. Ad esempio, completa le seguenti operazioni:
1. Copia e incolla il codice seguente in un nuovo file `kms-key-for-encryption-on-ebs.json`. Sostituisci *custom-key-arn* con l'[ARN della chiave KMS personalizzata](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"]
}
]
}
```
1. Crea la policy. È possibile modificare *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* con un nome diverso. Se esegui questa operazione, tuttavia, assicurati di modificare il nome anche nelle fasi successive.
```
aws iam create-policy \
--policy-name KMS_Key_For_Encryption_On_EBS_Policy \
--policy-document file://kms-key-for-encryption-on-ebs.json
```
1. Collega la policy IAM al ruolo con il comando seguente. Sostituisci *111122223333* con l'ID del tuo account.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/KMS_Key_For_Encryption_On_EBS_Policy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
### Console di gestione AWS
1. Apri la console IAM all'indirizzo. https://console.aws.amazon.com/iam/
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, seleziona **Crea ruolo**.
1. Nella pagina **Select trusted entity** (Seleziona entità attendibile), esegui le operazioni seguenti:
1. Nella sezione **Tipo di identità attendibile**, scegli **Identità Web**.
1. Per **Identity provider** (Provider di identità), scegli **URL del provider OpenID Connect** per il cluster (come mostrato nella scheda **Overview** (Panoramica) in Amazon EKS).
1. Per **Pubblico**, scegli `sts.amazonaws.com`.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Add permissions** (Aggiungi autorizzazioni), esegui le operazioni seguenti:
1. Nella casella **Filtra policy**, inserisci `AmazonEBSCSIDriverPolicy`.
1. Seleziona la casella di controllo a sinistra della `AmazonEBSCSIDriverPolicy` restituita dalla ricerca.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Name, review, and create** (Assegna un nome, rivedi e crea), esegui le operazioni seguenti:
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio *AmazonEKS\$1EBS\$1CSI\$1DriverRole*.
1. In **Aggiungi tag (facoltativo)**, aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull’utilizzo di tag in IAM, consulta la sezione [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l’utente di IAM*.
1. Scegli **Crea ruolo**.
1. Dopo aver creato il ruolo, sceglilo nella console in modo da aprirlo per la modifica.
1. Scegli la scheda **Relazioni di attendibilità** e quindi **Modifica policy di attendibilità**.
1. Trova la riga simile alla seguente:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
```
Inserisci una virgola alla fine della riga precedente, quindi aggiungine una seguente dopo quella precedente. Sostituisci *region-code* con la AWS regione in cui si trova il cluster. Sostituire *EXAMPLED539D4633E53DE1B71EXAMPLE* con l’ID del gestore OIDC del cluster.
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
```
1. Scegli **Aggiorna policy** per concludere.
1. Se utilizzi una [chiave KMS](https://aws.amazon.com/kms/) personalizzata per la crittografia dei volumi Amazon EBS, personalizza il ruolo IAM secondo necessità. Ad esempio, completa le seguenti operazioni:
1. Nel pannello di navigazione a sinistra, seleziona **Policy**.
1. Nella pagina **Policy**, scegli **Crea policy**.
1. Nella pagina **Crea policy**, scegli la scheda **JSON**.
1. Copia e incolla il codice seguente nell'editor, sostituendo *custom-key-arn* con l'[ARN della chiave KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personalizzata.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"]
}
]
}
```
1. Scegli **Successivo: Tag**.
1. Nella pagina **Add tags (optional)** (Aggiungi tag, facoltativo), seleziona **Next: Review** (Successivo: esamina).
1. Per **Nome** immettere un nome univoco per la policy (ad esempio *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy*).
1. Scegli **Crea policy**.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Sceglila ***AmazonEKS\$1EBS\$1CSI\$1DriverRole***nella console per aprirla e modificarla.
1. Dall'elenco a discesa **Aggiungi autorizzazioni**, scegli **Collega policy**.
1. Nella casella **Filtra policy**, inserisci *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy*.
1. Seleziona la casella di controllo a sinistra della *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* restituita dalla ricerca.
1. Scegli **Collega policy**.
### AWS CLI
1. Visualizzare l’URL del gestore OIDC del cluster. Sostituire *my-cluster* con il nome del cluster. Se l'output dal comando è `None`, rivedi i **Prerequisiti**.
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
Di seguito viene riportato un output di esempio:
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
1. Crea il ruolo IAM concedendo l'autorizzazione per l'operazione `AssumeRoleWithWebIdentity`.
1. Copiare i contenuti seguenti in un file denominato `aws-ebs-csi-driver-trust-policy.json`. Sostituisci *111122223333* con l'ID del tuo account. Sostituire *EXAMPLED539D4633E53DE1B71EXAMPLE* 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.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
}
}
}
]
}
```
1. Creare il ruolo. È possibile modificare *AmazonEKS\$1EBS\$1CSI\$1DriverRole* con un nome diverso. Se modifichi il valore, assicurati di modificarlo anche nelle fasi successive.
```
aws iam create-role \
--role-name AmazonEKS_EBS_CSI_DriverRole \
--assume-role-policy-document file://"aws-ebs-csi-driver-trust-policy.json"
```
1. Allega una politica. AWS mantiene una politica AWS gestita oppure è possibile creare una politica personalizzata. AWS Associa la politica gestita al ruolo con il seguente comando.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
1. Se utilizzi una [chiave KMS](https://aws.amazon.com/kms/) personalizzata per la crittografia dei volumi Amazon EBS, personalizza il ruolo IAM secondo necessità. Ad esempio, completa le seguenti operazioni:
1. Copia e incolla il codice seguente in un nuovo file `kms-key-for-encryption-on-ebs.json`. Sostituisci *custom-key-arn* con l'[ARN della chiave KMS personalizzata](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"],
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": ["arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab"]
}
]
}
```
1. Crea la policy. È possibile modificare *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* con un nome diverso. Se esegui questa operazione, tuttavia, assicurati di modificare il nome anche nelle fasi successive.
```
aws iam create-policy \
--policy-name KMS_Key_For_Encryption_On_EBS_Policy \
--policy-document file://kms-key-for-encryption-on-ebs.json
```
1. Collega la policy IAM al ruolo con il comando seguente. Sostituisci *111122223333* con l'ID del tuo account.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::111122223333:policy/KMS_Key_For_Encryption_On_EBS_Policy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
Ora che è stato creato il ruolo IAM del driver CSI di Amazon EBS, è possibile passare alla sezione successiva. Quando si implementa il componente aggiuntivo con il ruolo IAM, questo crea e viene configurato per utilizzare un account di servizio denominato `ebs-csi-controller-sa`. L’account di servizio è associato a un `clusterrole` Kubernetes a cui sono assegnate le autorizzazioni Kubernetes richieste.
## Fase 2: ottenere il driver CSI di Amazon EBS
Consigliamo di installare il driver CSI di Amazon EBS attraverso il componente aggiuntivo di Amazon EKS per migliorare la sicurezza e ridurre le attività. Per aggiungere un componente aggiuntivo di Amazon EKS al cluster, consulta [Creare un componente aggiuntivo Amazon EKS](creating-an-add-on.md). Per ulteriori informazioni sui componenti aggiuntivi, consulta [Componenti aggiuntivi Amazon EKS](eks-add-ons.md).
**Importante**
Prima di aggiungere il driver Amazon EBS come componente aggiuntivo di Amazon EKS, verificare che nel cluster non sia installata una versione autogestita del driver. In tal caso, vedi[Disinstallazione di un driver Amazon EBS CSI autogestito](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#uninstalling-the-ebs-csi-driver)sul GitHub.
**Nota**
Per impostazione predefinita, il ruolo RBAC utilizzato dal CSI di EBS dispone delle autorizzazioni per modificare i nodi per supportare la funzionalità di rimozione delle macchie. A causa delle limitazioni di Kubernetes RBAC, ciò consente anche di modificare qualsiasi altro nodo del cluster. Il grafico Helm ha un parametro (`node.serviceAccount.disableMutation`) che disabilita la modifica delle autorizzazioni RBAC del nodo per l'account del servizio. ebs-csi-node Se abilitate, le funzioni del driver come la rimozione delle macchie non funzioneranno.
[In alternativa, se desideri un'installazione autogestita del driver CSI di Amazon EBS, consulta Installazione su.](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) GitHub
## Fase 3: implementazione di un’applicazione di esempio
Puoi implementare diverse app di esempio e modificarle in base alle tue esigenze. Per ulteriori informazioni, consulta [Kubernetes](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes) Examples su. GitHub
# Utilizzo dell’archiviazione di file system elastici con Amazon EFS
[Amazon Elastic File System](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) (Amazon EFS) fornisce un'archiviazione di file serverless e completamente elastica in modo da poter condividere i dati dei file senza dover fornire o gestire la capacità e le prestazioni di archiviazione. Il [driver Amazon EFS Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-efs-csi-driver) fornisce un'interfaccia CSI che consente ai cluster Kubernetes in esecuzione di AWS gestire il ciclo di vita dei file system Amazon EFS. Questo argomento illustra come implementare il driver CSI per Amazon EBS nel cluster Amazon EKS.
## Considerazioni
+ Il driver CSI per Amazon EFS non è compatibile con le immagini di container basate su Windows.
+ Non è possibile utilizzare il [provisioning dinamico](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) dei volumi persistenti con nodi Fargate, ma è possibile utilizzare il [provisioning statico](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md).
+ Il [provisioning dinamico](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) richiede un driver versione [1.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v12) o successiva. È possibile eseguire il [provisioning statico](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md) di volumi persistenti utilizzando la versione `1.1` del driver su qualsiasi versione del cluster Amazon EKS supportata (consultare la pagina [Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)).
+ La versione [1.3.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v132) o successiva di questo driver supporta l'architettura Arm64, incluse le istanze basate su Amazon EC2 Graviton.
+ La versione [1.4.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v142) o successiva di questo driver supporta l’uso di FIPS per il montaggio di file system.
+ Osserva le quote delle risorse per Amazon EFS. Ad esempio, è possibile creare una quota di 1.000 punti di accesso per ogni file system Amazon EFS. Per ulteriori informazioni, consulta le [Quote di risorse di Amazon EFS che non puoi modificare](https://docs.aws.amazon.com/efs/latest/ug/limits.html#limits-efs-resources-per-account-per-region).
+ A partire dalla versione [2.0.0](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-2.x.md#v200), questo driver è passato dall’utilizzo di `stunnel` a `efs-proxy` per le connessioni TLS. Quando viene utilizzato `efs-proxy`, aprirà un numero di thread pari a uno più il numero di core del nodo su cui è in esecuzione.
+ Il driver CSI per Amazon EFS non è compatibile con Amazon EKS Hybrid Nodes.
## Prerequisiti
+ Il driver CSI Amazon EFS necessita delle autorizzazioni AWS Identity and Access Management (IAM).
+ AWS suggerisce di utilizzare EKS Pod Identities. Per ulteriori informazioni, consulta [Panoramica sulla configurazione delle associazioni EKS Pod Identity](pod-identities.md#pod-id-setup-overview).
+ Per informazioni sui ruoli IAM per gli account di servizio e su come configurare un gestore OpenID Connect (OIDC) IAM per il cluster, consultare [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
**Nota**
Un pod in esecuzione su Fargate monta automaticamente un file system Amazon EFS senza bisogno della procedura di installazione manuale del driver.
## Passaggio 1: Creazione di un ruolo IAM
Il driver CSI per Amazon EFS richiede le autorizzazioni IAM per interagire con il file system. Crea un ruolo IAM e allega ad esso la policy AWS gestita richiesta. Per implementare questa procedura, è possibile utilizzare uno dei seguenti strumenti:
+ [`eksctl`](#eksctl_efs_store_app_data)
+ [Console di gestione AWS](#console_efs_store_app_data)
+ [AWS CLI](#awscli_efs_store_app_data)
**Nota**
I passaggi specifici di questa procedura sono stati scritti per l'utilizzo del driver come componente aggiuntivo di Amazon EKS. Per informazioni dettagliate sulle installazioni autogestite, consulta [Set up driver permission](https://github.com/kubernetes-sigs/aws-efs-csi-driver#set-up-driver-permission) su GitHub.
### `eksctl`
#### Se si utilizza Pod Identity
Eseguire i seguenti comandi per creare un ruolo IAM e un’associazione Pod Identity con `eksctl`. Sostituisci `my-cluster` con il nome del cluster. È anche possibile sostituire `AmazonEKS_EFS_CSI_DriverRole` con un nome diverso.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
eksctl create podidentityassociation \
--service-account-name efs-csi-controller-sa \
--namespace kube-system \
--cluster $cluster_name \
--role-name $role_name \
--permission-policy-arns arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy
```
#### Se si utilizzano ruoli IAM per gli account di servizio
Eseguire i seguenti comandi per creare un ruolo IAM con `eksctl`. Sostituisci `my-cluster` con il nome del cluster. È anche possibile sostituire `AmazonEKS_EFS_CSI_DriverRole` con un nome diverso.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
eksctl create iamserviceaccount \
--name efs-csi-controller-sa \
--namespace kube-system \
--cluster $cluster_name \
--role-name $role_name \
--role-only \
--attach-policy-arn arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--approve
TRUST_POLICY=$(aws iam get-role --output json --role-name $role_name --query 'Role.AssumeRolePolicyDocument' | \
sed -e 's/efs-csi-controller-sa/efs-csi-*/' -e 's/StringEquals/StringLike/')
aws iam update-assume-role-policy --role-name $role_name --policy-document "$TRUST_POLICY"
```
### Console di gestione AWS
Esegui quanto segue per creare un ruolo IAM con Console di gestione AWS.
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, seleziona **Crea ruolo**.
1. Nella pagina **Seleziona un’entità attendibile**, esegui le operazioni seguenti:
1. Se si utilizza EKS Pod Identity:
1. Nella sezione **Tipo di entità affidabile**, scegli ** AWS servizio**.
1. Nel menu a discesa **Servizio o caso d’uso**, scegliere **EKS**.
1. Nella sezione **Caso d’uso**, scegliere **EKS - Pod Identity**.
1. Scegli **Next (Successivo)**.
1. Se si utilizzano ruoli IAM per gli account di servizio:
1. Nella sezione **Tipo di identità attendibile**, scegli **Identità Web**.
1. Per **Identity provider** (Provider di identità), scegli **URL del provider OpenID Connect** per il cluster (come mostrato nella scheda **Overview** (Panoramica) in Amazon EKS).
1. Per **Pubblico**, scegli `sts.amazonaws.com`.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Add permissions** (Aggiungi autorizzazioni), esegui le operazioni seguenti:
1. Nella casella **Filtra policy**, inserisci `AmazonEFSCSIDriverPolicy`.
1. Seleziona la casella di controllo a sinistra della `AmazonEFSCSIDriverPolicy` restituita dalla ricerca.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Name, review, and create** (Assegna un nome, rivedi e crea), esegui le operazioni seguenti:
1. Per **Nome ruolo**, inserisci un nome univoco per il ruolo, ad esempio `AmazonEKS_EFS_CSI_DriverRole`.
1. In **Aggiungi tag (facoltativo)**, aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull’utilizzo di tag in IAM, consulta la sezione [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l’utente di IAM*.
1. Scegli **Crea ruolo**.
1. Dopo aver creato il ruolo:
1. Se si utilizza EKS Pod Identity:
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel riquadro di navigazione a sinistra, selezionare **Cluster**, quindi selezionare il nome del cluster per cui configurare l’associazione EKS Pod Identity.
1. Scegliere la scheda **Accesso**.
1. In **Associazioni Pod Identity**, scegliere **Crea**.
1. Scegliere il menu a discesa **Ruolo IAM** e selezionare il ruolo appena creato.
1. Scegliere il campo **Namespace Kubernetes** e inserire `kube-system`.
1. Scegliere il campo **Account del servizio Kubernetes** e inserire `efs-csi-controller-sa`.
1. Scegli **Create** (Crea).
1. Per ulteriori informazioni sulla creazione di associazioni Pod Identity, consultare [Crea un'associazione Pod Identity (AWS Console)](pod-id-association.md#pod-id-association-create).
1. Se si utilizzano ruoli IAM per gli account di servizio:
1. Scegliere il ruolo per aprirlo per la modifica.
1. Scegli la scheda **Relazioni di attendibilità** e quindi **Modifica policy di attendibilità**.
1. Trova la riga simile alla seguente:
```
"oidc.eks.region-code.amazonaws.com/id/:aud": "sts.amazonaws.com"
```
Aggiungi la riga seguente sopra la riga precedente. Sostituiscilo `` con la AWS regione in cui si trova il cluster. Sostituire `` con l’ID del gestore OIDC del cluster.
```
"oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount:kube-system:efs-csi-*",
```
1. Modifica l'operatore `Condition` da `"StringEquals"` a `"StringLike"`.
1. Scegli **Aggiorna policy** per concludere.
### AWS CLI
Esegui i seguenti comandi per creare un ruolo IAM con AWS CLI.
#### Se si utilizza Pod Identity
1. Creare il ruolo IAM che concede le operazioni `AssumeRole` e `TagSession` al servizio `pods.eks.amazonaws.com`.
1. Copiare i seguenti contenuti in un file denominato `aws-efs-csi-driver-trust-policy-pod-identity.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Crea il ruolo. Sostituisci `my-cluster` con il nome del cluster. È anche possibile sostituire `AmazonEKS_EFS_CSI_DriverRole` con un nome diverso.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
aws iam create-role \
--role-name $role_name \
--assume-role-policy-document file://"aws-efs-csi-driver-trust-policy-pod-identity.json"
```
1. Allega la policy AWS gestita richiesta al ruolo con il comando seguente.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--role-name $role_name
```
1. Eseguire il seguente comando per creare l’associazione Pod Identity. Sostituire ` arn:aws: iam::<111122223333>:role/my-role` con il ruolo creato nei passaggi precedenti.
```
aws eks create-pod-identity-association --cluster-name $cluster_name --role-arn {arn-aws}iam::<111122223333>:role/my-role --namespace kube-system --service-account efs-csi-controller-sa
```
1. Per ulteriori informazioni sulla creazione di associazioni Pod Identity, consultare [Crea un'associazione Pod Identity (AWS Console)](pod-id-association.md#pod-id-association-create).
#### Se si utilizzano ruoli IAM per gli account di servizio
1. Visualizzare l’URL del gestore OIDC del cluster. Sostituisci `my-cluster` con il nome del cluster. È anche possibile sostituire `AmazonEKS_EFS_CSI_DriverRole` con un nome diverso.
```
export cluster_name=my-cluster
export role_name=AmazonEKS_EFS_CSI_DriverRole
aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text
```
Di seguito viene riportato un output di esempio.
```
https://oidc.eks..amazonaws.com/id/
```
Se l'output dal comando è `None`, rivedi i **Prerequisiti**.
1. Crea il ruolo IAM che concede l'autorizzazione per l'operazione `AssumeRoleWithWebIdentity`.
1. Copia i seguenti contenuti in un file denominato `aws-efs-csi-driver-trust-policy.json`. Sostituisci `<111122223333>` con l'ID del tuo account. Sostituire `` e `` con i valori restituiti nella fase precedente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:efs-csi-*",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Creare il ruolo.
```
aws iam create-role \
--role-name $role_name \
--assume-role-policy-document file://"aws-efs-csi-driver-trust-policy.json"
```
1. Allega la politica AWS gestita richiesta al ruolo con il comando seguente.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--role-name $role_name
```
## Fase 2: ottenere il driver CSI per Amazon EFS
Consigliamo di installare il driver Amazon EFS CSI attraverso il componente aggiuntivo di Amazon EKS. Per aggiungere un componente aggiuntivo di Amazon EKS al cluster, consulta [Creare un componente aggiuntivo Amazon EKS](creating-an-add-on.md). Per ulteriori informazioni sui componenti aggiuntivi, consulta [Componenti aggiuntivi Amazon EKS](eks-add-ons.md). Se non riesci a utilizzare il componente aggiuntivo Amazon EKS, ti consigliamo di segnalare un problema sul motivo per cui non puoi farlo all'archivio della [roadmap GitHub di Containers](https://github.com/aws/containers-roadmap/issues).
**Importante**
Prima di aggiungere il driver Amazon EFS come componente aggiuntivo di Amazon EKS, verificare che nel cluster non sia installata una versione autogestita del driver. In tal caso, consulta [Disinstallazione del driver Amazon EFS CSI](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#uninstalling-the-amazon-efs-csi-driver) su. GitHub
In alternativa, se desideri un'installazione autogestita del driver Amazon EFS CSI, consulta [Installazione](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#installation)su GitHub.
## Fase 3: Creazione di un file system Amazon EFS
Per creare un file system Amazon EFS, consulta [Creazione di un sistema di file Amazon EFS per Amazon EKS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/efs-create-filesystem.md) su GitHub.
## Fase 4: implementazione di un’applicazione di esempio
Puoi implementare diverse app di esempio e modificarle in base alle tue esigenze. Per ulteriori informazioni, consulta [Esempi](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#examples) su. GitHub
# Usa l’archiviazione delle app ad alte prestazioni con Amazon FSx per Lustre
Il [driver Container Storage Interface (CSI) per Amazon FSx per Lustre](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) mette a disposizione un’interfaccia CSI che permette ai cluster Amazon EKS di gestire il ciclo di vita dei file system Amazon FSx per Lustre. Per ulteriori informazioni, consulta [Amazon FSx for Lustre User Guide](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html).
Per informazioni su come implementare il driver CSI per Amazon FSx per Lustre nel cluster Amazon EKS e come verificarne il funzionamento, consulta [Implementa il driver FSx for Lustre](fsx-csi-create.md).
# Implementa il driver FSx for Lustre
Questo argomento mostra come distribuire il [driver CSI FSx for Lustre](fsx-csi.md) nel cluster Amazon EKS e verificarne il funzionamento. Ti consigliamo di utilizzare sempre la versione più recente del driver. Per le versioni disponibili, consulta la matrice di compatibilità delle [specifiche CSI su](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/README.md#csi-specification-compatibility-matrix). GitHub
**Nota**
Il driver non è supportato su Fargate o Amazon EKS Hybrid Nodes.
Per descrizioni dettagliate dei parametri disponibili ed esempi completi che dimostrano le caratteristiche del driver, consultate il progetto [driver FSx for Lustre Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) su. GitHub
## Prerequisiti
+ Un cluster esistente.
+ Il componente aggiuntivo Amazon FSx CSI Driver EKS richiede l'agente EKS Pod Identity per l'autenticazione. Senza questo componente, il componente aggiuntivo fallirà con l’errore `Amazon EKS Pod Identity agent is not installed in the cluster`, impedendo le operazioni di volume. Installa l'agente Pod Identity prima o dopo la distribuzione del componente aggiuntivo FSx CSI Driver. Per ulteriori informazioni, consulta [Configurazione dell’agente Amazon EKS Pod Identity](pod-id-agent-setup.md).
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ La versione `0.215.0` o quelle successive dello strumento a riga di comando `eksctl` deve essere installata sul dispositivo o nella AWS CloudShell. Per l’installazione o l’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
## Passaggio 1: Creazione di un ruolo IAM
Il plug-in Amazon FSx CSI richiede le autorizzazioni IAM per effettuare chiamate per tuo AWS APIs conto.
**Nota**
I pod avranno accesso alle autorizzazioni assegnate al ruolo IAM, a meno che non si blocchi l’accesso a IMDS. Per ulteriori informazioni, consulta [Protezione dei cluster Amazon EKS con le best practice](security-best-practices.md).
La procedura seguente mostra come creare un ruolo IAM e allegare ad esso la policy AWS gestita.
1. Crea un ruolo IAM e collega la policy AWS gestita con il seguente comando. Sostituisci `my-cluster` con il nome del cluster che desideri utilizzare. Il comando distribuisce uno AWS CloudFormation stack che crea un ruolo IAM e vi allega la policy IAM.
```
eksctl create iamserviceaccount \
--name fsx-csi-controller-sa \
--namespace kube-system \
--cluster my-cluster \
--role-name AmazonEKS_FSx_CSI_DriverRole \
--role-only \
--attach-policy-arn arn:aws: iam::aws:policy/AmazonFSxFullAccess \
--approve
```
Visualizzerai diverse righe di output quando l’account del servizio viene creato. Le ultime righe dell’output sono simili a quelle riportate di seguito.
```
[ℹ] 1 task: {
2 sequential sub-tasks: {
create IAM role for serviceaccount "kube-system/fsx-csi-controller-sa",
create serviceaccount "kube-system/fsx-csi-controller-sa",
} }
[ℹ] building iamserviceaccount stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ] deploying stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa"
[ℹ] created serviceaccount "kube-system/fsx-csi-controller-sa"
```
Annota il nome dello AWS CloudFormation stack che è stato distribuito. Nell’output di esempio precedente, lo stack è denominato `eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa`.
Ora che hai creato il ruolo IAM del driver Amazon FSx CSI, puoi passare alla sezione successiva. Quando si implementa il componente aggiuntivo con il ruolo IAM, questo crea e viene configurato per utilizzare un account di servizio denominato `fsx-csi-controller-sa`. L’account di servizio è associato a un `clusterrole` Kubernetes a cui sono assegnate le autorizzazioni Kubernetes richieste.
## Fase 2: Installare il driver Amazon FSx CSI
Ti consigliamo di installare il driver Amazon FSx CSI tramite il componente aggiuntivo Amazon EKS per migliorare la sicurezza e ridurre la quantità di lavoro. Per aggiungere un componente aggiuntivo di Amazon EKS al cluster, consulta [Creare un componente aggiuntivo Amazon EKS](creating-an-add-on.md). Per ulteriori informazioni sui componenti aggiuntivi, consulta [Componenti aggiuntivi Amazon EKS](eks-add-ons.md).
**Importante**
Le installazioni preesistenti di driver Amazon FSx CSI nel cluster possono causare errori di installazione dei componenti aggiuntivi. Quando tenti di installare la versione del componente aggiuntivo Amazon EKS mentre esiste un driver FSx CSI non EKS, l'installazione avrà esito negativo a causa di conflitti di risorse. Usa il flag `OVERWRITE` durante l’installazione per risolvere il problema.
```
aws eks create-addon --addon-name aws-fsx-csi-driver --cluster-name my-cluster --resolve-conflicts OVERWRITE
```
In alternativa, se desideri un'installazione autogestita del driver Amazon FSx CSI, consulta [Installation](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/install.md) on. GitHub
## Passaggio 3: implementazione di una classe di archiviazione, una dichiarazione di volume persistente e un’app di esempio
Questa procedura utilizza il GitHub repository di [driver FSx for Lustre Container Storage Interface (CSI)](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) per utilizzare un volume Lustre con provisioning dinamico. FSx
1. Annota il gruppo di sicurezza per il cluster. Puoi vederlo nella Console di gestione AWS sezione **Rete** o utilizzando il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster che desideri utilizzare.
```
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
1. Crea un gruppo di sicurezza per il tuo FSx file system Amazon in base ai criteri indicati in [Amazon VPC Security Groups](https://docs.aws.amazon.com/fsx/latest/LustreGuide/limit-access-security-groups.html#fsx-vpc-security-groups) nella Amazon FSx for Lustre User Guide. Per il **VPC**, seleziona il VPC del cluster come mostrato nella sezione **Reti**. Per i "gruppi di sicurezza associati ai client Lustre", usa il gruppo di sicurezza del cluster. Non specificare alcun valore nelle regole in uscita per consentire **Tutto il traffico**.
1. Scarica il manifesto della classe di storage con il comando seguente.
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
```
1. Modifica la sezione dei parametri del file `storageclass.yaml`. Sostituisci ogni valore esemplificativo con i tuoi valori.
```
parameters:
subnetId: subnet-0eabfaa81fb22bcaf
securityGroupIds: sg-068000ccf82dfba88
deploymentType: PERSISTENT_1
automaticBackupRetentionDays: "1"
dailyAutomaticBackupStartTime: "00:00"
copyTagsToBackups: "true"
perUnitStorageThroughput: "200"
dataCompressionType: "NONE"
weeklyMaintenanceStartTime: "7:09:00"
fileSystemTypeVersion: "2.12"
```
+ **`subnetId`**— L'ID di sottorete in cui deve essere creato il file system Amazon FSx for Lustre. Amazon FSx for Lustre non è supportato in tutte le zone di disponibilità. Apri la console Amazon FSx for Lustre all'indirizzo per https://console.aws.amazon.com/fsx/ confermare che la sottorete che desideri utilizzare si trova in una zona di disponibilità supportata. La sottorete può includere i nodi oppure può essere una sottorete o un VPC differente:
+ **Puoi verificare la presenza di sottoreti di nodi in Console di gestione AWS selezionando il gruppo di nodi nella sezione Elaborazione.**
+ Se la sottorete specificata non è la stessa sottorete in cui sono presenti i nodi, è VPCs necessario essere [connessi](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html) e assicurarsi di avere le porte necessarie aperte nei gruppi di sicurezza.
+ ** `securityGroupIds` ** – l’ID del gruppo di sicurezza creato per il file system.
+ **`deploymentType` (facoltativo)**: il tipo di implementazione del file system. I valori validi sono `SCRATCH_1`, `SCRATCH_2`, `PERSISTENT_1` e `PERSISTENT_2`. Per ulteriori informazioni sui tipi di distribuzione, consulta [Create your Amazon FSx for Lustre file system](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step1.html).
+ **altri parametri (facoltativo)**: per informazioni sugli altri parametri, consulta [Modifica StorageClass](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass) su GitHub.
1. Crea il manifesto della classe di storage.
```
kubectl apply -f storageclass.yaml
```
Di seguito viene riportato un output di esempio:
```
storageclass.storage.k8s.io/fsx-sc created
```
1. Scaricare il manifesto della dichiarazione di volume persistente.
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/claim.yaml
```
1. (Facoltativo) Modificare il file `claim.yaml`. Cambia `1200Gi` in uno dei valori di incremento riportati di seguito in base ai tuoi requisiti di archiviazione e al `deploymentType` selezionato in un passaggio precedente.
```
storage: 1200Gi
```
+ `SCRATCH_2` e `PERSISTENT` – `1.2 TiB`, `2.4 TiB` o incrementi di 2,4 TiB su 2,4 TiB.
+ `SCRATCH_1` – `1.2 TiB`, `2.4 TiB`, `3.6 TiB` o incrementi di 3,6 TiB su 3,6 TiB.
1. Creare la dichiarazione di volume persistente.
```
kubectl apply -f claim.yaml
```
Di seguito viene riportato un output di esempio:
```
persistentvolumeclaim/fsx-claim created
```
1. Verificare che il file system sia stato sottoposto a provisioning.
```
kubectl describe pvc
```
Di seguito viene riportato un output di esempio:
```
Name: fsx-claim
Namespace: default
StorageClass: fsx-sc
Status: Bound
[...]
```
**Nota**
`Status` può apparire `Pending` per 5-10 minuti, prima di passare a `Bound`. Non continuare con il passo successivo fino a quando `Status` non è `Bound`. Se nel campo `Status` viene visualizzato `Pending` per più di 10 minuti, utilizza i messaggi di avviso negli `Events` come riferimento per risolvere eventuali problemi.
1. Implementare un’applicazione di esempio.
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
```
1. Verificare che l’applicazione di esempio sia in esecuzione.
```
kubectl get pods
```
Di seguito viene riportato un output di esempio:
```
NAME READY STATUS RESTARTS AGE
fsx-app 1/1 Running 0 8s
```
1. Verifica che l’applicazione abbia montato correttamente il file system.
```
kubectl exec -ti fsx-app -- df -h
```
Di seguito viene riportato un output di esempio.
```
Filesystem Size Used Avail Use% Mounted on
overlay 80G 4.0G 77G 5% /
tmpfs 64M 0 64M 0% /dev
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
192.0.2.0@tcp:/abcdef01 1.1T 7.8M 1.1T 1% /data
/dev/nvme0n1p1 80G 4.0G 77G 5% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 6.9G 12K 6.9G 1% /run/secrets/kubernetes.io/serviceaccount
tmpfs 3.8G 0 3.8G 0% /proc/acpi
tmpfs 3.8G 0 3.8G 0% /sys/firmware
```
1. Verifica che i dati siano stati scritti nel file system FSx for Lustre dall'app di esempio.
```
kubectl exec -it fsx-app -- ls /data
```
Di seguito viene riportato un output di esempio.
```
out.txt
```
Questo output esemplificativo mostra che l’app di esempio ha eseguito correttamente la scrittura del file `out.txt` nel file system.
**Nota**
Prima di eliminare il cluster, assicuratevi di eliminare il file system FSx for Lustre. Per ulteriori informazioni, consultate [Clean up resources nella Guida FSx ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step4.html) *per l'utente di for Lustre*.
## Ottimizzazione delle prestazioni per for FSx Lustre
Quando si utilizza FSx per Lustre con Amazon EKS, è possibile ottimizzare le prestazioni applicando le ottimizzazioni Lustre durante l'inizializzazione del nodo. L’approccio consigliato consiste nell’utilizzare i dati utente del modello di avvio per garantire una configurazione coerente su tutti i nodi.
Queste ottimizzazioni includono:
+ Ottimizzazioni di rete e RPC
+ Gestione del modulo Lustre
+ Ottimizzazioni LRU (Lock Resource Unit)
+ Impostazioni di controllo della cache del client
+ Controlli RPC per OST e MDC
Per istruzioni dettagliate sull’implementazione di queste ottimizzazioni delle prestazioni:
+ Per ottimizzare le prestazioni per i nodi standard (non EFA), consulta [Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (non EFA)](fsx-csi-tuning-non-efa.md) per uno script completo che può essere aggiunto ai dati utente del modello di avvio.
+ Per ottimizzare le prestazioni per i nodi abilitati all’EFA, consulta [Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (EFA)](fsx-csi-tuning-efa.md).
# Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (EFA)
Questo argomento descrive come configurare l'ottimizzazione di Elastic Fabric Adapter (EFA) con Amazon EKS e Amazon for Lustre. FSx
**Nota**
Per informazioni sulla creazione e la distribuzione del driver CSI FSx for Lustre, consulta. [Implementa il driver FSx for Lustre](fsx-csi-create.md)
Per ottimizzare i nodi standard senza EFA, consultare [Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (non EFA)](fsx-csi-tuning-non-efa.md).
## Passaggio 1. Crea un cluster EKS
Crea un cluster utilizzando il file di configurazione fornito:
```
# Create cluster using efa-cluster.yaml
eksctl create cluster -f efa-cluster.yaml
```
Esempio: `efa-cluster.yaml`
```
#efa-cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: csi-fsx
region: us-east-1
version: "1.30"
iam:
withOIDC: true
availabilityZones: ["us-east-1a", "us-east-1d"]
managedNodeGroups:
- name: my-efa-ng
instanceType: c6gn.16xlarge
minSize: 1
desiredCapacity: 1
maxSize: 1
availabilityZones: ["us-east-1b"]
volumeSize: 300
privateNetworking: true
amiFamily: Ubuntu2204
efaEnabled: true
preBootstrapCommands:
- |
#!/bin/bash
eth_intf="$(/sbin/ip -br -4 a sh | grep $(hostname -i)/ | awk '{print $1}')"
efa_version=$(modinfo efa | awk '/^version:/ {print $2}' | sed 's/[^0-9.]//g')
min_efa_version="2.12.1"
if [[ "$(printf '%s\n' "$min_efa_version" "$efa_version" | sort -V | head -n1)" != "$min_efa_version" ]]; then
sudo curl -O https://efa-installer.amazonaws.com/aws-efa-installer-1.37.0.tar.gz
tar -xf aws-efa-installer-1.37.0.tar.gz && cd aws-efa-installer
echo "Installing EFA driver"
sudo apt-get update && apt-get upgrade -y
sudo apt install -y pciutils environment-modules libnl-3-dev libnl-route-3-200 libnl-route-3-dev dkms
sudo ./efa_installer.sh -y
modinfo efa
else
echo "Using EFA driver version $efa_version"
fi
echo "Installing Lustre client"
sudo wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg > /dev/null
sudo echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" > /etc/apt/sources.list.d/fsxlustreclientrepo.list
sudo apt update | tail
sudo apt install -y lustre-client-modules-$(uname -r) amazon-ec2-utils | tail
modinfo lustre
echo "Loading Lustre/EFA modules..."
sudo /sbin/modprobe lnet
sudo /sbin/modprobe kefalnd ipif_name="$eth_intf"
sudo /sbin/modprobe ksocklnd
sudo lnetctl lnet configure
echo "Configuring TCP interface..."
sudo lnetctl net del --net tcp 2> /dev/null
sudo lnetctl net add --net tcp --if $eth_intf
# For P5 instance type which supports 32 network cards,
# by default add 8 EFA interfaces selecting every 4th device (1 per PCI bus)
echo "Configuring EFA interface(s)..."
instance_type="$(ec2-metadata --instance-type | awk '{ print $2 }')"
num_efa_devices="$(ls -1 /sys/class/infiniband | wc -l)"
echo "Found $num_efa_devices available EFA device(s)"
if [[ "$instance_type" == "p5.48xlarge" || "$instance_type" == "p5e.48xlarge" ]]; then
for intf in $(ls -1 /sys/class/infiniband | awk 'NR % 4 == 1'); do
sudo lnetctl net add --net efa --if $intf --peer-credits 32
done
else
# Other instances: Configure 2 EFA interfaces by default if the instance supports multiple network cards,
# or 1 interface for single network card instances
# Can be modified to add more interfaces if instance type supports it
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | head -n1) --peer-credits 32
if [[ $num_efa_devices -gt 1 ]]; then
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | tail -n1) --peer-credits 32
fi
fi
echo "Setting discovery and UDSP rule"
sudo lnetctl set discovery 1
sudo lnetctl udsp add --src efa --priority 0
sudo /sbin/modprobe lustre
sudo lnetctl net show
echo "Added $(sudo lnetctl net show | grep -c '@efa') EFA interface(s)"
```
## Passaggio 2. Creazione di un gruppo di nodi
Creazione di un gruppo di nodi abilitato per EFA:
```
# Create node group using efa-ng.yaml
eksctl create nodegroup -f efa-ng.yaml
```
**Importante**
=== Modifica questi valori per il tuo ambiente nella sezione `# 5. Mount FSx filesystem`.
```
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
```
===
Esempio`efa-ng.yaml`:
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: final-efa
region: us-east-1
managedNodeGroups:
- name: ng-1
instanceType: c6gn.16xlarge
minSize: 1
desiredCapacity: 1
maxSize: 1
availabilityZones: ["us-east-1a"]
volumeSize: 300
privateNetworking: true
amiFamily: Ubuntu2204
efaEnabled: true
preBootstrapCommands:
- |
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
#########################################################################################
# Configuration Section #
#########################################################################################
# File System Configuration
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
# Lustre Tuning Parameters
LUSTRE_LRU_MAX_AGE=600000
LUSTRE_MAX_CACHED_MB=64
LUSTRE_OST_MAX_RPC=32
LUSTRE_MDC_MAX_RPC=64
LUSTRE_MDC_MOD_RPC=50
# File paths
FUNCTIONS_SCRIPT="/usr/local/bin/lustre_functions.sh"
TUNINGS_SCRIPT="/usr/local/bin/apply_lustre_tunings.sh"
SERVICE_FILE="/etc/systemd/system/lustre-tunings.service"
#EFA
MIN_EFA_VERSION="2.12.1"
# Function to check if a command was successful
check_success() {
if [ $? -eq 0 ]; then
echo "SUCCESS: $1"
else
echo "FAILED: $1"
return 1
fi
}
echo "********Starting FSx for Lustre configuration********"
# 1. Install Lustre client
if grep -q '^ID=ubuntu' /etc/os-release; then
echo "Detected Ubuntu, proceeding with Lustre setup..."
# Add Lustre repository
sudo wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | sudo gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/fsxlustreclientrepo.list
sudo apt-get update
sudo apt-get install -y lustre-client-modules-$(uname -r)
sudo apt-get install -y lustre-client
else
echo "Not Ubuntu, exiting"
exit 1
fi
check_success "Install Lustre client"
# Ensure Lustre tools are in the PATH
export PATH=$PATH:/usr/sbin
# 2. Apply network and RPC tunings
echo "********Applying network and RPC tunings********"
if ! grep -q "options ptlrpc ptlrpcd_per_cpt_max" /etc/modprobe.d/modprobe.conf; then
echo "options ptlrpc ptlrpcd_per_cpt_max=64" | sudo tee -a /etc/modprobe.d/modprobe.conf
check_success "Set ptlrpcd_per_cpt_max"
else
echo "ptlrpcd_per_cpt_max already set in modprobe.conf"
fi
if ! grep -q "options ksocklnd credits" /etc/modprobe.d/modprobe.conf; then
echo "options ksocklnd credits=2560" | sudo tee -a /etc/modprobe.d/modprobe.conf
check_success "Set ksocklnd credits"
else
echo "ksocklnd credits already set in modprobe.conf"
fi
# 3. Load Lustre modules
manage_lustre_modules() {
echo "Checking for existing Lustre modules..."
if lsmod | grep -q lustre; then
echo "Existing Lustre modules found."
# Check for mounted Lustre filesystems
echo "Checking for mounted Lustre filesystems..."
if mount | grep -q "type lustre"; then
echo "Found mounted Lustre filesystems. Attempting to unmount..."
mounted_fs=$(mount | grep "type lustre" | awk '{print $3}')
for fs in $mounted_fs; do
echo "Unmounting $fs"
sudo umount $fs
check_success "Unmount filesystem $fs"
done
else
echo "No Lustre filesystems mounted."
fi
# After unmounting, try to remove modules
echo "Attempting to remove Lustre modules..."
sudo lustre_rmmod
if [ $? -eq 0 ]; then
echo "SUCCESS: Removed existing Lustre modules"
else
echo "WARNING: Could not remove Lustre modules. They may still be in use."
echo "Please check for any remaining Lustre processes or mounts."
return 1
fi
else
echo "No existing Lustre modules found."
fi
echo "Loading Lustre modules..."
sudo modprobe lustre
check_success "Load Lustre modules" || exit 1
echo "Checking loaded Lustre modules:"
lsmod | grep lustre
}
# Managing Lustre kernel modules
echo "********Managing Lustre kernel modules********"
manage_lustre_modules
# 4. Initializing Lustre networking
echo "********Initializing Lustre networking********"
sudo lctl network up
check_success "Initialize Lustre networking" || exit 1
# 4.5 EFA Setup and Configuration
setup_efa() {
echo "********Starting EFA Setup********"
# Get interface and version information
eth_intf="$(/sbin/ip -br -4 a sh | grep $(hostname -i)/ | awk '{print $1}')"
efa_version=$(modinfo efa | awk '/^version:/ {print $2}' | sed 's/[^0-9.]//g')
min_efa_version=$MIN_EFA_VERSION
# Install or verify EFA driver
if [[ "$(printf '%s\n' "$min_efa_version" "$efa_version" | sort -V | head -n1)" != "$min_efa_version" ]]; then
echo "Installing EFA driver..."
sudo curl -O https://efa-installer.amazonaws.com/aws-efa-installer-1.37.0.tar.gz
tar -xf aws-efa-installer-1.37.0.tar.gz && cd aws-efa-installer
# Install dependencies
sudo apt-get update && apt-get upgrade -y
sudo apt install -y pciutils environment-modules libnl-3-dev libnl-route-3-200 libnl-route-3-dev dkms
# Install EFA
sudo ./efa_installer.sh -y
modinfo efa
else
echo "Using existing EFA driver version $efa_version"
fi
}
configure_efa_network() {
echo "********Configuring EFA Network********"
# Load required modules
echo "Loading network modules..."
sudo /sbin/modprobe lnet
sudo /sbin/modprobe kefalnd ipif_name="$eth_intf"
sudo /sbin/modprobe ksocklnd
# Initialize LNet
echo "Initializing LNet..."
sudo lnetctl lnet configure
# Configure TCP interface
echo "Configuring TCP interface..."
sudo lnetctl net del --net tcp 2> /dev/null
sudo lnetctl net add --net tcp --if $eth_intf
# For P5 instance type which supports 32 network cards,
# by default add 8 EFA interfaces selecting every 4th device (1 per PCI bus)
echo "Configuring EFA interface(s)..."
instance_type="$(ec2-metadata --instance-type | awk '{ print $2 }')"
num_efa_devices="$(ls -1 /sys/class/infiniband | wc -l)"
echo "Found $num_efa_devices available EFA device(s)"
if [[ "$instance_type" == "p5.48xlarge" || "$instance_type" == "p5e.48xlarge" ]]; then
# P5 instance configuration
for intf in $(ls -1 /sys/class/infiniband | awk 'NR % 4 == 1'); do
sudo lnetctl net add --net efa --if $intf --peer-credits 32
done
else
# Standard configuration
# Other instances: Configure 2 EFA interfaces by default if the instance supports multiple network cards,
# or 1 interface for single network card instances
# Can be modified to add more interfaces if instance type supports it
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | head -n1) --peer-credits 32
if [[ $num_efa_devices -gt 1 ]]; then
sudo lnetctl net add --net efa --if $(ls -1 /sys/class/infiniband | tail -n1) --peer-credits 32
fi
fi
# Configure discovery and UDSP
echo "Setting up discovery and UDSP rules..."
sudo lnetctl set discovery 1
sudo lnetctl udsp add --src efa --priority 0
sudo /sbin/modprobe lustre
# Verify configuration
echo "Verifying EFA network configuration..."
sudo lnetctl net show
echo "Added $(sudo lnetctl net show | grep -c '@efa') EFA interface(s)"
}
# Main execution
setup_efa
configure_efa_network
# 5. Mount FSx filesystem
if [ ! -z "$FSX_DNS" ] && [ ! -z "$MOUNT_NAME" ]; then
echo "********Creating mount point********"
sudo mkdir -p $MOUNT_POINT
check_success "Create mount point"
echo "Mounting FSx filesystem..."
sudo mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} ${MOUNT_POINT}
check_success "Mount FSx filesystem"
else
echo "Skipping FSx mount as DNS or mount name is not provided"
fi
# 6. Applying Lustre performance tunings
echo "********Applying Lustre performance tunings********"
# Get number of CPUs
NUM_CPUS=$(nproc)
# Calculate LRU size (100 * number of CPUs)
LRU_SIZE=$((100 * NUM_CPUS))
#Apply LRU tunings
echo "Apply LRU tunings"
sudo lctl set_param ldlm.namespaces.*.lru_max_age=${LUSTRE_LRU_MAX_AGE}
check_success "Set lru_max_age"
sudo lctl set_param ldlm.namespaces.*.lru_size=$LRU_SIZE
check_success "Set lru_size"
# Client Cache Control
sudo lctl set_param llite.*.max_cached_mb=${LUSTRE_MAX_CACHED_MB}
check_success "Set max_cached_mb"
# RPC Controls
sudo lctl set_param osc.*OST*.max_rpcs_in_flight=${LUSTRE_OST_MAX_RPC}
check_success "Set OST max_rpcs_in_flight"
sudo lctl set_param mdc.*.max_rpcs_in_flight=${LUSTRE_MDC_MAX_RPC}
check_success "Set MDC max_rpcs_in_flight"
sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=${LUSTRE_MDC_MOD_RPC}
check_success "Set MDC max_mod_rpcs_in_flight"
# 7. Verify all tunings
echo "********Verifying all tunings********"
# Function to verify parameter value
verify_param() {
local param=$1
local expected=$2
local actual=$3
if [ "$actual" == "$expected" ]; then
echo "SUCCESS: $param is correctly set to $expected"
else
echo "WARNING: $param is set to $actual (expected $expected)"
fi
}
echo "Verifying all parameters:"
# LRU tunings
actual_lru_max_age=$(lctl get_param -n ldlm.namespaces.*.lru_max_age | head -1)
verify_param "lru_max_age" "600000" "$actual_lru_max_age"
actual_lru_size=$(lctl get_param -n ldlm.namespaces.*.lru_size | head -1)
verify_param "lru_size" "$LRU_SIZE" "$actual_lru_size"
# Client Cache
actual_max_cached_mb=$(lctl get_param -n llite.*.max_cached_mb | grep "max_cached_mb:" | awk '{print $2}')
verify_param "max_cached_mb" "64" "$actual_max_cached_mb"
# RPC Controls
actual_ost_rpcs=$(lctl get_param -n osc.*OST*.max_rpcs_in_flight | head -1)
verify_param "OST max_rpcs_in_flight" "32" "$actual_ost_rpcs"
actual_mdc_rpcs=$(lctl get_param -n mdc.*.max_rpcs_in_flight | head -1)
verify_param "MDC max_rpcs_in_flight" "64" "$actual_mdc_rpcs"
actual_mdc_mod_rpcs=$(lctl get_param -n mdc.*.max_mod_rpcs_in_flight | head -1)
verify_param "MDC max_mod_rpcs_in_flight" "50" "$actual_mdc_mod_rpcs"
# Network and RPC configurations from modprobe.conf
actual_ptlrpc=$(grep "ptlrpc ptlrpcd_per_cpt_max" /etc/modprobe.d/modprobe.conf | awk '{print $3}')
verify_param "ptlrpcd_per_cpt_max" "ptlrpcd_per_cpt_max=64" "$actual_ptlrpc"
actual_ksocklnd=$(grep "ksocklnd credits" /etc/modprobe.d/modprobe.conf | awk '{print $3}')
verify_param "ksocklnd credits" "credits=2560" "$actual_ksocklnd"
# 8. Setup persistence
setup_persistence() {
# Create functions file
cat << EOF > $FUNCTIONS_SCRIPT
#!/bin/bash
apply_lustre_tunings() {
local NUM_CPUS=\$(nproc)
local LRU_SIZE=\$((100 * NUM_CPUS))
echo "Applying Lustre performance tunings..."
lctl set_param ldlm.namespaces.*.lru_max_age=$LUSTRE_LRU_MAX_AGE
lctl set_param ldlm.namespaces.*.lru_size=\$LRU_SIZE
lctl set_param llite.*.max_cached_mb=$LUSTRE_MAX_CACHED_MB
lctl set_param osc.*OST*.max_rpcs_in_flight=$LUSTRE_OST_MAX_RPC
lctl set_param mdc.*.max_rpcs_in_flight=$LUSTRE_MDC_MAX_RPC
lctl set_param mdc.*.max_mod_rpcs_in_flight=$LUSTRE_MDC_MOD_RPC
}
EOF
# Create tuning script
cat << EOF > $TUNINGS_SCRIPT
#!/bin/bash
exec 1> >(logger -s -t \$(basename \$0)) 2>&1
source $FUNCTIONS_SCRIPT
# Function to check if Lustre is mounted
is_lustre_mounted() {
mount | grep -q "type lustre"
}
# Function to mount Lustre
mount_lustre() {
echo "Mounting Lustre filesystem..."
mkdir -p $MOUNT_POINT
mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} $MOUNT_POINT
return \$?
}
# Main execution
# Try to mount if not already mounted
if ! is_lustre_mounted; then
echo "Lustre filesystem not mounted, attempting to mount..."
mount_lustre
fi
# Wait for successful mount (up to 5 minutes)
for i in {1..30}; do
if is_lustre_mounted; then
echo "Lustre filesystem mounted, applying tunings..."
apply_lustre_tunings
exit 0
fi
echo "Waiting for Lustre filesystem to be mounted... (attempt $i/30)"
sleep 10
done
echo "Timeout waiting for Lustre filesystem mount"
exit 1
EOF
# Create systemd service
# Create systemd directory if it doesn't exist
sudo mkdir -p /etc/systemd/system/
# Create service file directly for Ubuntu
cat << EOF > $SERVICE_FILE
[Unit]
Description=Apply Lustre Performance Tunings
After=network.target remote-fs.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'source $FUNCTIONS_SCRIPT && $TUNINGS_SCRIPT'
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
# Make scripts executable and enable service
sudo chmod +x $FUNCTIONS_SCRIPT
sudo chmod +x $TUNINGS_SCRIPT
systemctl enable lustre-tunings.service
systemctl start lustre-tunings.service
}
echo "********Setting up persistent tuning********"
setup_persistence
echo "FSx for Lustre configuration completed."
```
## (Facoltativo) Passaggio 3. Verifica della configurazione EFA
SSH nel nodo:
```
# Get instance ID from EKS console or {aws} CLI
ssh -i /path/to/your-key.pem ec2-user@
```
Verifica della configurazione EFA:
```
sudo lnetctl net show
```
Controlla i registri di configurazione:
```
sudo cat /var/log/cloud-init-output.log
```
Ecco un esempio di output previsto per `lnetctl net show`:
```
net:
- net type: tcp
...
- net type: efa
local NI(s):
- nid: xxx.xxx.xxx.xxx@efa
status: up
```
## Esempio di implementazioni
### a. Creazione di claim.yaml
```
#claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: fsx-claim-efa
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 4800Gi
volumeName: fsx-pv
```
Applica la richiesta:
```
kubectl apply -f claim.yaml
```
### b. Creazione di pv.yaml
Aggiorna``:
```
#pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: fsx-pv
spec:
capacity:
storage: 4800Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
mountOptions:
- flock
persistentVolumeReclaimPolicy: Recycle
csi:
driver: fsx.csi.aws.com
volumeHandle: fs-<1234567890abcdef0>
volumeAttributes:
dnsname: fs-<1234567890abcdef0>.fsx.us-east-1.amazonaws.com
mountname:
```
Applica il volume persistente:
```
kubectl apply -f pv.yaml
```
### c. Creazione di pod.yaml
```
#pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: fsx-efa-app
spec:
containers:
- name: app
image: amazonlinux:2
command: ["/bin/sh"]
args: ["-c", "while true; do dd if=/dev/urandom bs=100M count=20 > data/test_file; sleep 10; done"]
resources:
requests:
vpc.amazonaws.com/efa: 1
limits:
vpc.amazonaws.com/efa: 1
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: fsx-claim-efa
```
Applica il pod:
```
kubectl apply -f pod.yaml
```
## Comandi di verifica aggiuntivi
Verifica i montaggi del pod e scrive sul filesystem:
```
kubectl exec -ti fsx-efa-app -- df -h | grep data
# Expected output:
# <192.0.2.0>@tcp:/ 4.5T 1.2G 4.5T 1% /data
kubectl exec -ti fsx-efa-app -- ls /data
# Expected output:
# test_file
```
SSH sul nodo per verificare che il traffico stia passando attraverso EFA:
```
sudo lnetctl net show -v
```
L’output previsto mostrerà le interfacce EFA con le statistiche sul traffico.
## Informazioni correlate
+ [Implementa il driver FSx for Lustre](fsx-csi-create.md)
+ [Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (non EFA)](fsx-csi-tuning-non-efa.md)
+ [Prestazioni Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
+ [Elastic Fabric Adapter](https://docs.aws.amazon.com/ec2/latest/userguide/efa.html)
# Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (non EFA)
Puoi ottimizzare le prestazioni di Amazon FSx for Lustre applicando i parametri di ottimizzazione durante l'inizializzazione del nodo utilizzando i dati utente del modello di lancio.
**Nota**
Per informazioni sulla creazione e la distribuzione del driver CSI FSx for Lustre, consulta. [Implementa il driver FSx for Lustre](fsx-csi-create.md) Per ottimizzare le prestazioni con i nodi abilitati all’EFA, consultare [Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (EFA)](fsx-csi-tuning-efa.md).
## Perché utilizzare i dati utente del modello di avvio?
+ Applica automaticamente le ottimizzazioni durante l’inizializzazione del nodo.
+ Garantisce una configurazione coerente su tutti i nodi.
+ Elimina la necessità di configurare manualmente il nodo.
## Panoramica degli script di esempio
Lo script di esempio definito in questo argomento esegue le seguenti operazioni:
### `# 1. Install Lustre client`
+ Rileva automaticamente la versione del tuo sistema operativo Amazon Linux (AL).
+ Installa il pacchetto client Lustre appropriato.
### `# 2. Apply network and RPC tunings`
+ Imposta `ptlrpcd_per_cpt_max=64` per l’elaborazione RPC parallela.
+ Configura `ksocklnd credits=2560` per ottimizzare i buffer di rete.
### `# 3. Load Lustre modules`
+ Rimuove in modo sicuro i moduli Lustre esistenti, se presenti.
+ Gestisce lo smontaggio dei filesystem esistenti.
+ Carica nuovi moduli Lustre.
### `# 4. Lustre Network Initialization`
+ Inizializza la configurazione di rete Lustre.
+ Imposta i parametri di rete richiesti.
### `# 5. Mount FSx filesystem`
+ È necessario modificare i valori per il tuo ambiente in questa sezione.
### `# 6. Apply tunings`
+ Ottimizzazioni LRU (Lock Resource Unit):
+ `lru_max_age=600000`
+ `lru_size` calcolato in base al numero di CPU
+ Controllo della cache del client: `max_cached_mb=64`
+ Controlli RPC:
+ OST `max_rpcs_in_flight=32`
+ MDC `max_rpcs_in_flight=64`
+ MDC `max_mod_rpcs_in_flight=50`
### `# 7. Verify tunings`
+ Verifica tutte le ottimizzazioni applicate.
+ Segnala il successo o l’avviso per ogni parametro.
### `# 8. Setup persistence`
+ È necessario modificare i valori per il tuo ambiente anche in questa sezione.
+ Rileva automaticamente la versione del sistema operativo (AL2023) per determinare quale `Systemd` servizio applicare.
+ Il sistema si avvia.
+ `Systemd` avvia il servizio `lustre-tunings` (a causa di `WantedBy=multi-user.target`).
+ Il servizio esegue `apply_lustre_tunings.sh` che:
+ Verifica se il filesystem è montato.
+ Monta il filesystem se non è montato.
+ Attende che il montaggio venga eseguito con successo (fino a cinque minuti).
+ Applica i parametri di ottimizzazione dopo il montaggio riuscito.
+ Le impostazioni rimangono attive fino al riavvio.
+ Il servizio si chiude dopo il completamento dello script.
+ Systemd contrassegna il servizio come “attivo (terminato)”.
+ Il processo si ripete al successivo riavvio.
## Creazione di un modello di avvio
1. Apri la EC2 console Amazon all'indirizzo https://console.aws.amazon.com/ec2/.
1. Scegli **Modelli di avvio**.
1. Scegli **Crea modello di avvio**.
1. In **Dettagli avanzati**, individua la sezione **Dati utente**.
1. Incolla lo script qui di seguito, aggiornando tutto ciò che è necessario.
**Importante**
Regola questi valori per il tuo ambiente sia nella sezione `# 5. Mount FSx filesystem` che nella funzione `setup_persistence()` di `apply_lustre_tunings.sh` nella sezione `# 8. Setup persistence`:
```
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
```
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
# Function definitions
check_success() {
if [ $? -eq 0 ]; then
echo "SUCCESS: $1"
else
echo "FAILED: $1"
return 1
fi
}
apply_tunings() {
local NUM_CPUS=$(nproc)
local LRU_SIZE=$((100 * NUM_CPUS))
local params=(
"ldlm.namespaces.*.lru_max_age=600000"
"ldlm.namespaces.*.lru_size=$LRU_SIZE"
"llite.*.max_cached_mb=64"
"osc.*OST*.max_rpcs_in_flight=32"
"mdc.*.max_rpcs_in_flight=64"
"mdc.*.max_mod_rpcs_in_flight=50"
)
for param in "${params[@]}"; do
lctl set_param $param
check_success "Set ${param%%=*}"
done
}
verify_param() {
local param=$1
local expected=$2
local actual=$3
if [ "$actual" == "$expected" ]; then
echo "SUCCESS: $param is correctly set to $expected"
else
echo "WARNING: $param is set to $actual (expected $expected)"
fi
}
verify_tunings() {
local NUM_CPUS=$(nproc)
local LRU_SIZE=$((100 * NUM_CPUS))
local params=(
"ldlm.namespaces.*.lru_max_age:600000"
"ldlm.namespaces.*.lru_size:$LRU_SIZE"
"llite.*.max_cached_mb:64"
"osc.*OST*.max_rpcs_in_flight:32"
"mdc.*.max_rpcs_in_flight:64"
"mdc.*.max_mod_rpcs_in_flight:50"
)
echo "Verifying all parameters:"
for param in "${params[@]}"; do
name="${param%%:*}"
expected="${param#*:}"
actual=$(lctl get_param -n $name | head -1)
verify_param "${name##*.}" "$expected" "$actual"
done
}
setup_persistence() {
# Create functions file
cat << 'EOF' > /usr/local/bin/lustre_functions.sh
#!/bin/bash
apply_lustre_tunings() {
local NUM_CPUS=$(nproc)
local LRU_SIZE=$((100 * NUM_CPUS))
echo "Applying Lustre performance tunings..."
lctl set_param ldlm.namespaces.*.lru_max_age=600000
lctl set_param ldlm.namespaces.*.lru_size=$LRU_SIZE
lctl set_param llite.*.max_cached_mb=64
lctl set_param osc.*OST*.max_rpcs_in_flight=32
lctl set_param mdc.*.max_rpcs_in_flight=64
lctl set_param mdc.*.max_mod_rpcs_in_flight=50
}
EOF
# Create tuning script
cat << 'EOF' > /usr/local/bin/apply_lustre_tunings.sh
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
# Source the functions
source /usr/local/bin/lustre_functions.sh
# FSx details
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
# Function to check if Lustre is mounted
is_lustre_mounted() {
mount | grep -q "type lustre"
}
# Function to mount Lustre
mount_lustre() {
echo "Mounting Lustre filesystem..."
mkdir -p ${MOUNT_POINT}
mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} ${MOUNT_POINT}
return $?
}
# Main execution
# Try to mount if not already mounted
if ! is_lustre_mounted; then
echo "Lustre filesystem not mounted, attempting to mount..."
mount_lustre
fi
# Wait for successful mount (up to 5 minutes)
for i in {1..30}; do
if is_lustre_mounted; then
echo "Lustre filesystem mounted, applying tunings..."
apply_lustre_tunings
exit 0
fi
echo "Waiting for Lustre filesystem to be mounted... (attempt $i/30)"
sleep 10
done
echo "Timeout waiting for Lustre filesystem mount"
exit 1
EOF
# Create systemd service
cat << 'EOF' > /etc/systemd/system/lustre-tunings.service
[Unit]
Description=Apply Lustre Performance Tunings
After=network.target remote-fs.target
StartLimitIntervalSec=0
[Service]
Type=oneshot
ExecStart=/usr/local/bin/apply_lustre_tunings.sh
RemainAfterExit=yes
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
EOF
chmod +x /usr/local/bin/lustre_functions.sh
chmod +x /usr/local/bin/apply_lustre_tunings.sh
systemctl enable lustre-tunings.service
systemctl start lustre-tunings.service
}
echo "Starting FSx for Lustre configuration..."
# 1. Install Lustre client
if grep -q 'VERSION="2"' /etc/os-release; then
amazon-linux-extras install -y lustre
elif grep -q 'VERSION="2023"' /etc/os-release; then
dnf install -y lustre-client
fi
check_success "Install Lustre client"
# 2. Apply network and RPC tunings
export PATH=$PATH:/usr/sbin
echo "Applying network and RPC tunings..."
if ! grep -q "options ptlrpc ptlrpcd_per_cpt_max" /etc/modprobe.d/modprobe.conf; then
echo "options ptlrpc ptlrpcd_per_cpt_max=64" | tee -a /etc/modprobe.d/modprobe.conf
echo "options ksocklnd credits=2560" | tee -a /etc/modprobe.d/modprobe.conf
fi
# 3. Load Lustre modules
modprobe lustre
check_success "Load Lustre modules" || exit 1
# 4. Lustre Network Initialization
lctl network up
check_success "Initialize Lustre networking" || exit 1
# 5. Mount FSx filesystem
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
if [ ! -z "$FSX_DNS" ] && [ ! -z "$MOUNT_NAME" ]; then
mkdir -p $MOUNT_POINT
mount -t lustre ${FSX_DNS}@tcp:/${MOUNT_NAME} ${MOUNT_POINT}
check_success "Mount FSx filesystem"
fi
# 6. Apply tunings
apply_tunings
# 7. Verify tunings
verify_tunings
# 8. Setup persistence
setup_persistence
echo "FSx for Lustre configuration completed."
--==MYBOUNDARY==--
```
1. Quando crei gruppi di nodi Amazon EKS, seleziona questo modello di avvio. Per ulteriori informazioni, consulta [Creare un gruppo di nodi gestiti per il cluster](create-managed-node-group.md).
## Informazioni correlate
+ [Implementa il driver FSx for Lustre](fsx-csi-create.md)
+ [Ottimizza le prestazioni di Amazon FSx for Lustre sui nodi (EFA)](fsx-csi-tuning-efa.md)
+ [Prestazioni Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
# Usa l’archiviazione delle app ad alte prestazioni con FSx per NetApp ONTAP
NetApp Trident offre un’orchestrazione dinamica dello storage utilizzando un driver compatibile con CSI (Container Storage Interface). Ciò consente ai cluster Amazon EKS di gestire il ciclo di vita dei volumi persistenti (PV) supportati dai file system Amazon FSx per NetApp ONTAP. Tieni presente che il driver CSI di Amazon FSx per NetApp ONTAP non è compatibile con Amazon EKS Hybrid Nodes. Per iniziare, consultare [Use Trident with Amazon FSx for NetApp ONTAP](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html) nella documentazione di NetApp Trident.
Amazon FSx per NetApp ONTAP è un servizio di archiviazione che consente di avviare ed eseguire file system ONTAP completamente gestiti nel cloud. ONTAP è la tecnologia di file system di NetApp che fornisce un insieme ampiamente adottato di funzionalità di accesso ai dati e gestione dei dati. FSx per ONTAP offre le funzionalità, le prestazioni e le API dei file system NetApp on-premises con l’agilità, la scalabilità e l’agilità di un servizio AWS completamente gestito. Per ulteriori informazioni, consulta la [Guida per l’utente di FSx per ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html).
**Importante**
Se utilizzi Amazon FSx per NetApp ONTAP insieme al driver Amazon EBS CSI per il provisioning dei volumi EBS, devi specificare di non utilizzare dispositivi EBS nel file `multipath.conf`. Per i metodi supportati, consulta [Configuration File Blacklist](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/dm_multipath/config_file_blacklist#config_file_blacklist). Ecco un esempio.
```
defaults {
user_friendly_names yes
find_multipaths no
}
blacklist {
device {
vendor "NVME"
product "Amazon Elastic Block Store"
}
}
```
# Usa l’archiviazione di dati con Amazon FSx per OpenZFS
Amazon FSx per OpenZFS è un servizio di archiviazione di file interamente gestito che semplifica il trasferimento di dati su AWS da ZFS on-premise o altri file server basati su Linux. Puoi farlo senza modificare il codice dell’applicazione o la modalità di gestione dei dati. Offre un’archiviazione di file altamente affidabile, scalabile, efficiente e ricca di funzionalità basata sul file system OpenZFS open source. Combina queste funzionalità con l’agilità, la scalabilità e la semplicità di un servizio AWS interamente gestito. Per ulteriori informazioni, consulta la [Guida per l’utente di Amazon FSx per OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/what-is-fsx.html).
Il driver Container Storage Interface (CSI) di FSx per OpenZFS mette a disposizione un’interfaccia CSI che consente ai cluster EKS di gestire il ciclo di vita dei volumi Amazon FSx per OpenZFS. Tieni presente che il Driver CSI di Amazon FSx per OpenZFS non è compatibile con Amazon EKS Hybrid Nodes. Per implementare il driver CSI di FSx per OpenZFS nel tuo cluster Amazon EKS, consulta [aws-fsx-openzfs-csi-driver](https://github.com/kubernetes-sigs/aws-fsx-openzfs-csi-driver) su GitHub.
# Riduci al minimo la latenza con Amazon File Cache
Amazon File Cache è una cache ad alta velocità completamente gestita su AWS che viene utilizzata per elaborare i dati dei file indipendentemente da dove sono archiviati. Amazon File Cache carica automaticamente i dati nella cache quando vi si accede per la prima volta e li rilascia quando non vengono utilizzati. Per ulteriori informazioni, consulta la [Guida per l’utente di Amazon File Cache](https://docs.aws.amazon.com/fsx/latest/FileCacheGuide/what-is.html).
Il driver Container Storage Interface (CSI) di Amazon File Cache mette a disposizione un’interfaccia CSI che consente ai cluster Amazon EKS di gestire il ciclo di vita delle cache di file di Amazon. Tieni presente che il driver Amazon File Cache CSI non è compatibile con Amazon EKS Hybrid Nodes. Per implementare il driver CSI di Amazon File Cache nel tuo cluster Amazon EKS, consulta [aws-file-cache-csi-driver](https://github.com/kubernetes-sigs/aws-file-cache-csi-driver) su GitHub.
# Accedere agli oggetti Amazon S3 con il driver CSI Mountpoint per Amazon S3
Con il [driver dell’interfaccia di archiviazione del container (CSI) di Mountpoint per Amazon S3](https://github.com/awslabs/mountpoint-s3-csi-driver), le applicazioni Kubernetes possono accedere agli oggetti Amazon S3 tramite un’interfaccia di file system, raggiungendo una throughput aggregato elevato senza modificare alcun codice applicativo. Basato su [Mountpoint per Amazon S3](https://github.com/awslabs/mountpoint-s3), il driver CSI presenta un bucket Amazon S3 come volume, a cui è possibile accedere tramite i container in Amazon EKS e i cluster Kubernetes autogestiti.
## Considerazioni
+ Il driver CSI di Mountpoint per Amazon S3 non è compatibile con le immagini di container basate su Windows.
+ Il driver CSI di Mountpoint per Amazon S3 non è attualmente compatibile con Amazon EKS Hybrid Nodes.
+ Il driver CSI di Mountpoint per Amazon S3 non supporta AWS Fargate. Tuttavia, sono supportati i container in esecuzione in Amazon EC2 (con Amazon EKS o un’installazione Kubernetes personalizzata).
+ Il driver CSI di Mountpoint per Amazon S3 supporta solo il provisioning statico. Non è supportato il provisioning dinamico o la creazione di nuovi bucket.
**Nota**
Il provisioning statico si riferisce all’utilizzo di un bucket Amazon S3 esistente specificato come `bucketName` in `volumeAttributes` nell’oggetto `PersistentVolume`. Per ulteriori informazioni, consulta [Provisioning statico](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/examples/kubernetes/static_provisioning/README.md) su GitHub.
+ I volumi montati con il driver CSI di Mountpoint per Amazon S3 non supportano tutte le funzionalità del file system POSIX. Per i dettagli sul comportamento del file system, consulta [Comportamento del file system di Mountpoint per Amazon S3](https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md) su GitHub.
Per i dettagli sull’implementazione del driver, consulta [Implementazione del driver Mountpoint per Amazon S3](s3-csi-create.md). Per informazioni dettagliate sulla rimozione del driver, consulta [Rimozione del componente aggiuntivo Amazon EKS di Mountpoint per Amazon S3](removing-s3-csi-eks-add-on.md).
# Implementazione del driver Mountpoint per Amazon S3
Con il [driver dell’interfaccia di archiviazione del container (CSI) di Mountpoint per Amazon S3](https://github.com/awslabs/mountpoint-s3-csi-driver), le applicazioni Kubernetes possono accedere agli oggetti Amazon S3 tramite un’interfaccia di file system, raggiungendo una throughput aggregato elevato senza modificare alcun codice applicativo.
Questa procedura illustra come implementare il [driver Amazon EKS CSI di Mountpoint per Amazon S3](s3-csi.md). Prima di procedere, consulta [Considerazioni](s3-csi.md#s3-csi-considerations).
## Prerequisiti
+ Un provider di AWS Identity and Access Management (IAM) OpenID Connect (OIDC) esistente per il tuo cluster. Per determinare se si dispone già di un provider IAM o per crearne uno, consulta [Per creare un provider di identità IAM OIDC per il cluster](enable-iam-roles-for-service-accounts.md).
+ Versione 2.12.3 o successiva della AWS CLI installata e configurata sul dispositivo o. AWS CloudShell
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
## Fase 1: Creazione di una policy IAM
Il driver CSI di Mountpoint per Amazon S3 richiede le autorizzazioni Amazon S3 per interagire con il file system. In questa sezione viene descritto come creare una policy IAM che conceda le autorizzazioni necessarie.
La seguente policy esemplificativa segue i suggerimenti delle autorizzazioni IAM per Mountpoint. In alternativa, puoi utilizzare la politica AWS gestita [AmazonS3 FullAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AmazonS3FullAccess$jsonEditor), ma questa politica gestita concede più autorizzazioni di quelle necessarie per Mountpoint.
[Per ulteriori informazioni sulle autorizzazioni consigliate per Mountpoint, consulta Mountpoint IAM permissions on.](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#iam-permissions) GitHub
1. Apri la console IAM all'indirizzo. https://console.aws.amazon.com/iam/
1. Nel pannello di navigazione a sinistra, seleziona **Policy**.
1. Nella pagina **Policy**, scegli **Crea policy**.
1. Per **Editor di policy**, scegli **JSON**.
1. In **Editor di policy**, copia e incolla quanto segue:
**Importante**
Sostituisci `amzn-s3-demo-bucket1` con il nome del bucket Amazon S3.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MountpointFullBucketAccess",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1"
]
},
{
"Sid": "MountpointFullObjectAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:AbortMultipartUpload",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket1/*"
]
}
]
}
```
I bucket di directory, introdotti con la classe di archiviazione Amazon S3 Express One Zone, utilizzano un meccanismo di autenticazione diverso dai bucket per uso generico. Invece di utilizzare le azioni `s3:*`, devi utilizzare l’azione `s3express:CreateSession`. Per ulteriori informazioni sui bucket, consulta [Bucket di directory](https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-buckets-overview.html) nella *Guida per l’utente di Amazon S3*.
Di seguito è riportato un esempio di policy dei privilegi minimi da utilizzare per un bucket di directory.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3express:CreateSession",
"Resource": "arn:aws:s3express:us-west-2:111122223333:bucket/amzn-s3-demo-bucket1--usw2-az1--x-s3"
}
]
}
```
1. Scegli **Next (Successivo)**.
1. Nella pagina **Verifica e crea**, assegna un nome alla policy. Questa procedura guidata di esempio utilizza il nome `AmazonS3CSIDriverPolicy`.
1. Scegli **Crea policy**.
## Fase 2: creazione di un ruolo IAM
Il driver CSI di Mountpoint per Amazon S3 richiede le autorizzazioni Amazon S3 per interagire con il file system. In questa sezione viene descritto come creare un ruolo IAM per delegare queste autorizzazioni. Per creare questo ruolo, è possibile utilizzare uno di questi strumenti:
+ [eksctl](#eksctl_s3_store_app_data)
+ [Console di gestione AWS](#console_s3_store_app_data)
+ [AWS CLI](#awscli_s3_store_app_data)
**Nota**
La policy IAM `AmazonS3CSIDriverPolicy` è stata creata nella sezione precedente.
### eksctl
**creazione del ruolo IAM del driver CSI di Mountpoint per Amazon S3 con `eksctl`**
Per creare il ruolo IAM e dell’account di servizio Kubernetes, esegui i comandi seguenti. Questi comandi allegano anche la policy IAM `AmazonS3CSIDriverPolicy` al ruolo, annotano l’account di servizio Kubernetes (`s3-csi-controller-sa`) con nome della risorsa Amazon (ARN) del ruolo IAM e aggiungono il nome dell’account di servizio Kubernetes alla policy di attendibilità per il ruolo IAM.
```
CLUSTER_NAME=my-cluster
REGION=region-code
ROLE_NAME=AmazonEKS_S3_CSI_DriverRole
POLICY_ARN=AmazonEKS_S3_CSI_DriverRole_ARN
eksctl create iamserviceaccount \
--name s3-csi-driver-sa \
--namespace kube-system \
--cluster $CLUSTER_NAME \
--attach-policy-arn $POLICY_ARN \
--approve \
--role-name $ROLE_NAME \
--region $REGION \
--role-only
```
### Console di gestione AWS
1. Apri la console IAM all'indirizzo https://console.aws.amazon.com/iam/.
1. Nel pannello di navigazione a sinistra, seleziona **Ruoli**.
1. Nella pagina **Ruoli**, seleziona **Crea ruolo**.
1. Nella pagina **Select trusted entity** (Seleziona entità attendibile), esegui le operazioni seguenti:
1. Nella sezione **Tipo di identità attendibile**, scegli **Identità Web**.
1. Per **Identity provider** (Provider di identità), scegli **URL del provider OpenID Connect** per il cluster (come mostrato nella scheda **Overview** (Panoramica) in Amazon EKS).
Se non URLs ne viene visualizzato nessuno, consulta i [Prerequisiti](#s3-csi-prereqs).
1. Per **Pubblico**, scegli `sts.amazonaws.com`.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Add permissions** (Aggiungi autorizzazioni), esegui le operazioni seguenti:
1. Nella casella **Filtra politiche**, inserisci la politica di CSIDriver AmazonS3.
**Nota**
Questa policy è stata creata nella sezione precedente.
1. Seleziona la casella di controllo a sinistra del risultato `AmazonS3CSIDriverPolicy` restituito dalla ricerca.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Name, review, and create** (Assegna un nome, rivedi e crea), esegui le operazioni seguenti:
1. Per **il nome del ruolo, inserisci un nome** univoco per il tuo ruolo, ad esempio AmazonEKS\$1S3\$1CSI\$1. DriverRole
1. In **Aggiungi tag (facoltativo)**, aggiungi metadati al ruolo collegando i tag come coppie chiave-valore. Per ulteriori informazioni sull’utilizzo di tag in IAM, consulta la sezione [Tagging IAM resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *Guida per l’utente di IAM*.
1. Scegli **Crea ruolo**.
1. Dopo aver creato il ruolo, sceglilo nella console in modo da aprirlo per la modifica.
1. Scegli la scheda **Trust relationships** (Relazioni di attendibilità), quindi scegli **Edit trust policy** (Modifica policy di attendibilità).
1. Cercare il risultato finale simile al seguente:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
```
Inserisci una virgola alla fine della riga precedente, quindi aggiungine una seguente dopo quella riga. Sostituiscilo con la regione in cui si trova il cluster. *region-code* AWS Sostituire *EXAMPLED539D4633E53DE1B71EXAMPLE* con l’ID del gestore OIDC del cluster.
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:s3-csi-driver-sa"
```
1. Assicurati che l’operatore `Condition` sia impostato su `"StringEquals"`.
1. Scegli **Aggiorna policy** per concludere.
### AWS CLI
1. Visualizza l'URL del provider OIDC del cluster. Sostituisci *my-cluster* con il nome del cluster. Se l'output dal comando è `None`, rivedi i [Prerequisiti](#s3-csi-prereqs).
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
Di seguito viene riportato un output di esempio.
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
1. Creare il ruolo IAM, concedendo all'account di servizio Kubernetes l'operazione `AssumeRoleWithWebIdentity`.
1. Copiare i contenuti seguenti in un file denominato `aws-s3-csi-driver-trust-policy.json`. Sostituisci *111122223333* con l'ID del tuo account. Sostituire *EXAMPLED539D4633E53DE1B71EXAMPLE* 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.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:s3-csi-driver-sa",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Creare il ruolo. È possibile modificare *AmazonEKS\$1S3\$1CSI\$1DriverRole* con un nome diverso. In tal caso, assicurati di modificarlo anche nelle fasi successive.
```
aws iam create-role \
--role-name AmazonEKS_S3_CSI_DriverRole \
--assume-role-policy-document file://"aws-s3-csi-driver-trust-policy.json"
```
1. Collega la policy IAM creata in precedenza al ruolo con il seguente comando.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonS3CSIDriverPolicy \
--role-name AmazonEKS_S3_CSI_DriverRole
```
**Nota**
La policy IAM `AmazonS3CSIDriverPolicy` è stata creata nella sezione precedente.
1. Salta questo passaggio se stai installando il driver come componente aggiuntivo di Amazon EKS. Per le installazioni autogestite del driver, crea account di servizio Kubernetes annotati con l’ARN del ruolo IAM che hai creato.
1. Salvare i seguenti contenuti in un file denominato `mountpoint-s3-service-account.yaml`. Sostituisci *111122223333* con l'ID del tuo account.
```
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/name: aws-mountpoint-s3-csi-driver
name: mountpoint-s3-csi-controller-sa
namespace: kube-system
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
```
1. Creare l’account del servizio Kubernetes nel cluster. L'account del servizio Kubernetes (`mountpoint-s3-csi-controller-sa`) è annotato con il nome del ruolo IAM che hai creato. *AmazonEKS\$1S3\$1CSI\$1DriverRole*
```
kubectl apply -f mountpoint-s3-service-account.yaml
```
**Nota**
Quando implementi il plugin tramite questa procedura, il plugin crea ed è configurato per l'utilizzo di un account di servizio denominato `s3-csi-driver-sa`.
## Fase 3: installazione del driver CSI di Mountpoint per Amazon S3
È possibile installare il driver CSI di Mountpoint per Amazon S3 tramite il componente aggiuntivo di Amazon EKS. Per aggiungere il componente aggiuntivo al cluster, è possibile utilizzare i seguenti strumenti:
+ [eksctl](#eksctl_s3_add_store_app_data)
+ [Console di gestione AWS](#console_s3_add_store_app_data)
+ [AWS CLI](#awscli_s3_add_store_app_data)
In alternativa, è possibile installare il driver CSI Mountpoint per Amazon S3 come installazione autogestita. Per istruzioni su come eseguire un'installazione autogestita, consulta [Installazione](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/docs/install.md#deploy-driver) su GitHub.
A partire da `v1.8.0`, è possibile configurare i taint da tollerare per i pod del driver CSI. Per fare ciò, specifica un set personalizzato di taint da tollerare con `node.tolerations` o tollera tutti i taint con `node.tolerateAllTaints`. Per ulteriori informazioni, consulta [Taint e tolleranze](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nella documentazione Kubernetes.
### eksctl
**Aggiungere il componente aggiuntivo CSI per Amazon S3 utilizzando `eksctl` **
Eseguire il seguente comando seguente. Sostituisci *my-cluster* con il nome del cluster, *111122223333* con il tuo ID account e *AmazonEKS\$1S3\$1CSI\$1DriverRole* con il nome del [ruolo IAM creato in precedenza](#s3-create-iam-role).
```
eksctl create addon --name aws-mountpoint-s3-csi-driver --cluster my-cluster \
--service-account-role-arn arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole --force
```
Se si rimuove l'opzione *--force* e tutte le impostazioni del componente aggiuntivo Amazon EKS sono in conflitto con le impostazioni esistenti, l'aggiornamento del componente aggiuntivo Amazon EKS non avrà successo. Verrà quindi visualizzato un messaggio di errore con la procedura utile a risolvere il conflitto. Prima di specificare questa opzione, assicurati che il componente aggiuntivo di Amazon EKS non gestisca le impostazioni che devi gestire tu, perché questa opzione le sovrascrive. Per ulteriori informazioni su altre opzioni per questa impostazione, consulta [Componenti aggiuntivi](https://eksctl.io/usage/addons/) nella documentazione di `eksctl`. Per ulteriori informazioni sulla gestione dei campi Kubernetes di Amazon EKS, consulta [Determina i campi che puoi personalizzare per i componenti aggiuntivi Amazon EKS](kubernetes-field-management.md).
È possibile personalizzare `eksctl` tramite file di configurazione. Per ulteriori informazioni, consulta [Funzionamento con i valori di configurazione](https://eksctl.io/usage/addons/#working-with-configuration-values) nella documentazione `eksctl`. L’esempio seguente mostra come tollerare tutti i taint.
```
# config.yaml
...
addons:
- name: aws-mountpoint-s3-csi-driver
serviceAccountRoleARN: arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
configurationValues: |-
node:
tolerateAllTaints: true
```
### Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Scegli il nome del cluster per cui configurare il componente aggiuntivo CSI di Mountpoint per Amazon S3.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Scegli **Ottieni altri componenti aggiuntivi**.
1. Nella pagina **Seleziona componenti aggiuntivi**, procedi come segue:
1. Nella sezione **Componenti aggiuntivi di Amazon EKS**, seleziona la casella di controllo **Driver CSI di Mountpoint per Amazon S3**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Configura le impostazioni dei componenti aggiuntivi selezionati**, procedi come segue:
1. Seleziona la **Versione** che desideri utilizzare.
1. In **Seleziona ruolo IAM**, seleziona il nome di un ruolo IAM a cui è stata allegata la policy IAM del driver CSI di Mountpoint per Amazon S3.
1. (Facoltativo) Aggiorna il **Metodo di risoluzione dei conflitti** dopo aver espanso le **Impostazioni di configurazione opzionali**. Se selezioni **Sostituisci**, una o più impostazioni per il componente aggiuntivo esistente possono essere sovrascritte con le impostazioni del componente aggiuntivo di Amazon EKS. Se non si abilita questa opzione e c’è un conflitto con le impostazioni esistenti, l’operazione non va a buon fine e viene visualizzato un messaggio di errore per aiutarti a risolvere il conflitto. Prima di selezionare questa opzione, assicurarsi che il componente aggiuntivo Amazon EKS non gestisca le impostazioni che devono essere gestite dall’utente.
1. (Facoltativo) Configura le tolleranze nel campo **Valori di configurazione** dopo aver espanso le **Impostazioni di configurazione opzionali**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e aggiungi**, scegli **Crea**. Una volta completata l'installazione, viene visualizzato il componente aggiuntivo.
### AWS CLI
**Per aggiungere il componente aggiuntivo Mountpoint for Amazon S3 CSI utilizzando la CLI AWS **
Eseguire il seguente comando seguente. Sostituire *my-cluster* con il nome del cluster, *111122223333* con il proprio ID account e *AmazonEKS\$1S3\$1CSI\$1DriverRole* con il nome del ruolo creato in precedenza.
```
aws eks create-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver \
--service-account-role-arn arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
```
È possibile personalizzare il comando con il contrassegno `--configuration-values`. L’esempio alternativo seguente mostra come tollerare tutti i taint.
```
aws eks create-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver \
--service-account-role-arn arn:aws: iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole \
--configuration-values '{"node":{"tolerateAllTaints":true}}'
```
## Fase 4: configurazione di Mountpoint per Amazon S3
Nella maggior parte dei casi, è possibile configurare Mountpoint per Amazon S3 solo con un nome di bucket. Per istruzioni sulla configurazione di Mountpoint per Amazon S3, [consulta Configurazione di Mountpoint per](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md) Amazon S3 su. GitHub
## Fase 5: implementazione di un’applicazione esemplificativa
Puoi implementare il provisioning statico al driver su un bucket Amazon S3 esistente. [Per ulteriori informazioni, consulta Provisioning statico attivo.](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/examples/kubernetes/static_provisioning/README.md) GitHub
# Rimozione del componente aggiuntivo Amazon EKS di Mountpoint per Amazon S3
Sono disponibili due opzioni per rimuovere il [driver CSI di Mountpoint per Amazon S3](s3-csi.md).
+ **Mantenere il software aggiuntivo sul cluster** – Questa opzione rimuove la gestione di Amazon EKS su qualsiasi impostazione. Inoltre, rimuove la possibilità per Amazon EKS di notificare gli aggiornamenti e aggiornare automaticamente il componente aggiuntivo Amazon EKS dopo l'avvio di un aggiornamento. Tuttavia, mantiene il software aggiuntivo sul cluster. Questa opzione rende il componente aggiuntivo come autogestito anziché come un componente aggiuntivo Amazon EKS. Con questa opzione, non ci sono tempi di inattività per il componente aggiuntivo. I comandi in questa procedura utilizzano questa opzione.
+ **Rimuovere completamente il software aggiuntivo dal cluster** – Consigliamo di rimuovere il componente aggiuntivo Amazon EKS dal cluster solo se non ci sono risorse nel cluster che dipendono dallo stesso. Per eseguire questa operazione, elimina `--preserve` dal comando utilizzato in questa procedura.
Se al componente aggiuntivo è associato un account IAM, l’account IAM non è rimosso.
È possibile utilizzare i seguenti strumenti per rimuovere il componente aggiuntivo CSI per Amazon S3:
+ [eksctl](#eksctl_s3_remove_store_app_data)
+ [Console di gestione AWS](#console_s3_remove_store_app_data)
+ [CLI AWS](#awscli_s3_remove_store_app_data)
## eksctl
**Per rimuovere il componente aggiuntivo CSI per Amazon S3 utilizzando `eksctl`**
Sostituisci *my-cluster* con il nome del cluster ed eseguire il comando seguente.
```
eksctl delete addon --cluster my-cluster --name aws-mountpoint-s3-csi-driver --preserve
```
## Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**.
1. Scegli il nome del cluster per cui desideri rimuovere il componente aggiuntivo CSI per Amazon EBS.
1. Seleziona la scheda **Componenti aggiuntivi**.
1. Scegli **Driver CSI di Mountpoint per Amazon S3**
1. Scegli **Rimuovi**.
1. Nella finestra di dialogo di conferma **Rimuovi: aws-mountpoint-s3-csi-driver**, procedi come segue:
1. Se desideri che Amazon EKS interrompa la gestione delle impostazioni per il componente aggiuntivo, seleziona **Mantieni sul cluster**. Effettuare questa operazione se si desidera conservare il software aggiuntivo sul cluster. In questo modo sarà possibile gestire autonomamente tutte le impostazioni del componente aggiuntivo.
1. Specificare `aws-mountpoint-s3-csi-driver`.
1. Selezionare **Rimuovi**.
## CLI AWS
**Rimuovere il componente aggiuntivo CSI di Amazon S3 utilizzando AWS CLI**
Sostituisci *my-cluster* con il nome del cluster ed eseguire il comando seguente.
```
aws eks delete-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver --preserve
```
# Abilitare la funzionalità snapshot per i volumi CSI
La funzionalità snapshot consente di eseguire copie point-in-time dei dati. Affinché funzioni in Kubernetes, questa funzionalità richiede sia un driver CSI con supporto per snapshot (come il driver CSI di Amazon EBS), sia un controller di snapshot CSI. Il controller di snapshot è disponibile come componente aggiuntivo Amazon EKS o come installazione autogestita.
Di seguito sono elencati alcuni punti da considerare quando si utilizza il controller di snapshot CSI.
+ Il controller di snapshot deve essere installato insieme a un driver CSI con funzionalità di snapshot. Per istruzioni sull’installazione del driver CSI di Amazon EBS, consultare la pagina [Utilizzare il volume di archiviazione Kubernetes con Amazon EBS](ebs-csi.md).
+ Kubernetes non supporta snapshot di volumi serviti tramite migrazione CSI, come i volumi Amazon EBS che utilizzano una `StorageClass` con provisioner `kubernetes.io/aws-ebs`. I volumi devono essere creati con una `StorageClass` che fa riferimento al provisioner del driver CSI, `ebs.csi.aws.com`.
+ La modalità automatica Amazon EKS non include il controller di snapshot. La funzionalità di archiviazione della modalità automatica EKS è compatibile con il controller di snapshot.
Consigliamo di installare il controller di snapshot CSI attraverso il componente aggiuntivo gestito di Amazon EKS. Questo componente aggiuntivo include le definizioni di risorse personalizzate (Custom Resource Definitions, CRD) necessarie per creare e gestire snapshot su Amazon EKS. Per aggiungere un componente aggiuntivo di Amazon EKS al cluster, consulta [Creare un componente aggiuntivo Amazon EKS](creating-an-add-on.md). Per ulteriori informazioni sui componenti aggiuntivi, consulta [Componenti aggiuntivi Amazon EKS](eks-add-ons.md).
In alternativa, se si desidera un’installazione autogestita del controller di snapshot CSI, consultare la pagina [Usage](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage) nel `external-snapshotter` upstream Kubernetes su GitHub.