Executar workloads monitoradas com armazenamento de dados persistente usando o Amazon EFS no Amazon EKS com o AWS Fargate

Crie um cluster do Amazon EKS.

Exportar as variáveis de ambiente.

Executar o script env.sh. Isso fornece as informações necessárias para as próximas etapas.

source ./scripts/env.sh
Inform the AWS Account ID:
<13-digit-account-id>
Inform your AWS Region:
<aws-Region-code>
Inform your Amazon EKS Cluster Name:
<amazon-eks-cluster-name>
Inform the Amazon EFS Creation Token:
<self-genereated-uuid>

Caso não as tenha ainda, você pode obter todas as informações solicitadas acima com os seguintes comandos da CLI.

# ACCOUNT ID
aws sts get-caller-identity --query "Account" --output text

# REGION CODE
aws configure get region

# CLUSTER EKS NAME
aws eks list-clusters --query "clusters" --output text

# GENERATE EFS TOKEN
uuidgen

Crie um namespace do Kubernetes e um perfil do Fargate para workloads da aplicação.

Crie um namespace para receber as workloads do aplicativo que interagem com o Amazon EFS. Execute o script create-k8s-ns-and-linked-fargate-profile.sh. Você pode optar por usar um nome de namespace personalizado ou o namespace padrão fornecido poc-efs-eks-fargate.

Com um nome de namespace de aplicação personalizado:

export $APP_NAMESPACE=<CUSTOM_NAME>
./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \
-c "$CLUSTER_NAME" -n "$APP_NAMESPACE"

Sem um nome de namespace de aplicação personalizado:

./scripts/epic01/create-k8s-ns-and-linked-fargate-profile.sh \
    -c "$CLUSTER_NAME"

onde $CLUSTER_NAME é o nome do cluster do Amazon EKS. O parâmetro -n <NAMESPACE> é opcional; se não for informado, um nome de namespace padrão gerado será fornecido.

Gere um token exclusivo.

O Amazon EFS requer um token de criação para garantir uma operação idempotente (chamar a operação com o mesmo token de criação não tem efeito). Para atender a esse requisito, você deve gerar um token exclusivo por meio de uma técnica disponível. Por exemplo, você pode gerar um identificador universal exclusivo (UUID) para usar como um token de criação.

Criar um sistema de arquivos do Amazon EFS.

Crie o sistema de arquivos para receber os arquivos de dados que são lidos e gravados pelas workloads do aplicativo. Você pode criar um sistema de arquivos criptografado ou não criptografado. (Como prática recomendada, o código deste padrão cria um sistema criptografado para habilitar a criptografia em repouso por padrão.) Você pode usar uma chave do AWS KMS exclusiva e simétrica do AWS KMS para criptografar o sistema de arquivos. Se não for especificada, uma chave gerenciada pela AWS será usada.

Use o script create-efs.sh para criar um sistema de arquivos Amazon EFS criptografado ou não criptografado, depois de gerar um token exclusivo para o Amazon EFS.

Com a criptografia em repouso, sem uma chave KMS:

./scripts/epic02/create-efs.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN"

onde $CLUSTER_NAME é o nome do seu cluster Amazon EKS e $EFS_CREATION_TOKEN é um token de criação exclusivo para o sistema de arquivos.

Com a criptografia em repouso, com uma chave KMS:

./scripts/epic02/create-efs.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN" \
    -k "$KMS_KEY_ALIAS"

onde $CLUSTER_NAME é o nome do seu cluster Amazon EKS e $EFS_CREATION_TOKEN é um token de criação exclusivo para o sistema de arquivos, e $KMS_KEY_ALIAS é o alias para a chave do KMS.

Sem criptografia:

./scripts/epic02/create-efs.sh -d \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN"

onde $CLUSTER_NAME é o nome do seu cluster Amazon EKS, $EFS_CREATION_TOKEN é um token de criação exclusivo para o sistema de arquivos e –d desabilita a criptografia em repouso.

Crie um grupo de segurança.

Crie um grupo de segurança para permitir que o cluster do Amazon EKS acesse o sistema de arquivos do Amazon EFS.

Atualize a regra de entrada para o grupo de segurança.

