**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Usar armazenamento de dados de aplicações para o cluster
Você pode usar uma variedade de serviços de armazenamento da AWS com o Amazon EKS para atender às necessidades de armazenamento das aplicações. Por meio de uma variedade de drivers compatíveis com a AWS da interface de armazenamento de contêineres (CSI), você pode usar facilmente o Amazon EBS, Amazon S3, Amazon EFS, Amazon FSX e Amazon File Cache para as necessidades de armazenamento das aplicações em execução no Amazon EKS. Para gerenciar backups do cluster do Amazon EKS, consulte o [suporte do AWS Backup para Amazon EKS](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-supported-services.html#working-with-eks).
Este capítulo aborda as opções de armazenamento para clusters do Amazon EKS.
**Topics**
+ [Usar armazenamento de volumes do Kubernetes com o Amazon EBS](ebs-csi.md)
+ [Usar armazenamento elástico do sistema de arquivos com o Amazon EFS](efs-csi.md)
+ [Usar armazenamento de aplicações de alta performance com o Amazon FSx para Lustre](fsx-csi.md)
+ [Usar armazenamento de aplicações de alta performance com o FSx para NetApp ONTAP](fsx-ontap.md)
+ [Usar armazenamento de dados com o Amazon FSx para OpenZFS](fsx-openzfs-csi.md)
+ [Minimizar a latência com o Amazon File Cache](file-cache-csi.md)
+ [Acessar objetos do Amazon S3 com o driver CSI do Mountpoint para Amazon S3](s3-csi.md)
+ [Habilitar a funcionalidade de snapshot para volumes CSI](csi-snapshot-controller.md)
# Usar armazenamento de volumes do Kubernetes com o Amazon EBS
**nota**
**Novo:** o Modo Automático do Amazon EKS automatiza tarefas de rotina para armazenamento em blocos. Saiba como [Implantar uma workload com estado de exemplo no Modo Automático do EKS](sample-storage-workload.md).
O [driver CSI (Container Storage Interface) do Amazon Elastic Block Store (Amazon EBS)](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/) gerencia o ciclo de vida dos volumes do Amazon EBS como armazenamento para os volumes do Kubernetes que você cria. O driver da CSI do Amazon EBS cria volumes do Amazon EBS para estes tipos de volumes do Kubernetes: [volumes temporários](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) e [volumes persistentes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) genéricos.
## Considerações
+ Você não precisa instalar o Controlador da CSI do Amazon EBS nos clusters do Modo Automático do EKS.
+ Você não pode montar volumes do Amazon EBS em pods do Fargate.
+ Você pode executar o controlador da CSI do Amazon EBS em nós do Fargate, mas o `DaemonSet` do nó da CSI do Amazon EBS só pode ser executado em instâncias do Amazon EC2.
+ Os volumes do Amazon EBS e o driver CSI do Amazon EBS não são compatíveis com o Amazon EKS Hybrid Nodes.
+ Suporte será fornecido para a versão complementar mais recente e para uma versão anterior. As correções de bugs ou vulnerabilidades encontradas na versão mais recente serão incorporadas à versão anterior como uma nova versão secundária.
+ O Modo Automático do EKS exige que as classes de armazenamento usem `ebs.csi.eks.amazonaws.com` como provisionador. O driver CSI padrão do Amazon EBS (`ebs.csi.aws.com`) gerencia seus próprios volumes separadamente. Para usar volumes existentes com o Modo Automático do EKS, migre-os usando snapshots de volume para uma classe de armazenamento que use o provisionador do Modo Automático.
**Importante**
Para utilizar a funcionalidade de snapshot do driver da CSI do Amazon EBS, primeiro é necessário instalar o controlador de snapshots da CSI. Para obter mais informações, consulte [Habilitar a funcionalidade de snapshot para volumes CSI](csi-snapshot-controller.md).
## Pré-requisitos
+ Um cluster existente. Para ver a versão necessária da plataforma, execute o comando a seguir.
```
aws eks describe-addon-versions --addon-name aws-ebs-csi-driver
```
+ O driver CSI do EBS precisa de permissões do AWS IAM.
+ A AWS sugere o uso de Identidades de Pod do EKS. Para obter mais informações, consulte [Visão geral da configuração do EKS Pod Identities](pod-identities.md#pod-id-setup-overview).
+ Para obter informações sobre perfis do IAM para contas de serviço, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
## Etapa 1: criar um perfil do IAM
O plugin CSI do Amazon EBS requer permissões do IAM para fazer chamadas para APIs da AWS em seu nome. Se você não concluir essas etapas, a tentativa de instalar o complemento e de executar `kubectl describe pvc` mostrarão `failed to provision volume with StorageClass` junto com erro `could not create volume in EC2: UnauthorizedOperation`. Para obter mais informações, consulte [Configurar permissão de driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#set-up-driver-permissions) no GitHub.
**nota**
Os pods terão acesso às permissões atribuídas ao perfil do IAM, a menos que você bloqueie o acesso ao IMDS. Para obter mais informações, consulte [Proteger os clusters do Amazon EKS com as práticas recomendadas](security-best-practices.md).
O procedimento a seguir mostra como criar um perfil do IAM e associar a política gerenciada da AWS a ele. Para implementar esse procedimento, você pode usar uma das seguintes ferramentas:
+ [`eksctl`](#eksctl_store_app_data)
+ [Console de gerenciamento da AWS](#console_store_app_data)
+ [AWS CLI](#awscli_store_app_data)
**nota**
É possível criar uma política autogerenciada com permissões de escopo reduzido. Analise a política [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 crie uma política do IAM personalizada com permissões reduzidas.
**nota**
As etapas específicas desse procedimento foram escritas para usar o driver como um complemento do Amazon EKS. Diferentes etapas para usar o driver como um complemento autogerenciado. Para obter mais informações, consulte [Set up driver permissions](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#set-up-driver-permissions) no GitHub.
### `eksctl`
1. Criar um perfil do IAM e associar uma política. AWS mantém uma política AWS gerenciada ou você pode criar sua própria política personalizada. É possível criar um perfil do IAM e anexar a política gerenciada AWS com o seguinte comando. Substitua *my-cluster* pelo nome do cluster. O comando implementa uma pilha do AWS CloudFormation que cria um perfil do IAM e anexa a política do IAM a ela.
```
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. Você poderá pular esta etapa se não usar uma [chave do KMS](https://aws.amazon.com/kms/) personalizada. Se você usar uma para criptografia nos volumes do Amazon EBS, personalize o perfil do IAM conforme necessário. Por exemplo, faça o seguinte:
1. Copie e cole o código a seguir em um novo arquivo `kms-key-for-encryption-on-ebs.json`. Substitua *custom-key-arn* pelo [ARN da chave do KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personalizada.
```
{
"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. Crie a política. É possível alterar *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* para um nome diferente. Porém, se fizer isso, não se esqueça de alterá-lo também em etapas posteriores.
```
aws iam create-policy \
--policy-name KMS_Key_For_Encryption_On_EBS_Policy \
--policy-document file://kms-key-for-encryption-on-ebs.json
```
1. Anexe a política do IAM necessária ao perfil com o comando a seguir. Substitua *111122223333* pelo ID da sua conta.
```
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 de gerenciamento da AWS
1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
1. No painel de navegação à esquerda, escolha **Funções**.
1. Na página **Perfis**, selecione **Criar perfil**.
1. Na página **Select trusted entity** (Selecionar entidade confiável), faça o seguinte:
1. Na seção **Tipo de entidade confiável**, escolha **Identidade da Web**.
1. Para **Identity provider** (Provedor de identidade), escolha **OpenID Connect provider URL** (URL do provedor OpenID Connect) para o seu cluster (conforme mostrado na guia **Overview** (Visão geral) do Amazon EKS).
1. Em **Público**, escolha `sts.amazonaws.com`.
1. Escolha **Próximo**.
1. Na página **Add permissions** (Adicionar permissões), faça o seguinte:
1. Na caixa **Filtrar políticas** insira `AmazonEBSCSIDriverPolicy`.
1. Marque a caixa de seleção à esquerda do `AmazonEBSCSIDriverPolicy` retornado na pesquisa.
1. Escolha **Próximo**.
1. Na página **Nomear, revisar e criar**, faça o seguinte:
1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como *AmazonEKS\$1EBS\$1CSI\$1DriverRole*.
1. Em **Adicionar tags (Opcional)**, adicione metadados ao perfil anexando tags como pares chave-valor. Para obter mais informações sobre o uso de tags no IAM, consulte [Marcar recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) no *Guia do usuário do IAM*.
1. Selecione **Criar perfil**.
1. Depois que o perfil for criado, escolha-o no console para abri-lo para edição.
1. Escolha a guia **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança).
1. Encontre a linha semelhante à seguinte:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
```
Adicione uma vírgula ao final da linha anterior e depois adicione a linha a seguir após a anterior. Substitua *region-code* pela região da AWS em que seu cluster se encontra. Substitua *EXAMPLED539D4633E53DE1B71EXAMPLE* pelo ID do provedor OIDC do cluster.
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:ebs-csi-controller-sa"
```
1. Escolha **Atualizar política** para concluir.
1. Se você usar uma [chave do KMS](https://aws.amazon.com/kms/) personalizada para criptografia em seus volumes do Amazon EBS, personalize o perfil do IAM conforme necessário. Por exemplo, faça o seguinte:
1. No painel de navegação à esquerda, escolha **Políticas**.
1. Na página **Policies** (Políticas), escolha **Create Policy** (Criar política).
1. Na página **Criar política**, escolha a guia **JSON**.
1. Copie e cole o código a seguir no editor, substituindo *custom-key-arn* pelo [ARN da chave KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personalizada.
```
{
"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. Escolha **Próximo: tags**.
1. Na página **Add tags (optional)** (Adicionar etiquetas - opcional), escolha **Next: Review** (Próximo: revisar).
1. Em **Nome**, insira um nome exclusivo para sua política (por exemplo, *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy*).
1. Escolha **Criar política**.
1. No painel de navegação à esquerda, selecione **Perfis**.
1. Escolha ***AmazonEKS\$1EBS\$1CSI\$1DriverRole*** no console para abri-lo para edição.
1. Na lista suspensa **Add permissions** (Adicionar permissões), escolha **Attach policies** (Anexar políticas).
1. Na caixa **Políticas de filtro**, insira *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy*.
1. Marque a caixa de seleção à esquerda da *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* retornada na pesquisa.
1. Escolha **Anexar políticas**.
### AWS CLI
1. Exiba a URL do provedor OIDC do cluster. Substitua *my-cluster* pelo nome do cluster. Se o resultado do comando for `None`, revise os **Pré-requisitos**.
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
Veja um exemplo de saída abaixo.
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
1. Crie o perfil do IAM, concedendo a ação `AssumeRoleWithWebIdentity`.
1. Copie o conteúdo a seguir em um arquivo chamado `aws-ebs-csi-driver-trust-policy.json`. Substitua *111122223333* pelo ID da sua conta. Substitua *EXAMPLED539D4633E53DE1B71EXAMPLE* e *region-code* pelos valores retornados na etapa anterior.
```
{
"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. Crie a função. É possível alterar *AmazonEKS\$1EBS\$1CSI\$1DriverRole* para um nome diferente. Se você alterá-lo, não se esqueça de alterá-lo em etapas superiores.
```
aws iam create-role \
--role-name AmazonEKS_EBS_CSI_DriverRole \
--assume-role-policy-document file://"aws-ebs-csi-driver-trust-policy.json"
```
1. Associar uma política. AWS mantém uma política AWS gerenciada ou você pode criar sua própria política personalizada. Anexe a política gerenciada pela AWS ao perfil com o comando a seguir.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--role-name AmazonEKS_EBS_CSI_DriverRole
```
1. Se você usar uma [chave do KMS](https://aws.amazon.com/kms/) personalizada para criptografia em seus volumes do Amazon EBS, personalize o perfil do IAM conforme necessário. Por exemplo, faça o seguinte:
1. Copie e cole o código a seguir em um novo arquivo `kms-key-for-encryption-on-ebs.json`. Substitua *custom-key-arn* pelo [ARN da chave do KMS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-key) personalizada.
```
{
"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. Crie a política. É possível alterar *KMS\$1Key\$1For\$1Encryption\$1On\$1EBS\$1Policy* para um nome diferente. Porém, se fizer isso, não se esqueça de alterá-lo também em etapas posteriores.
```
aws iam create-policy \
--policy-name KMS_Key_For_Encryption_On_EBS_Policy \
--policy-document file://kms-key-for-encryption-on-ebs.json
```
1. Anexe a política do IAM necessária ao perfil com o comando a seguir. Substitua *111122223333* pelo ID da sua conta.
```
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
```
Agora que você criou o perfil do IAM do driver de CSI do Amazon EBS, poderá avançar para a próxima seção. Quando você implanta o complemento com esse perfil do IAM, ele cria e é configurado para usar uma conta de serviço chamada `ebs-csi-controller-sa`. A conta de serviço está vinculada a um `clusterrole` do Kubernetes que recebe as permissões necessárias do Kubernetes.
## Etapa 2: obter o driver de CSI do Amazon EBS
Recomendamos que você instale o driver de CSI do Amazon EBS por meio do complemento do Amazon EKS para reforçar a segurança e reduzir o volume do trabalho. Para adicionar um complemento do Amazon EKS ao cluster, consulte [Criar um complemento do Amazon EKS](creating-an-add-on.md). Para obter mais informações sobre complementos, consulte [Complementos do Amazon EKS](eks-add-ons.md).
**Importante**
Antes de adicionar o driver do Amazon EBS como um complemento do Amazon EKS, verifique se você não tem uma versão autogerenciada do driver instalada no seu cluster. Em caso afirmativo, consulte [Uninstalling a self-managed Amazon EBS CSI driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md#uninstalling-the-ebs-csi-driver) no GitHub.
**nota**
Por padrão, o perfil de RBAC usado pela CSI do EBS tem permissões para realizar mutações em nós a fim de fornecer suporte à funcionalidade de remoção de taints. Por conta de limitações do RBAC do Kubernetes, isso também possibilita a modificação de qualquer outro nó presente no cluster. O chart do Helm conta com um parâmetro (`node.serviceAccount.disableMutation`) que desabilita permissões de RBAC para modificar nós, vinculadas ao perfil da conta de serviço ebs-csi-node. Caso habilitado, as funcionalidades do driver, por exemplo, a remoção de taints, deixarão de operar.
Como alternativa, se quiser uma instalação autogerenciada do driver CSI do Amazon EBS, consulte [Installation](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) no GitHub.
## Etapa 3: implantar uma aplicação de exemplo
Você pode implantar toda uma variedade de aplicações de exemplo e modificá-las conforme necessário. Para obter mais informações, consulte [Kubernetes Examples](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes) no GitHub.
# Usar armazenamento elástico do sistema de arquivos com o Amazon EFS
O [Amazon Elastic File System](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) (Amazon EFS) fornece armazenamento de arquivos com tecnologia sem servidor e totalmente elástico para que você possa compartilhar dados de arquivos sem provisionar ou gerenciar a capacidade e a performance do armazenamento. O [driver da Container Storage Interface (CSI) do Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver) fornece uma interface CSI que permite que os clusters do Kubernetes executados na AWS gerenciem o ciclo de vida dos sistemas de arquivos do Amazon EFS. Este tópico mostra como implantar o driver da CSI do Amazon EFS no cluster do Amazon EKS.
## Considerações
+ O driver da CSI do Amazon EFS não é compatível com imagens de contêiner baseadas no Windows.
+ Você não pode usar o [provisionamento dinâmico](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) de volumes persistentes com nós do Fargate, mas pode usar o [provisionamento estático](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md).
+ [O provisionamento dinâmico](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) requer a versão [1.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v12) ou superior do driver. Você pode usar o [ provisionamento estático](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/static_provisioning/README.md) para volumes persistentes usando a versão `1.1` do driver em qualquer versão de cluster do Amazon EKS compatível (consulte [Versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)).
+ A versão [1.3.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v132) ou superior deste driver é compatível com a arquitetura Arm64, inclusive instâncias baseadas no Graviton do Amazon EC2.
+ A versão [1.4.2](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-1.x.md#v142) ou posterior desse driver é compatível com o uso de FIPS para montagem de sistemas de arquivos.
+ Anote as cotas de recursos do Amazon EFS. Por exemplo, há uma cota de 1000 pontos de acesso que podem ser criados para cada sistema de arquivos do Amazon EFS. Para acessar mais informações, consulte [Cotas de recursos do Amazon EFS que você não pode alterar](https://docs.aws.amazon.com/efs/latest/ug/limits.html#limits-efs-resources-per-account-per-region).
+ A partir da versão [2.0.0](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/CHANGELOG-2.x.md#v200), esse driver deixou de usar `stunnel` e passou a usar `efs-proxy` para conexões TLS. Quando `efs-proxy` é usado, ele abre um número de threads igual a um mais o número de núcleos do nó em que está sendo executado.
+ O driver CSI do Amazon EFS não é compatível com o Amazon EKS Hybrid Nodes.
## Pré-requisitos
+ O driver CSI do Amazon EFS precisa de permissões do AWS Identity and Access Management (IAM).
+ A AWS sugere o uso de Identidades de Pod do EKS. Para obter mais informações, consulte [Visão geral da configuração do EKS Pod Identities](pod-identities.md#pod-id-setup-overview).
+ Para obter informações sobre os perfis do IAM para contas de serviço e a configuração de um provedor OpenID Connect (OIDC) do IAM para o cluster, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
**nota**
Um pod em execução no Fargate automaticamente monta um sistema de arquivos do Amazon EFS sem precisar das etapas de instalação manual do driver.
## Etapa 1: criar um perfil do IAM
O driver da CSI do Amazon EFS exige permissões do IAM para interagir com seu sistema de arquivos. Crie um perfil do IAM de cluster e associe a política gerenciada do AWS a ele. Para implementar esse procedimento, você pode usar uma das seguintes ferramentas:
+ [`eksctl`](#eksctl_efs_store_app_data)
+ [Console de gerenciamento da AWS](#console_efs_store_app_data)
+ [AWS CLI](#awscli_efs_store_app_data)
**nota**
As etapas específicas desse procedimento foram escritas para usar o driver como um complemento do Amazon EKS. Para obter detalhes sobre instalações autogerenciadas, consulte [Set up driver permission](https://github.com/kubernetes-sigs/aws-efs-csi-driver#set-up-driver-permission) no GitHub.
### `eksctl`
#### Se estiver usando Identidades de Pods
Execute os comandos a seguir para criar um perfil do IAM e a Identidade de Pods com o `eksctl`. Substitua `my-cluster` pelo nome do cluster. É possível substituir `AmazonEKS_EFS_CSI_DriverRole` por um nome diferente.
```
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 estiver usando perfis do IAM para contas de serviço
Execute os seguintes comandos para criar um perfil IAM com o `eksctl`. Substitua `my-cluster` pelo nome do cluster. É possível substituir `AmazonEKS_EFS_CSI_DriverRole` por um nome diferente.
```
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 de gerenciamento da AWS
Execute o seguinte para criar um perfil IAM com Console de gerenciamento da AWS.
1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
1. No painel de navegação à esquerda, escolha **Funções**.
1. Na página **Perfis**, selecione **Criar perfil**.
1. Na página **Selecionar entidade confiável**, faça o seguinte:
1. Se estiver usando Identidade de Pods do EKS:
1. Na seção **Tipo de entidade confiável**), escolha **Service da AWS**.
1. No menu suspenso **Serviço ou caso de uso**, escolha **EKS**.
1. Na seção **Caso de uso**, escolha **EKS - Identidade de Pods**.
1. Escolha **Próximo**.
1. Se estiver usando perfis do IAM para contas de serviço:
1. Na seção **Tipo de entidade confiável**, escolha **Identidade da Web**.
1. Para **Identity provider** (Provedor de identidade), escolha **OpenID Connect provider URL** (URL do provedor OpenID Connect) para o seu cluster (conforme mostrado na guia **Overview** (Visão geral) do Amazon EKS).
1. Em **Público**, escolha `sts.amazonaws.com`.
1. Escolha **Próximo**.
1. Na página **Add permissions** (Adicionar permissões), faça o seguinte:
1. Na caixa **Filtrar políticas** insira `AmazonEFSCSIDriverPolicy`.
1. Marque a caixa de seleção à esquerda do `AmazonEFSCSIDriverPolicy` retornado na pesquisa.
1. Escolha **Próximo**.
1. Na página **Name, review, and create** (Nomear, revisar e criar), faça o seguinte:
1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como `AmazonEKS_EFS_CSI_DriverRole`.
1. Em **Adicionar tags (Opcional)**, adicione metadados ao perfil anexando tags como pares chave-valor. Para obter mais informações sobre o uso de tags no IAM, consulte [Marcar recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) no *Guia do usuário do IAM*.
1. Selecione **Criar perfil**.
1. Depois que o perfil for criado:
1. Se estiver usando Identidade de Pods do EKS:
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação esquerdo, selecione **Clusters** e depois o nome do cluster para o qual você deseja configurar a associação a Identidade de Pods do EKS.
1. Escolha a guia **Acesso**.
1. Em **Associações da Identidade de Pods**, escolha **Criar**.
1. Escolha o menu suspenso **Perfil do IAM** e selecione o perfil que acabou de criar.
1. Escolha o campo **Namespace Kubernetes** e a entrada `kube-system`.
1. Escolha o campo **Conta de serviço do Kubernetes** e a entrada `efs-csi-controller-sa`.
1. Escolha **Criar**.
1. Para obter mais informações sobre a criação de associações da Identidade de Pods, consulte [Criar uma associação de identidade de pod (console do AWS )](pod-id-association.md#pod-id-association-create).
1. Se estiver usando perfis do IAM para contas de serviço:
1. Escolha o perfil para abri-lo para edição.
1. Escolha a guia **Relacionamentos de confiança** e, em seguida, escolha **Editar política de confiança**.
1. Encontre a linha semelhante à seguinte:
```
"oidc.eks.region-code.amazonaws.com/id/:aud": "sts.amazonaws.com"
```
Adicione a seguinte linha acima da linha anterior. Substitua `` pela região da AWS em que seu cluster está localizado. Substitua `` pelo ID do provedor OIDC do cluster.
```
"oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount:kube-system:efs-csi-*",
```
1. Modifique o operador `Condition` de `"StringEquals"` para `"StringLike"`.
1. Escolha **Atualizar política** para concluir.
### AWS CLI
Execute os seguintes comandos para criar um perfil IAM com a AWS CLI.
#### Se estiver usando Identidades de Pods
1. Crie o perfil do IAM que concede as ações `AssumeRole` e `TagSession` ao serviço `pods.eks.amazonaws.com`.
1. Copie o conteúdo a seguir em um arquivo denominado `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. Crie a função. Substitua `my-cluster` pelo nome do cluster. É possível substituir `AmazonEKS_EFS_CSI_DriverRole` por um nome diferente.
```
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. Anexe a política gerenciada pela AWS necessária ao perfil com o comando a seguir.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--role-name $role_name
```
1. Execute o comando a seguir para criar a associação da Identidade de Pods. Substitua ` arn:aws:iam::<111122223333>:role/my-role` pelo perfil criado nas etapas anteriores.
```
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. Para obter mais informações sobre a criação de associações da Identidade de Pods, consulte [Criar uma associação de identidade de pod (console do AWS )](pod-id-association.md#pod-id-association-create).
#### Se estiver usando perfis do IAM para contas de serviço
1. Exiba a URL do provedor OIDC do cluster. Substitua `my-cluster` pelo nome do cluster. É possível substituir `AmazonEKS_EFS_CSI_DriverRole` por um nome diferente.
```
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
```
Veja abaixo um exemplo de saída.
```
https://oidc.eks..amazonaws.com/id/
```
Se o resultado do comando for `None`, revise os **Pré-requisitos**.
1. Crie um perfil do IAM que conceda a ação `AssumeRoleWithWebIdentity`.
1. Copie o conteúdo a seguir em um arquivo denominado `aws-efs-csi-driver-trust-policy.json`. Substitua `<111122223333>` pelo ID da sua conta. Substitua `` e `` pelos valores retornados na etapa anterior.
```
{
"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. Crie a função.
```
aws iam create-role \
--role-name $role_name \
--assume-role-policy-document file://"aws-efs-csi-driver-trust-policy.json"
```
1. Anexe a política gerenciada pela AWS necessária ao perfil com o comando a seguir.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonEFSCSIDriverPolicy \
--role-name $role_name
```
## Etapa 2: obter o driver de CSI do Amazon EFS
Recomendamos que você instale o driver da CSI do Amazon EFS por meio do complemento Amazon EKS. Para adicionar um complemento do Amazon EKS ao cluster, consulte [Criar um complemento do Amazon EKS](creating-an-add-on.md). Para obter mais informações sobre complementos, consulte [Complementos do Amazon EKS](eks-add-ons.md). Se você não conseguir usar o complemento do Amazon EKS, recomendamos que você envie um problema sobre o motivo pelo qual não pode usar o [repositório GitHub para roteiro de contêineres](https://github.com/aws/containers-roadmap/issues).
**Importante**
Antes de adicionar o driver do Amazon EFS como um complemento do Amazon EKS, verifique se você não tem uma versão autogerenciada do driver instalada no seu cluster. Em caso afirmativo, consulte [Uninstalling the Amazon EFS CSI Driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#uninstalling-the-amazon-efs-csi-driver) no GitHub.
Como alternativa, se quiser uma instalação autogerenciada do driver CSI do Amazon EFS, consulte [Installation](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#installation) no GitHub.
## Etapa 3: criar um sistema de arquivos do Amazon EFS
Para criar um sistema de arquivos do Amazon EFS, consulte [Criar um sistema de arquivos do Amazon EFS para o Amazon EKS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/efs-create-filesystem.md) no GitHub.
## Etapa 4: implantar uma aplicação de exemplo
Você pode implantar toda uma variedade de aplicações de exemplo e modificá-las conforme necessário. Para obter mais informações, consulte [Exemplos](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md#examples) no GitHub.
# Usar armazenamento de aplicações de alta performance com o Amazon FSx para Lustre
O [driver da Container Storage Interface (CSI) do Amazon FSx for Lustre](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) fornece uma interface da CSI que permite que os clusters do Amazon EKS gerenciem o ciclo de vida dos sistemas de arquivos do Amazon FSx for Lustre. Para obter mais informações, consulte o [Guia do usuário do Amazon FSx para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html).
Para obter detalhes sobre como implantar o driver de CSI do Amazon FSx para Lustre no cluster do Amazon EKS e verificar se ele funciona, consulte [Implantar o driver do FSx para Lustre](fsx-csi-create.md).
# Implantar o driver do FSx para Lustre
Este tópico mostra como implantar o [driver de CSI do FSx para Lustre](fsx-csi.md) no cluster do Amazon EKS e verificar se ele funciona. Recomendamos o uso da versão mais recente do driver. Para ver as versões disponíveis, consulte [CSI Specification Compatibility Matrix](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/README.md#csi-specification-compatibility-matrix) (Matriz de compatibilidade de especificações de CSI) no GitHub.
**nota**
O driver não é compatível com o Fargate ou o Amazon EKS Hybrid Nodes.
Para obter descrições detalhadas dos parâmetros disponíveis e exemplos completos que demonstram os recursos do driver, consulte o projeto [FSx for Lustre Container Storage Interface (CSI) driver](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) no GitHub.
## Pré-requisitos
+ Um cluster existente.
+ O complemento do driver CSI do Amazon FSx para o EKS requer o agente da Identidade de Pods do EKS para autenticação. Sem esse componente, o complemento falhará com o erro `Amazon EKS Pod Identity agent is not installed in the cluster`, impedindo operações de volume. Instale o atendente da Identidade de Pods antes ou depois de implantar o complemento do driver CSI do FSx. Para obter mais informações, consulte [Configurar o atndente do Identidade de Pods do Amazon EKS](pod-id-agent-setup.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ Versão `0.215.0` ou posterior da ferramenta de linha de comando da `eksctl` instalada no seu dispositivo ou AWS CloudShell. Para instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
## Etapa 1: criar um perfil do IAM
O plug-in do CSI para Amazon FSx requer permissões do IAM para fazer chamadas para APIs da AWS em seu nome.
**nota**
Os pods terão acesso às permissões atribuídas ao perfil do IAM, a menos que você bloqueie o acesso ao IMDS. Para obter mais informações, consulte [Proteger os clusters do Amazon EKS com as práticas recomendadas](security-best-practices.md).
O procedimento a seguir mostra como criar um perfil do IAM e associar a política gerenciada da AWS a ele.
1. Crie um perfil do IAM e anexe a política do IAM gerenciada pela AWS com o comando a seguir. Substitua `my-cluster` pelo nome do cluster que você deseja usar. O comando implementa uma pilha do AWS CloudFormation que cria um perfil do IAM e anexa a política do IAM a ela.
```
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
```
Você verá várias linhas de resultado à medida que a conta de serviço é criada. As últimas linhas de saída são semelhantes às seguintes:
```
[ℹ] 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"
```
Observe o nome da pilha do AWS CloudFormation que foi implantada. No resultado do exemplo anterior, a pilha é denominada `eksctl-my-cluster-addon-iamserviceaccount-kube-system-fsx-csi-controller-sa`.
Agora que criou o perfil do IAM do driver CSI do Amazon FSx, você poderá avançar para a próxima seção. Quando você implanta o complemento com esse perfil do IAM, ele cria e é configurado para usar uma conta de serviço chamada `fsx-csi-controller-sa`. A conta de serviço está vinculada a um `clusterrole` do Kubernetes que recebe as permissões necessárias do Kubernetes.
## Etapa 2: instalar o driver CSI do Amazon FSx
Recomendamos que você instale o driver CSI do Amazon FSx usando o complemento do Amazon EKS para reforçar a segurança e reduzir o volume do trabalho. Para adicionar um complemento do Amazon EKS ao cluster, consulte [Criar um complemento do Amazon EKS](creating-an-add-on.md). Para obter mais informações sobre complementos, consulte [Complementos do Amazon EKS](eks-add-ons.md).
**Importante**
Instalações preexistentes do driver CSI do Amazon FSx no cluster podem causar falhas na instalação do complemento. Quando você tentar instalar a versão do complemento do Amazon EKS quando houver um driver CSI do FSx que não seja para o EKS, a instalação falhará devido a conflitos de recursos. Use o sinalizador `OVERWRITE` durante a instalação para resolver esse problema.
```
aws eks create-addon --addon-name aws-fsx-csi-driver --cluster-name my-cluster --resolve-conflicts OVERWRITE
```
Como alternativa, se quiser uma instalação autogerenciada do driver CSI do Amazon FSx, consulte [Installation](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/blob/master/docs/install.md) no GitHub.
## Etapa 3: implantar uma classe de armazenamento, uma solicitação de volume persistente e uma aplicação de exemplo
Este procedimento usa o repositório GitHub do [driver Container Storage Interface (CSI) do FSx para Lustre](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) para consumir um volume provisionado dinamicamente do Amazon FSx para Lustre.
1. Observe o grupo de segurança do seu cluster. Você pode vê-lo em Console de gerenciamento da AWS na seção **Networking** ou usando o seguinte comando da AWS CLI. Substitua `my-cluster` pelo nome do cluster que você deseja usar.
```
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
1. Crie um grupo de segurança para seu sistema de arquivos Amazon FSx conforme os critérios mostrados em [Grupos de segurança de Amazon VPC](https://docs.aws.amazon.com/fsx/latest/LustreGuide/limit-access-security-groups.html#fsx-vpc-security-groups), no Guia do usuário do Amazon FSx para Lustre. Para a **VPC**, selecione a VPC do seu cluster, conforme mostrado na seção **Networking** (Redes). Para os “grupos de segurança associados aos seus clientes Lustre”, utilize o grupo de segurança do seu cluster. É possível deixar as regras de saída sozinhas para permitir **Todo o tráfego**.
1. Baixe o manifesto da classe de armazenamento com o seguinte comando:
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
```
1. Edite a seção de parâmetros do arquivo `storageclass.yaml`. Substitua cada valor de exemplo por seus próprios valores.
```
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` ** – o ID de da sub-rede em que o sistema de arquivos do Amazon FSx para Lustre deve ser criado. O Amazon FSx for Lustre não conta com suporte em todas as zonas de disponibilidade. Abra o console do Amazon FSx for Lustre em https://console.aws.amazon.com/fsx/ para confirmar se a sub-rede que você deseja usar está em uma zona de disponibilidade compatível. A sub-rede pode incluir os nós ou pode ser uma sub-rede ou uma VPC diferente:
+ É possível verificar as sub-redes do nó no Console de gerenciamento da AWS, selecionando o grupo de nós na seção **Compute** (Computação).
+ Se a sub-rede especificada não for a mesma sub-rede em que os nós estiverem localizados, as VPCs deverão estar [conectadas](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/amazon-vpc-to-amazon-vpc-connectivity-options.html), e você deverá garantir que as portas necessárias estejam abertas nos grupos de segurança.
+ ** `securityGroupIds` ** – o ID do grupo de segurança criado para o sistema de arquivos.
+ ** `deploymentType` (opcional)**: o tipo de implantação do sistema de arquivos. Os valores válidos são `SCRATCH_1`, `SCRATCH_2`, `PERSISTENT_1` e `PERSISTENT_2`. Para obter mais informações sobre os tipos de implantação, consulte [Create your Amazon FSx for Lustre file system](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step1.html) (Criar o sistema de arquivos do Amazon FSx for Lustre).
+ **outros parâmetros (opcionais)**: para obter informações sobre outros parâmetros, consulte [Editar StorageClass](https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning#edit-storageclass), no GitHub.
1. Crie o manifesto da classe de armazenamento.
```
kubectl apply -f storageclass.yaml
```
Veja um exemplo de saída abaixo.
```
storageclass.storage.k8s.io/fsx-sc created
```
1. Faça download do manifesto de declaração de volume persistente.
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/claim.yaml
```
1. (Opcional) Edite o arquivo `claim.yaml`. Altere `1200Gi` para um dos seguintes valores de incremento com base nos requisitos de armazenamento e no `deploymentType` selecionado em uma etapa anterior.
```
storage: 1200Gi
```
+ `SCRATCH_2` e `PERSISTENT` a `1.2 TiB`, `2.4 TiB` ou incrementos de 2,4 TiB, com mais de 2,4 TiB.
+ `SCRATCH_1` – `1.2 TiB`, `2.4 TiB`, `3.6 TiB`, a , , ou incrementos de 3,6 TiB, com mais de 3,6 TiB.
1. Crie a declaração de volume persistente.
```
kubectl apply -f claim.yaml
```
Veja um exemplo de saída abaixo.
```
persistentvolumeclaim/fsx-claim created
```
1. Confirme se o sistema de arquivos está provisionado.
```
kubectl describe pvc
```
Veja um exemplo de saída abaixo.
```
Name: fsx-claim
Namespace: default
StorageClass: fsx-sc
Status: Bound
[...]
```
**nota**
O `Status` pode ser exibido como `Pending` por 5 a 10 minutos, antes de mudar para `Bound`. Não prossiga para a próxima etapa até o `Status` for `Bound`. Se `Status` mostrar `Pending` por mais de 10 minutos, use mensagens de aviso em `Events` como referência para resolver problemas.
1. Implante a aplicação de exemplo.
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-fsx-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
```
1. Verifique se a aplicação de exemplo está em execução.
```
kubectl get pods
```
Veja um exemplo de saída abaixo.
```
NAME READY STATUS RESTARTS AGE
fsx-app 1/1 Running 0 8s
```
1. Verifique se o sistema de arquivos está montado corretamente pela aplicação.
```
kubectl exec -ti fsx-app -- df -h
```
Veja um exemplo de saída abaixo.
```
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. Verifique se os dados foram gravados no sistema de arquivos do FSx for Lustre pela aplicação de exemplo.
```
kubectl exec -it fsx-app -- ls /data
```
Veja um exemplo de saída abaixo.
```
out.txt
```
Essa saída de exemplo indica que a aplicação de amostra gravou com êxito o arquivo `out.txt` no sistema de arquivos.
**nota**
Antes de excluir o cluster, não esqueça de excluir o sistema de arquivos do FSx for Lustre. Para obter mais informações, consulte [Limpar os recursos](https://docs.aws.amazon.com/fsx/latest/LustreGuide/getting-started-step4.html) no *Guia do usuário do FSx for Lustre*.
## Ajuste de performance para o FSx para Lustre
Ao usar o FSx para Lustre com o Amazon EKS, você pode otimizar a performance aplicando ajustes do Lustre durante a inicialização de nós. A abordagem recomendada é usar os dados do usuário do modelo de inicialização para garantir uma configuração consistente em todos os nós.
Esses ajustes incluem:
+ Otimizações de rede e RPC
+ Gerenciamento do módulo Lustre
+ Ajustes da LRU (unidade de bloqueio de recursos)
+ Configurações de controle de cache do cliente
+ Controles de RPC para OST e MDC
Para obter instruções detalhadas sobre a implementação desses ajustes de performance:
+ Para otimizar a performance de nós padrão (não EFA), consulte [Otimizar a performance do Amazon FSx para Lustre em nós (não EFA)](fsx-csi-tuning-non-efa.md) para obter um script completo que pode ser adicionado aos dados do usuário do modelo de inicialização.
+ Para otimizar a performance de nós habilitados para o EFA, consulte [Otimizar a performance do Amazon FSx para Lustre em nós (EFA)](fsx-csi-tuning-efa.md).
# Otimizar a performance do Amazon FSx para Lustre em nós (EFA)
Este tópico descreve como configurar o ajuste do Elastic Fabric Adapter (EFA) com o Amazon EKS e o Amazon FSx para Lustre.
**nota**
Para obter informações sobre como criar e implantar o driver CSI do FSx para Lustre, consulte [Implantar o driver do FSx para Lustre](fsx-csi-create.md).
Para otimizar os nós padrão sem o EFA, consulte [Otimizar a performance do Amazon FSx para Lustre em nós (não EFA)](fsx-csi-tuning-non-efa.md).
## Etapa 1. Criar um cluster do EKS
Crie um cluster usando o arquivo de configuração fornecido:
```
# Create cluster using efa-cluster.yaml
eksctl create cluster -f efa-cluster.yaml
```
Exemplo `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)"
```
## Etapa 2. Criar grupos de nós
Crie um grupo de nós habilitado para EFA:
```
# Create node group using efa-ng.yaml
eksctl create nodegroup -f efa-ng.yaml
```
**Importante**
=== Ajuste esses valores para seu ambiente na seção `# 5. Mount FSx filesystem`.
```
FSX_DNS="" # Needs to be adjusted.
MOUNT_NAME="" # Needs to be adjusted.
MOUNT_POINT="" # Needs to be adjusted.
```
===
Exemplo `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."
```
## (Opcional) Etapa 3. Verificar a configuração do EFA
SSH no nó:
```
# Get instance ID from EKS console or {aws} CLI
ssh -i /path/to/your-key.pem ec2-user@
```
Verifique a configuração do EFA:
```
sudo lnetctl net show
```
Verifique os logs de configuração:
```
sudo cat /var/log/cloud-init-output.log
```
Aqui está um exemplo de saída esperada para `lnetctl net show`:
```
net:
- net type: tcp
...
- net type: efa
local NI(s):
- nid: xxx.xxx.xxx.xxx@efa
status: up
```
## Implantações de exemplo
### a. Crie claim.yaml
```
#claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: fsx-claim-efa
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 4800Gi
volumeName: fsx-pv
```
Aplique a reivindicação:
```
kubectl apply -f claim.yaml
```
### b. Crie pv.yaml
Atualize a ``:
```
#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:
```
Aplique o volume persistente:
```
kubectl apply -f pv.yaml
```
### c. Crie 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
```
Aplique o pod:
```
kubectl apply -f pod.yaml
```
## Comandos de verificação adicionais
Verifique se o Pod monta e grava no sistema de arquivos:
```
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 no nó para verificar se o tráfego está passando pelo EFA:
```
sudo lnetctl net show -v
```
A saída esperada mostrará interfaces EFA com estatísticas de tráfego.
## Informações relacionadas
+ [Implantar o driver do FSx para Lustre](fsx-csi-create.md)
+ [Otimizar a performance do Amazon FSx para Lustre em nós (não EFA)](fsx-csi-tuning-non-efa.md)
+ [Performance do Amazon FSx para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
+ [Elastic Fabric Adapter](https://docs.aws.amazon.com/ec2/latest/userguide/efa.html)
# Otimizar a performance do Amazon FSx para Lustre em nós (não EFA)
Você pode otimizar a performance do Amazon FSx para Lustre aplicando parâmetros de ajuste durante a inicialização do nó usando dados do usuário do modelo de execução.
**nota**
Para obter informações sobre como criar e implantar o driver CSI do FSx para Lustre, consulte [Implantar o driver do FSx para Lustre](fsx-csi-create.md). Para otimizar a performance com nós habilitados pelo EFA, consulte [Otimizar a performance do Amazon FSx para Lustre em nós (EFA)](fsx-csi-tuning-efa.md).
## Por que usar os dados do usuário do modelo de execução?
+ Aplica ajustes automaticamente durante a inicialização do nó.
+ Garante uma configuração consistente em todos os nós.
+ Elimina a necessidade de configuração manual dos nós.
## Visão geral do script de exemplo
O script de exemplo definido neste tópico executa as seguintes operações:
### `# 1. Install Lustre client`
+ Detecta automaticamente a versão do seu sistema operacional Amazon Linux (AL).
+ Instala o pacote de cliente do Lustre apropriado.
### `# 2. Apply network and RPC tunings`
+ Define `ptlrpcd_per_cpt_max=64` para processamento paralelo de RPC.
+ Configura `ksocklnd credits=2560` para otimizar os buffers de rede.
### `# 3. Load Lustre modules`
+ Remove com segurança os módulos do Lustre existentes, se houver.
+ Lida com a desmontagem dos sistemas de arquivos existentes.
+ Carrega módulos do Lustre novos.
### `# 4. Lustre Network Initialization`
+ Inicializa a configuração de rede do Lustre.
+ Configura os parâmetros de rede necessários.
### `# 5. Mount FSx filesystem`
+ Você deve ajustar os valores para o seu ambiente nesta seção.
### `# 6. Apply tunings`
+ Ajustes da LRU (unidade de bloqueio de recursos):
+ `lru_max_age=600000`
+ `lru_size` calculado com base na contagem de CPU
+ Controle de cache do cliente: `max_cached_mb=64`
+ Controles de RPC:
+ OST `max_rpcs_in_flight=32`
+ MDC `max_rpcs_in_flight=64`
+ MDC `max_mod_rpcs_in_flight=50`
### `# 7. Verify tunings`
+ Verifica todos os ajustes aplicados.
+ Relata êxito ou uma advertência para cada parâmetro.
### `# 8. Setup persistence`
+ Você também deve ajustar os valores para o seu ambiente nesta seção.
+ Detecta automaticamente a versão do seu sistema operacional (AL2023) para determinar qual serviço do `Systemd` deve ser aplicado.
+ O sistema é iniciado.
+ O `Systemd` inicia o serviço `lustre-tunings` (devido a `WantedBy=multi-user.target`).
+ O serviço executa `apply_lustre_tunings.sh`, que:
+ Verifica se o sistema de arquivos está montado.
+ Monta o sistema de arquivos se não estiver montado.
+ Aguarda a montagem bem-sucedida (até cinco minutos).
+ Aplica parâmetros de ajuste após a montagem bem-sucedida.
+ As configurações permanecem ativas até a reinicialização.
+ O serviço é encerrado após a conclusão do script.
+ Systemd marca o serviço como "ativo (encerrado)".
+ O processo se repete na próxima reinicialização.
## Criar um modelo de execução
1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.
1. Escolha **Modelos de execução**.
1. Escolha **Criar modelo de execução**.
1. Em **Detalhes avançados**, localize a seção **Dados do usuário**.
1. Cole o script abaixo, atualizando o que for necessário.
**Importante**
Ajuste esses valores para seu ambiente na seção `# 5. Mount FSx filesystem` e na função `setup_persistence()` de `apply_lustre_tunings.sh` na seção `# 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. Ao criar grupos de nós do Amazon EKS, selecione este modelo de execução. Para obter mais informações, consulte [Criar um grupo de nós gerenciados para seu cluster](create-managed-node-group.md).
## Informações relacionadas
+ [Implantar o driver do FSx para Lustre](fsx-csi-create.md)
+ [Otimizar a performance do Amazon FSx para Lustre em nós (EFA)](fsx-csi-tuning-efa.md)
+ [Performance do Amazon FSx para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/performance.html)
# Usar armazenamento de aplicações de alta performance com o FSx para NetApp ONTAP
O NetApp Trident fornece orquestração de armazenamento dinâmico usando um driver compatível com a interface de armazenamento de contêineres (CSI). Isso permite que clusters do Amazon EKS gerenciem o ciclo de vida dos volumes persistentes (PVs) com suporte por sistemas de arquivo Amazon FSx para NetApp ONTAP. Observe que o Driver CSI do Amazon FSx para NetApp ONTAP não é compatível com o Amazon EKS Hybrid Nodes. Para começar, consulte [Use Trident with Amazon FSx for NetApp ONTAP](https://docs.netapp.com/us-en/trident/trident-use/trident-fsx.html) na documentação do NetApp Trident.
O Amazon FSx for NetApp ONTAP é um serviço de armazenamento que permite iniciar e executar sistemas de arquivos ONTAP totalmente gerenciados na nuvem. ONTAP é a tecnologia de sistema de arquivos da NetApp que fornece um conjunto, amplamente adotado, com todos os recursos de acesso a dados e gerenciamento de dados. O FSx para ONTAP fornece os recursos, a performance e as APIs dos sistemas de arquivos on-premises da NetApp com a agilidade, a escalabilidade e a simplicidade dos serviços totalmente gerenciados da AWS. Para obter mais informações, consulte o [Guia do usuário do FSx for ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html).
**Importante**
Se estiver usando o Amazon FSx para NetApp ONTAP junto com o driver CSI do Amazon EBS para provisionar volumes do EBS, você deve especificar que dispositivos EBS não devem ser usados no arquivo `multipath.conf`. Para ver os métodos compatíveis, consulte [Lista Negra de Arquivos de Configuração](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/dm_multipath/config_file_blacklist#config_file_blacklist). Aqui está um exemplo.
```
defaults {
user_friendly_names yes
find_multipaths no
}
blacklist {
device {
vendor "NVME"
product "Amazon Elastic Block Store"
}
}
```
# Usar armazenamento de dados com o Amazon FSx para OpenZFS
O Amazon FSx para OpenZFS é um serviço de armazenamento de arquivos totalmente gerenciado que facilita a transferência de dados do ZFS on-premises ou de outros servidores de arquivos baseados em Linux para a AWS. É possível fazer isso sem alterar o código da aplicação ou a forma como seus dados são gerenciados. Ele oferece armazenamento de arquivos altamente confiável, escalável, eficiente e rico em recursos, construído no sistema de arquivos de código aberto OpenZFS. Ele combina esses recursos com a agilidade, a escalabilidade e a simplicidade de um serviço da AWS totalmente gerenciado. Para obter mais informações, consulte o [Guia do usuário do Amazon FSx para OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/what-is-fsx.html).
O driver Container Storage Interface (CSI) do FSx para OpenZFS fornece uma interface de CSI que permite que os clusters do Amazon EKS gerenciem o ciclo de vida de volumes do FSx para OpenZFS. Observe que o Driver da CSI do Amazon FSx para OpenZFS não é compatível com o Amazon EKS Hybrid Nodes. Para implantar o driver FSx for OpenZFS CSI em seu cluster do Amazon EKS, consulte [aws-fsx-openzfs-csi-driver](https://github.com/kubernetes-sigs/aws-fsx-openzfs-csi-driver) no GitHub.
# Minimizar a latência com o Amazon File Cache
O Amazon File Cache é um cache de alta velocidade totalmente gerenciado na AWS, que é usado para processar dados de arquivos, independentemente do local em que os dados estão armazenados. O Amazon File Cache carrega os dados no cache automaticamente quando é acessado pela primeira vez e libera os dados quando não é usado. Para obter mais informações, consulte o [Guia do usuário do Amazon File Cache](https://docs.aws.amazon.com/fsx/latest/FileCacheGuide/what-is.html).
O driver da interface de armazenamento de contêiner (CSI) do Amazon File Cache fornece uma interface CSI que possibilita que os clusters do Amazon EKS gerenciem o ciclo de vida dos caches de arquivos da Amazon. Observe que o driver CSI do Amazon File Cache não é compatível com o Amazon EKS Hybrid Nodes. Para implantar o driver CSI do Amazon File Cache em seu cluster do Amazon EKS, consulte [aws-file-cache-csi-driver](https://github.com/kubernetes-sigs/aws-file-cache-csi-driver) no GitHub.
# Acessar objetos do Amazon S3 com o driver CSI do Mountpoint para Amazon S3
Com o [driver Container Storage Interface (CSI) do Mountpoint para Amazon S3](https://github.com/awslabs/mountpoint-s3-csi-driver), suas aplicações do Kubernetes podem acessar objetos do Amazon S3 por meio de uma interface de sistema de arquivos, obtendo alto throughput agregado sem alterar o código de aplicação. Desenvolvido no [Mountpoint para Amazon S3](https://github.com/awslabs/mountpoint-s3), o driver CSI apresenta um bucket do Amazon S3 como um volume que pode ser acessado por contêineres no Amazon EKS e em clusters autogerenciados do Kubernetes.
## Considerações
+ Atualmente, o driver CSI do Mountpoint para Amazon S3 não é compatível com imagens de contêineres baseadas no Windows.
+ O driver CSI do Mountpoint para Amazon S3 não é atualmente compatível com o Amazon EKS Hybrid Nodes.
+ O driver CSI do Mountpoint para Amazon S3 não é compatível com o AWS Fargate. No entanto, os contêineres em execução no Amazon EC2 (com o Amazon EKS ou com uma instalação personalizada do Kubernetes) são compatíveis.
+ O driver CSI do Mountpoint para Amazon S3 é compatível somente com provisionamento estático. Não há suporte ao provisionamento dinâmico ou à criação de novos buckets.
**nota**
O provisionamento estático refere-se ao uso de um bucket do Amazon S3 existente que é especificado como o `bucketName` no `volumeAttributes` no objeto `PersistentVolume`. Para obter mais informações, consulte [Static Provisioning](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/examples/kubernetes/static_provisioning/README.md) no GitHub.
+ Os volumes montados com o driver CSI do Mountpoint para Amazon S3 não são compatíveis com todos os recursos do sistema de arquivos POSIX. Para obter detalhes sobre o comportamento do sistema de arquivos, consulte [Mountpoint for Amazon S3 file system behavior](https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMANTICS.md) no GitHub.
Para obter detalhes sobre a implantação do driver, consulte [Implantar o driver de CSI do Mountpoint para Amazon S3](s3-csi-create.md). Para obter detalhes sobre como remover o driver, consulte [Remover o complemento Mountpoint para Amazon S3 do Amazon EKS](removing-s3-csi-eks-add-on.md).
# Implantar o driver de CSI do Mountpoint para Amazon S3
Com o [driver Container Storage Interface (CSI) do Mountpoint para Amazon S3](https://github.com/awslabs/mountpoint-s3-csi-driver), suas aplicações do Kubernetes podem acessar objetos do Amazon S3 por meio de uma interface de sistema de arquivos, obtendo alto throughput agregado sem alterar o código de aplicação.
Este procedimento mostrará como implantar o [driver do Amazon EKS de CSI do Mountpoint para Amazon S3](s3-csi.md). Antes de continuar, revise as [Considerações](s3-csi.md#s3-csi-considerations).
## Pré-requisitos
+ Um provedor AWS Identity and Access Management (IAM) OpenID Connect (OIDC) para o seu cluster. Para determinar se você tem ou para criar uma, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
+ Versão 2.12.3 ou posterior do AWS CLI instalada e configurada em seu dispositivo ou AWS CloudShell.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
## Etapa 1: criar uma política do IAM
O driver CSI do Mountpoint para Amazon S3 precisa de permissões do Amazon S3 para interagir com seu sistema de arquivos. Esta seção mostra como criar uma política do IAM que conceda as permissões necessárias.
O exemplo de política a seguir segue as recomendações de permissão do IAM para o Mountpoint. Como alternativa, você pode usar a política [AmazonS3FullAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AmazonS3FullAccess$jsonEditor) gerenciada pela AWS, mas ela concede mais permissões do que as necessárias para o Mountpoint.
Para obter mais informações sobre as permissões recomendadas para o Mountpoint, consulte [Mountpoint IAM permissions](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#iam-permissions) no GitHub.
1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
1. No painel de navegação à esquerda, escolha **Políticas**.
1. Na página **Políticas**, escolha **Criar política**.
1. Em **Editor de políticas**, escolha **JSON**.
1. No **Editor de políticas**, copie e cole o seguinte:
**Importante**
Substitua `amzn-s3-demo-bucket1` pelo nome do seu próprio bucket do 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/*"
]
}
]
}
```
Os buckets de diretório, introduzidos com a classe de armazenamento Amazon S3 Express One Zone, usam um mecanismo de autenticação diferente dos buckets de uso geral. Em vez de usar ações `s3:*`, você deve usar a ação `s3express:CreateSession`. Para obter mais informações sobre os buckets do diretório, consulte [Buckets de diretório](https://docs.aws.amazon.com/AmazonS3/latest/userguide/directory-buckets-overview.html) no *Guia do usuário do Amazon S3*.
Abaixo está um exemplo de política de privilégio mínimo que você usaria para um bucket de diretório.
```
{
"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. Escolha **Próximo**.
1. Na página **Analisar**, atribua um nome à sua política. Esta demonstração usa o nome `AmazonS3CSIDriverPolicy`.
1. Escolha **Criar política**.
## Etapa 2: Criar uma função do IAM
O driver CSI do Mountpoint para Amazon S3 precisa de permissões do Amazon S3 para interagir com seu sistema de arquivos. Esta seção mostra como criar um perfil do IAM para delegar essas permissões. Para criar esse perfil, você pode usar uma destas ferramentas:
+ [eksctl](#eksctl_s3_store_app_data)
+ [Console de gerenciamento da AWS](#console_s3_store_app_data)
+ [AWS CLI](#awscli_s3_store_app_data)
**nota**
A política do IAM `AmazonS3CSIDriverPolicy` foi criada na seção anterior.
### eksctl
**Para criar seu perfil do IAM do driver CSI do Mountpoint para Amazon S3 com o `eksctl` **
Para criar o perfil do IAM e a conta de serviço do Kubernetes, execute os comandos a seguir. Esses comandos também anexam a política do IAM `AmazonS3CSIDriverPolicy` ao perfil, anotam a conta de serviço do Kubernetes (`s3-csi-controller-sa`) com o nome do recurso da Amazon (ARN) do perfil do IAM e adicionam o nome da conta de serviço do Kubernetes à política de confiança para o perfil do 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 de gerenciamento da AWS
1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
1. No painel de navegação à esquerda, escolha **Funções**.
1. Na página **Perfis**, selecione **Criar perfil**.
1. Na página **Select trusted entity** (Selecionar entidade confiável), faça o seguinte:
1. Na seção **Tipo de entidade confiável**, escolha **Identidade da Web**.
1. Para **Identity provider** (Provedor de identidade), escolha **OpenID Connect provider URL** (URL do provedor OpenID Connect) para o seu cluster (conforme mostrado na guia **Overview** (Visão geral) do Amazon EKS).
Se não forem exibidos URLs, revise os [Pré-requisitos](#s3-csi-prereqs).
1. Em **Público**, escolha `sts.amazonaws.com`.
1. Escolha **Próximo**.
1. Na página **Adicionar permissões**, faça o seguinte:
1. Na caixa **Filtrar políticas**, insira AmazonS3CSIDriverPolicy.
**nota**
Essa política foi criada na seção anterior.
1. Marque a caixa de seleção à esquerda do resultado `AmazonS3CSIDriverPolicy` retornado na pesquisa.
1. Escolha **Próximo**.
1. Na página **Nomear, revisar e criar**, faça o seguinte:
1. Em **Nome do perfil**, insira um nome exclusivo para o perfil, como AmazonEKS\$1S3\$1CSI\$1DriverRole.
1. Em **Adicionar tags (Opcional)**, adicione metadados ao perfil anexando tags como pares chave-valor. Para obter mais informações sobre o uso de tags no IAM, consulte [Marcar recursos do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) no *Guia do usuário do IAM*.
1. Selecione **Criar perfil**.
1. Depois que a função for criada, escolha a função no console a fim de abri-la para edição.
1. Escolha a guia **Trust relationships** (Relacionamentos de confiança) e, em seguida, escolha **Edit trust policy** (Editar política de confiança).
1. Encontre a linha semelhante à seguinte:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
```
Adicione uma vírgula ao final da linha anterior e, em seguida, adicione a linha a seguir após ela. Substitua *region-code* pela região da AWS em que seu cluster se encontra. Substitua *EXAMPLED539D4633E53DE1B71EXAMPLE* pelo ID do provedor OIDC do cluster.
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:s3-csi-driver-sa"
```
1. Certifique-se de que o operador `Condition` esteja definido como `"StringEquals"`.
1. Escolha **Atualizar política** para concluir.
### AWS CLI
1. Visualize o URL do provedor OIDC do cluster. Substitua *my-cluster* pelo nome do cluster. Se o resultado do comando for `None`, revise os [Pré-requisitos](#s3-csi-prereqs).
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
Veja abaixo um exemplo de saída.
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
1. Crie a função do IAM, concedendo à conta de serviço do Kubernetes a ação `AssumeRoleWithWebIdentity`.
1. Copie o conteúdo a seguir em um arquivo denominado `aws-s3-csi-driver-trust-policy.json`. Substitua *111122223333* pelo ID da sua conta. Substitua *EXAMPLED539D4633E53DE1B71EXAMPLE* e *region-code* pelos valores retornados na etapa anterior.
```
{
"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. Crie a função. Você pode alterar o *AmazonEKS\$1S3\$1CSI\$1DriverRole* para um nome diferente, mas, se fizer isso, certifique-se de alterá-lo também nas etapas posteriores.
```
aws iam create-role \
--role-name AmazonEKS_S3_CSI_DriverRole \
--assume-role-policy-document file://"aws-s3-csi-driver-trust-policy.json"
```
1. Anexe a política do IAM criada anteriormente ao perfil executando o comando a seguir.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonS3CSIDriverPolicy \
--role-name AmazonEKS_S3_CSI_DriverRole
```
**nota**
A política do IAM `AmazonS3CSIDriverPolicy` foi criada na seção anterior.
1. Pule esta etapa se você estiver instalando o driver como um complemento do Amazon EKS.. Para instalações autogerenciadas do driver, crie contas de serviço do Kubernetes que são anotadas com o ARN do perfil do IAM que você criou.
1. Salve o conteúdo a seguir em um arquivo denominado `mountpoint-s3-service-account.yaml`. Substitua *111122223333* pelo ID da sua conta.
```
---
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. Crie a conta de serviço do Kubernetes no cluster: A conta de serviço do Kubernetes (`mountpoint-s3-csi-controller-sa`) é anotada com o perfil do IAM que você criou denominado *AmazonEKS\$1S3\$1CSI\$1DriverRole*.
```
kubectl apply -f mountpoint-s3-service-account.yaml
```
**nota**
Quando você implanta o plug-in nesse procedimento, ele cria e é configurado para usar uma conta de serviço chamada `s3-csi-driver-sa`.
## Etapa 3: instalar o driver de CSI do Mountpoint para Amazon S3
Você pode instalar o driver CSI do Mountpoint para Amazon S3 por meio do complemento do Amazon EKS. Você pode usar as seguintes ferramentas para adicionar o complemento ao seu cluster:
+ [eksctl](#eksctl_s3_add_store_app_data)
+ [Console de gerenciamento da AWS](#console_s3_add_store_app_data)
+ [AWS CLI](#awscli_s3_add_store_app_data)
Você também pode instalar o driver CSI do Mountpoint para Amazon S3 como uma instalação autogerenciada. Para obter instruções sobre como realizar uma instalação autogerenciada, consulte [Installation](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/docs/install.md#deploy-driver) no GitHub.
A partir da versão `v1.8.0`, é possível configurar taints para tolerar os pods do driver CSI. Para fazer isso, especifique um conjunto personalizado de taints para tolerar `node.tolerations` ou tolere todos os taints com `node.tolerateAllTaints`. Para obter mais informações, consulte [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) na documentação do Kubernetes.
### eksctl
**Para adicionar o complemento do Amazon S3 CSI usando `eksctl` **
Execute o comando a seguir. Substitua *my-cluster* pelo nome do seu cluster, *111122223333* pelo ID da sua conta e *AmazonEKS\$1S3\$1CSI\$1DriverRole* pelo nome do [perfil do IAM criado anteriormente](#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 você remover a opção *--force* e alguma das configurações do complemento do Amazon EKS entrar em conflito com as configurações existentes, a atualização do complemento do Amazon EKS falhará e você receberá uma mensagem de erro para ajudá-lo a resolver o conflito. Antes de especificar essa opção, certifique-se de que o complemento Amazon EKS não gerencie as configurações que você precisa gerenciar, pois essas configurações são substituídas por essa opção. Para obter mais informações sobre outras opções para essa configuração, consulte [Addons](https://eksctl.io/usage/addons/) (Complementos) na documentação do `eksctl`. Para obter mais informações sobre o gerenciamento de campos do Kubernetes do Amazon EKS, consulte [Determinar os campos que podem ser personalizados para os complementos do Amazon EKS](kubernetes-field-management.md).
É possível personalizar o `eksctl` por meio de arquivos de configuração. Para obter mais informações, consulte [Trabalhar com valores de configuração](https://eksctl.io/usage/addons/#working-with-configuration-values) na documentação do `eksctl`. O seguinte exemplo de mostra como tolerar todos os taints.
```
# config.yaml
...
addons:
- name: aws-mountpoint-s3-csi-driver
serviceAccountRoleARN: arn:aws:iam::111122223333:role/AmazonEKS_S3_CSI_DriverRole
configurationValues: |-
node:
tolerateAllTaints: true
```
### Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, escolha **Clusters**.
1. Escolha o nome do cluster para o qual você deseja configurar o complemento CSI do Mountpoint para Amazon S3.
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha **Obter mais complementos**.
1. Na página **Selecionar complementos**, faça o seguinte:
1. Na seção **Complementos do Amazon EKS**, marque a caixa de seleção **Driver CSI do Mountpoint para Amazon S3**.
1. Escolha **Próximo**.
1. Na página **Definir as configurações dos complementos selecionados**:
1. Selecione a **Versão** que deseja usar.
1. Em **Selecionar perfil do IAM**, selecione o nome do perfil do IAM ao qual você anexou a política do IAM do driver CSI do Mountpoint para Amazon S3.
1. (Opcional) Atualize o **Método de resolução de conflitos** após expandir as **Configurações opcionais**. Se você selecionar **Substituir**, uma ou mais configurações do complemento existente poderão ser substituídas pelas configurações do complemento do Amazon EKS. Se você não habilitar esta opção e houver um conflito com suas configurações existentes, a operação falhará. É possível usar a mensagem de erro resultante para solucionar o conflito. Antes de selecionar essa opção, certifique-se de que o complemento do Amazon EKS não gerencie as configurações que você precisa autogerenciar.
1. (Opcional) Configure as tolerâncias no campo **Valores de configuração** depois de expandir as **Configurações opcionais**.
1. Escolha **Próximo**.
1. Na página **Adicionar tags**, escolha **Criar**. Depois que a instalação do complemento for concluída, você verá o complemento instalado.
### AWS CLI
**Para adicionar o complemento CSI do Mountpoint para Amazon S3 usando a AWS CLI**
Execute o comando a seguir. Substitua *my-cluster* pelo nome do cluster, *111122223333* pelo ID da conta e *AmazonEKS\$1S3\$1CSI\$1DriverRole* pelo nome do perfil criada anteriormente.
```
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
```
É possível personalizar o comando com o sinalizador `--configuration-values`. O exemplo alternativo a seguir mostra como tolerar todos os taints.
```
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}}'
```
## Etapa 4: xonfigurar o Mountpoint para Amazon S3
Na maioria dos casos, você pode configurar o Mountpoint para Amazon S3 com apenas um nome de bucket. Para obter instruções sobre como configurar o Mountpoint para Amazon S3, consulte [Configuring Mountpoint for Amazon S3](https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md) no GitHub.
## Etapa 5: implantar uma aplicação de exemplo
É possível implantar provisionamento estático para o driver em um bucket do Amazon S3 existente. Para obter mais informações, consulte [Static Provisioning](https://github.com/awslabs/mountpoint-s3-csi-driver/blob/main/examples/kubernetes/static_provisioning/README.md) no GitHub.
# Remover o complemento Mountpoint para Amazon S3 do Amazon EKS
Você tem duas opções para remover o [driver de CSI do Mountpoint para Amazon S3](s3-csi.md).
+ **Preserve add-on software on your cluster** (Preservar software de complemento no cluster): esta opção remove o gerenciamento do Amazon EKS de qualquer configuração. Também remove a capacidade do Amazon EKS de notificar você sobre atualizações e de atualizar automaticamente o complemento do Amazon EKS depois de iniciar uma atualização. No entanto, ele preserva o software de complemento em seu cluster. Essa opção torna o complemento em uma instalação autogerenciada, em vez de um complemento do Amazon EKS. Com essa opção, não há tempo de inatividade para o complemento. Os comandos deste procedimento usam essa opção.
+ **Remover completamente o software do complemento do cluster**: recomendamos remover o complemento do Amazon EKS do cluster se não houver recursos no cluster que dependam dele. Para fazer essa opção, exclua`--preserve`a partir do comando que você utiliza neste procedimento.
Se não houver uma conta do IAM associada ao complemento, a conta do IAM não será removida.
Você pode usar as seguintes ferramentas para remover o complemento do Amazon S3 CSI:
+ [eksctl](#eksctl_s3_remove_store_app_data)
+ [Console de gerenciamento da AWS](#console_s3_remove_store_app_data)
+ [AWS CLI](#awscli_s3_remove_store_app_data)
## eksctl
**Para remover o complemento do Amazon S3 CSI usando `eksctl` **
Substitua *my-cluster* pelo nome do cluster, e depois execute comando a seguir.
```
eksctl delete addon --cluster my-cluster --name aws-mountpoint-s3-csi-driver --preserve
```
## Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, escolha **Clusters**.
1. Escolha o nome do cluster de onde você deseja remover o complemento CSI do Amazon EBS.
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha **Driver CSI do Mountpoint para Amazon S3**.
1. Escolha **Remover**.
1. Na caixa de diálogo de confirmação **Remover: aws-mountpoint-s3-csi-driver**, faça o seguinte:
1. Se quiser que o Amazon EKS pare de gerenciar as configurações do complemento, selecione **Preservar no cluster**. Faça isso se quiser manter o software de complemento em seu cluster. Isso serve para que você possa gerenciar todas as configurações do complemento por conta própria.
1. Insira `aws-mountpoint-s3-csi-driver`.
1. Selecione **Remover**.
## AWS CLI
**Para remover o complemento do Amazon S3 CSI usando a AWS CLI**
Substitua *my-cluster* pelo nome do cluster, e depois execute comando a seguir.
```
aws eks delete-addon --cluster-name my-cluster --addon-name aws-mountpoint-s3-csi-driver --preserve
```
# Habilitar a funcionalidade de snapshot para volumes CSI
A funcionalidade de snapshot permite fazer cópias pontuais dos seus dados. Para que esse recurso funcione no Kubernetes, você precisa de um driver CSI compatível com snapshots (como o driver CSI do Amazon EBS) e um controlador CSI de snapshots. O controlador de snapshot está disponível como complemento gerenciado do Amazon EKS ou como uma instalação autogerenciada.
Veja a seguir algumas considerações ao usar o controlador de snapshots da CSI.
+ O controlador de snapshots deve ser instalado junto com um driver de CSI com funcionalidade de snapshot instantâneo. Para obter instruções sobre como instalar o driver de CSI do Amazon EBS no cluster, consulte [Usar armazenamento de volumes do Kubernetes com o Amazon EBS](ebs-csi.md).
+ O Kubernetes não é compatível com snapshots de volumes que estão sendo fornecidos por meio da migração da CSI, como volumes do Amazon EBS que usam uma `StorageClass` com provisionador do `kubernetes.io/aws-ebs`. Os volumes devem ser criados com um `StorageClass` que faça referência ao provisionador do driver da CSI, `ebs.csi.aws.com`.
+ O Modo Automático do Amazon EKS não inclui o controlador de snapshots. A capacidade de armazenamento do Modo Automático do EKS é compatível com o controlador de snapshots.
Recomendamos instalar o controlador de snapshots da CSI via complemento gerenciado do Amazon EKS. Esse complemento inclui as definições de recursos personalizados (CRDs) que são necessárias para criar e gerenciar snapshot no Amazon EKS. Para adicionar um complemento do Amazon EKS ao cluster, consulte [Criar um complemento do Amazon EKS](creating-an-add-on.md). Para obter mais informações sobre complementos, consulte [Complementos do Amazon EKS](eks-add-ons.md).
Como alternativa, se você quiser uma instalação autogerenciada do controlador CSI de snapshots, consulte [Usage](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage) no Upstream Kubernetes `external-snapshotter` no GitHub.