Atualize as regras de entrada do grupo de segurança para permitir o tráfego de entrada nas seguintes configurações:

Adicione um destino de montagem para cada sub-rede privada.

Para cada sub-rede privada do cluster Kubernetes, crie um destino de montagem para o sistema de arquivos e o grupo de segurança.

Implemente o driver da CSI do Amazon EFS.

Implemente o driver da CSI do Amazon EFS no cluster. O driver provisiona o armazenamento de acordo com as declarações de volume persistentes criadas pelas aplicações. Execute o script create-k8s-efs-csi-sc.sh para implantar o driver da CSI do Amazon EFS e a classe de armazenamento no cluster.

./scripts/epic03/create-k8s-efs-csi-sc.sh

Esse script usa o utilitário kubectl, portanto, certifique-se de que o contexto tenha sido configurado para apontar para o cluster do Amazon EKS desejado.

Implante a classe de armazenamento.

Implante a classe de armazenamento no cluster do provisionador Amazon EFS (efs.csi.aws.com).

Implante o volume persistente.

Implante o volume persistente e vincule-o à classe de armazenamento criada e ao ID do sistema de arquivos Amazon EFS. O aplicativo usa o volume persistente para ler e gravar conteúdo. Você pode especificar qualquer tamanho para o volume persistente no campo de armazenamento. O Kubernetes requer esse campo, mas como o Amazon EFS é um sistema de arquivos elástico, ele não impõe nenhuma capacidade de sistema de arquivos. Você pode implantar o volume persistente com ou sem criptografia. (O driver CSI do Amazon EFS habilita a criptografia por padrão, como uma prática recomendada.) Execute o script deploy-poc-app.sh para implantar o volume persistente, a declaração de volume persistente e as duas workloads.

Com criptografia em trânsito:

./scripts/epic04/deploy-poc-app.sh \
    -t "$EFS_CREATION_TOKEN"

onde $EFS_CREATION_TOKEN é o token de criação exclusivo para o sistema de arquivos.

Sem criptografia em trânsito:

./scripts/epic04/deploy-poc-app.sh -d \
    -t "$EFS_CREATION_TOKEN"

onde $EFS_CREATION_TOKEN é o token de criação exclusivo para o sistema de arquivos e –d desativa a criptografia em trânsito.

Implante a declaração de volume persistente solicitada pelo aplicativo.

Implante a declaração de volume persistente solicitada pelo aplicativo e vincule-a à classe de armazenamento. Use o mesmo modo de acesso do volume persistente que você criou anteriormente. Você pode especificar qualquer tamanho para a reivindicação de volume persistente no campo de armazenamento. O Kubernetes requer esse campo, mas como o Amazon EFS é um sistema de arquivos elástico, ele não impõe nenhuma capacidade de sistema de arquivos.

Implante a workload 1.

Implante o pod que representa a workload 1 do aplicativo. Essa workload grava conteúdo no arquivo /data/out1.txt.

Implante a workload 2.

Implante o pod que representa a workload 2 do aplicativo. Essa workload grava conteúdo no arquivo /data/out2.txt.

Verifique o status de PersistentVolume.

Para conferir o status do PersistentVolume, insira o comando a seguir.

kubectl get pv

Para obter um exemplo de saída, consulte a seção Informações adicionais.

Verifique o status de PersistentVolumeClaim.

Para conferir o status do PersistentVolumeClaim, insira o comando a seguir.

kubectl -n poc-efs-eks-fargate get pvc

Para obter um exemplo de saída, consulte a seção Informações adicionais.

Validar se a workload 1 pode gravar no sistema de arquivos.

Insira o seguinte comando para validar se a workload 1 está gravando em /data/out1.txt.

kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -f /data/out1.txt

Os resultados são semelhantes ao seguinte:

...
Thu Sep  3 15:25:07 UTC 2023 - PoC APP 1
Thu Sep  3 15:25:12 UTC 2023 - PoC APP 1
Thu Sep  3 15:25:17 UTC 2023 - PoC APP 1
...

Validar se a workload 2 pode gravar no sistema de arquivos.

Insira o seguinte comando para validar se a workload 2 está gravando em /data/out2.txt.

kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -f /data/out2.txt

Os resultados são semelhantes ao seguinte:

...
Thu Sep  3 15:26:48 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:53 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:58 UTC 2023 - PoC APP 2
...

Validar se a workload 1 pode ler o arquivo gravado pela workload 2.

Insira o comando a seguir para validar que a workload 1 pode ler o arquivo /data/out2.txt gravado pela workload 2:

kubectl exec -ti poc-app1 -n poc-efs-eks-fargate -- tail -n 3 /data/out2.txt

Os resultados são semelhantes ao seguinte:

...
Thu Sep  3 15:26:48 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:53 UTC 2023 - PoC APP 2
Thu Sep  3 15:26:58 UTC 2023 - PoC APP 2
...

Validar se a workload 2 pode ler o arquivo gravado pela workload 1.

Insira o comando a seguir para validar que a workload 2 pode ler o arquivo /data/out1.txt gravado pela workload 1:

kubectl -n $APP_NAMESPACE exec -ti poc-app2 -- tail -n 3 /data/out1.txt

Os resultados são semelhantes ao seguinte:

...
Thu Sep  3 15:29:22 UTC 2023 - PoC APP 1
Thu Sep  3 15:29:27 UTC 2023 - PoC APP 1
Thu Sep  3 15:29:32 UTC 2023 - PoC APP 1
...

Valide se os arquivos são retidos após a remoção dos componentes do aplicativo.

Em seguida, use um script para remover os componentes da aplicação (volume persistente, declaração de volume persistente e pods) e verifique se os arquivos /data/out1.txt e /data/out2.txt estão retidos no sistema de arquivos. Execute o script validate-efs-content.sh usando o comando a seguir.

./scripts/epic05/validate-efs-content.sh \
    -t "$EFS_CREATION_TOKEN"

onde $EFS_CREATION_TOKEN é o token de criação exclusivo para o sistema de arquivos.

Os resultados são semelhantes ao seguinte:

pod/poc-app-validation created
Waiting for pod get Running state...
Waiting for pod get Running state...
Waiting for pod get Running state...
Results from execution of 'find /data' on validation process pod:
/data
/data/out2.txt
/data/out1.txt

Monitore os registros do aplicativo.

Como parte de uma operação do segundo dia, envie os registros do aplicativo para o Amazon CloudWatch para monitoramento.

Monitore os contêineres do Amazon EKS e do Kubernetes com o Container Insights.

Como parte de uma operação do segundo dia, monitore os sistemas Amazon EKS e Kubernetes usando o Amazon CloudWatch Container Insights. Essa ferramenta coleta, agrega e resume métricas de aplicações em contêineres em diferentes níveis e dimensões. Para obter mais informações, consulte a seção Recursos relacionados.

Monitorar o Amazon EFS com o CloudWatch

Como parte da operação do segundo dia, monitore os sistemas de arquivos usando o Amazon CloudWatch, que coleta e processa os dados brutos do Amazon EFS em métricas legíveis, quase em tempo real. Para obter mais informações, consulte a seção Recursos relacionados.

Limpe todos os recursos criados para o padrão.

Depois de concluir esse padrão, limpe todos os recursos para evitar incorrer em cobranças da AWS. Execute o script clean-up-resources.sh para remover todos os recursos depois de terminar de usar a aplicação PoC. Escolha uma das seguintes opções:

Com a criptografia em repouso, com uma chave KMS:

./scripts/epic06/clean-up-resources.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN" \
    -k "$KMS_KEY_ALIAS"

onde $CLUSTER_NAME é o nome do seu cluster Amazon EKS, $EFS_CREATION_TOKEN é o token de criação exclusivo para o sistema de arquivos e $KMS_KEY_ALIAS é o alias da chave KMS.

Sem criptografia em repouso:

./scripts/epic06/clean-up-resources.sh \
    -c "$CLUSTER_NAME" \
    -t "$EFS_CREATION_TOKEN"

onde $CLUSTER_NAME é o nome do seu cluster Amazon EKS e $EFS_CREATION_TOKEN é um token de criação para o sistema de arquivos.