Simplificação da implantação de aplicações multilocatário no Amazon EKS usando o Flux - Recomendações da AWS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Simplificação da implantação de aplicações multilocatário no Amazon EKS usando o Flux

Nadeem Rahaman, Aditya Ambati, Aniket Dekate e Shrikant Patil, Amazon Web Services

Resumo

Diversas empresas que fornecem produtos e serviços atuam em setores regulados por dados e devem preservar a separação de dados entre suas áreas internas. Este padrão descreve como você pode usar o recurso multilocatário no Amazon Elastic Kubernetes Service (Amazon EKS) para desenvolver uma plataforma de dados que garanta isolamento lógico e físico entre locatários ou usuários que compartilham um único cluster do Amazon EKS. O padrão oferece isolamento por meio das seguintes abordagens:

  • Isolamento entre namespaces no Kubernetes

  • Regras de controle de acesso com base em função (RBAC)

  • Políticas de rede

  • Cotas de recurso

  • AWS Identity and Access Management Funções (IAM) para contas de serviço (IRSA)

Além disso, a solução usa o Flux para garantir que a configuração do locatário permaneça imutável durante a implantação das aplicações. É possível implantar as aplicações do locatário especificando o repositório do locatário que contém o arquivo kustomization.yaml do Flux na sua configuração.

Este padrão realiza a implementação de:

  • Um AWS CodeCommit repositório, AWS CodeBuild projetos e um AWS CodePipeline pipeline, que são criados com a implantação manual de scripts do Terraform.

  • Componentes de rede e de computação necessários para hospedar os locatários. Eles são criados por meio CodePipeline e CodeBuild usando o Terraform.

  • Namespaces dos locatários, políticas de rede e cotas de recursos, os quais são configurados via chart do Helm.

  • Aplicações pertencentes a diferentes locatários, implantadas usando o Flux.

Recomendamos que você planeje e desenvolva cuidadosamente a própria arquitetura multilocatário com base em seus requisitos e considerações de segurança. Este padrão fornece um ponto de partida para a sua implementação.

Pré-requisitos e limitações

Pré-requisitos

Limitações

  • Dependência de implantações manuais do Terraform: a configuração inicial do fluxo de trabalho, incluindo a criação de CodeCommit repositórios, CodeBuild projetos e CodePipeline pipelines, depende de implantações manuais do Terraform. Isso introduz uma limitação potencial em termos de automação e escalabilidade, pois exige intervenção manual para alterações na infraestrutura.

  • CodeCommit dependência do repositório: o fluxo de trabalho depende dos CodeCommit repositórios como solução de gerenciamento de código-fonte e é fortemente acoplado a. Serviços da AWS

Arquitetura

Arquiteturas de destino

Este padrão implanta três módulos para criar o pipeline e a infraestrutura de rede e de computação de uma plataforma de dados, conforme ilustrado nos diagramas a seguir.

Arquitetura do pipeline:

Infraestrutura do pipeline para uma arquitetura multilocatário no Amazon EKS

Arquitetura da rede:

Infraestrutura da rede para uma arquitetura multilocatário no Amazon EKS

Arquitetura da computação:

Infraestrutura da computação para uma arquitetura multilocatário no Amazon EKS

Ferramentas

Serviços da AWS

  • O AWS CodeBuild é um serviço de compilação totalmente gerenciado que permite compilar o código-fonte, realizar testes de unidade e produzir artefatos preparados para a implantação.

  • O AWS CodeCommit é um serviço de controle de versão que ajuda no armazenamento e no gerenciamento de repositórios Git de forma privada, sem a necessidade de administrar o próprio sistema de controle de origem.

  • O AWS CodePipeline ajuda você a modelar e configurar rapidamente os diferentes estágios de uma versão de software, além de automatizar as etapas necessárias para a implantação contínua de alterações.

  • O Amazon Elastic Kubernetes Service (Amazon EKS) ajuda você a executar o AWS Kubernetes sem precisar instalar ou manter seu próprio plano de controle ou nós do Kubernetes.

  • AWS Transit Gatewayé um hub central que conecta nuvens privadas virtuais (VPCs) e redes locais.

  • A Amazon Virtual Private Cloud (Amazon VPC) ajuda você a lançar AWS recursos em uma rede virtual que você definiu. Essa rede virtual é semelhante a uma rede tradicional que você operaria no próprio datacenter, com os benefícios de usar a infraestrutura escalável da AWS.

Outras ferramentas

  • As políticas de rede da Cilium fornecem suporte para as políticas do Kubernetes voltadas para as camadas 3 e 4. Essas políticas podem ser complementadas com políticas para a camada 7 para prover segurança de API em protocolos como HTTP, Kafka, gRPC e outros equivalentes.

  • O Flux é uma ferramenta de entrega contínua (CD) baseada em Git que automatiza a implantação de aplicações no Kubernetes.

  • O Helm é um gerenciador de pacotes de código aberto para o Kubernetes que auxilia na instalação e no gerenciamento de aplicações no cluster do Kubernetes.

  • O Terraform é uma ferramenta de infraestrutura como código (IaC) HashiCorp que ajuda você a criar e gerenciar recursos na nuvem e no local.

Repositório de código

O código desse padrão está disponível no repositório GitHub EKS Multi-Tenancy Terraform Solution.

Práticas recomendadas

Para obter diretrizes e práticas recomendadas para o uso dessa implementação, consulte:

Épicos

TarefaDescriptionHabilidades necessárias

Clone o repositório do projeto.

Clone o repositório GitHub EKS Multi-Tenancy Terraform Solution executando o seguinte comando em uma janela de terminal:

git clone https://github.com/aws-samples/aws-eks-multitenancy-deployment.git
AWS DevOps

Inicialize o bucket do S3 do Terraform e o Amazon DynamoDB.

  1. Na pasta bootstrap, abra o arquivo bootstrap.sh e atualize os valores das variáveis para o nome do bucket do S3, o nome da tabela do DynamoDB e a Região da AWS:

    S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME>" REGION="<AWS_REGION>"
  2. Execute o script bootstrap.sh. O script requer o AWS CLI, que você instalou como parte dos pré-requisitos.

    cd bootstrap ./bootstrap.sh
AWS DevOps

Atualize os arquivos run.sh e locals.tf.

  1. Após a conclusão bem-sucedida do processo de inicialização, copie o nome do bucket do S3 e da tabela do DynamoDB da seção variables do script bootstrap.sh:

    # Variables S3_BUCKET_NAME="<S3_BUCKET_NAME>" DYNAMODB_TABLE_NAME="<DYNAMODB_NAME"
  2. Cole esses valores no script run.sh, que está no diretório raiz do projeto:

    BACKEND_BUCKET_ID="<SAME_NAME_AS_S3_BUCKET_NAME>" DYNAMODB_ID="<SAME_NAME_AS_DYNAMODB_NAME>"
  3. Faça o upload do código do projeto em um CodeCommit repositório. É possível criar esse repositório automaticamente por meio do Terraform ao definir a seguinte variável como true no arquivo demo/pipeline/locals.tf:

    create_new_repo = true
  4. Atualize o arquivo locals.tf de acordo com seus requisitos para criar os recursos do pipeline.

AWS DevOps

Implante o módulo do pipeline.

Para criar os recursos do pipeline, execute manualmente os comandos do Terraform apresentados a seguir. Não há orquestração para executar esses comandos automaticamente.

./run.sh -m pipeline -e demo -r <AWS_REGION> -t init ./run.sh -m pipeline -e demo -r <AWS_REGION> -t plan ./run.sh -m pipeline -e demo -r <AWS_REGION> -t apply
AWS DevOps
TarefaDescriptionHabilidades necessárias

Iniciar o pipeline.

  1. Na pasta templates, verifique se os arquivos buildspec têm a seguinte variável configurada para network:

    TF_MODULE_TO_BUILD: "network"
  2. No CodePipeline console, na página de detalhes do pipeline, inicie o pipeline escolhendo Release change.

Após essa primeira execução, o pipeline é iniciado automaticamente sempre que você confirma uma alteração na ramificação principal do CodeCommit repositório.

O pipeline inclui as seguintes fases:

  • validate inicializa o Terraform, executa verificações de segurança do Terraform usando as ferramentas checkov e tfsec, e envia os relatórios de verificação para o bucket do S3.

  • plan exibe o plano do Terraform e envia o plano para o bucket do S3.

  • applyaplica a saída do plano Terraform do bucket S3 e cria AWS recursos.

  • destroyremove os AWS recursos criados durante o apply estágio. Para habilitar essa fase opcional, defina a seguinte variável como true no arquivo demo/pipeline/locals.tf:

    enable_destroy_stage = true
AWS DevOps

Valide os recursos criados por meio do módulo de rede.

Confirme se os seguintes AWS recursos foram criados após a implantação bem-sucedida do pipeline:

  • Uma VPC de saída com três sub-redes públicas e três privadas, gateway da internet e gateway NAT.

  • Uma VPC do Amazon EKS com três sub-redes privadas.

  • Locatário 1 e Locatário 2 VPCs com três sub-redes privadas cada.

  • Um gateway de trânsito com todos os anexos da VPC e rotas para cada sub-rede privada.

  • Uma rota estática no gateway de trânsito para a VPC de saída do Amazon EKS, com o bloco CIDR de destino 0.0.0.0/0. Isso é necessário para permitir que todos tenham acesso de saída VPCs à Internet por meio da VPC de saída do Amazon EKS.

AWS DevOps
TarefaDescriptionHabilidades necessárias

Atualize locals.tf para permitir o acesso do CodeBuild projeto à VPC.

Para implantar os complementos para o cluster privado do Amazon EKS, o CodeBuild projeto deve ser anexado à VPC do Amazon EKS.

  1. Na pasta demo/pipeline, abra o arquivo locals.tf e defina a variável vpc_enabled como true.

  2. Execute o run.sh para aplicar as alterações no módulo do pipeline:

    demo/pipeline/locals.tf ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd init ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd plan ./run.sh -m pipeline -env demo -region <AWS_REGION> -tfcmd apply
AWS DevOps

Atualize os arquivos buildspec para desenvolver o módulo de computação.

Na pasta templates, em todos os arquivos YAML de buildspec, defina o valor da variável TF_MODULE_TO_BUILD de network para compute:

TF_MODULE_TO_BUILD: "compute"
AWS DevOps

Atualize o arquivo values para o chart do Helm de gerenciamento de locatários.

  1. Abra o arquivo values.yaml no seguinte local:

    cd cfg-terraform/demo/compute/cfg-tenant-mgmt

    Exemplo de arquivo:

    --- global: clusterRoles: operator: platform-tenant flux: flux-tenant-applier flux: tenantCloneBaseUrl: ${TEANT_BASE_URL} repoSecret: ${TENANT_REPO_SECRET} tenants: tenant-1: quotas: limits: cpu: 1 memory: 1Gi flux: path: overlays/tenant-1 tenant-2: quotas: limits: cpu: 1 memory: 2Gi flux: path: overlays/tenant-2
  2. Nas seções global e tenants, atualize a configuração de acordo com os seus requisitos:

    • tenantCloneBaseUrl: caminho para o repositório que hospeda o código de todos os locatários (usamos o mesmo repositório Git para todos os locatários)

    • repoSecret: segredo do Kubernetes que contém as chaves SSH e os hosts conhecidos para autenticação no repositório Git referente ao locatário global

    • quotas: cotas de recursos do Kubernetes que você deseja aplicar para cada locatário

    • flux path: caminho para os arquivos YAML da aplicação do locatário no repositório do locatário global

AWS DevOps

Valide os recursos de computação.

Depois de atualizar os arquivos nas etapas anteriores, CodePipeline inicia automaticamente. Confirme se ele criou os seguintes AWS recursos para a infraestrutura computacional:

  • Cluster do Amazon EKS com endpoint privado

  • Nós de processamento do Amazon EKS

  • Complementos do Amazon EKS: segredos de entidades externas, aws-loadbalancer-controller e metrics-server

  • GitOps módulo, gráfico Flux Helm, gráfico Cilium Helm e gráfico Helm de gerenciamento de inquilinos

AWS DevOps
TarefaDescriptionHabilidades necessárias

Valide os recursos de gerenciamento de locatários no Kubernetes.

Execute os comandos apresentados a seguir para verificar se os recursos de gerenciamento de locatários foram criados com êxito com a ajuda do Helm.

  1. Os namespaces dos locatários foram criados, conforme especificado em values.yaml:

    kubectl get ns -A
  2. As cotas foram atribuídas a cada namespace de locatário, conforme especificado em values.yaml:

    kubectl get quota --namespace=<tenant_namespace>
  3. Os detalhes das cotas estão corretos para cada namespace de locatário:

    kubectl describe quota cpu-memory-resource-quota-limit -n <tenant_namespace>
  4. As políticas de rede da Cilium foram aplicadas a cada namespace de locatário:

    kubectl get CiliumNetworkPolicy -A
AWS DevOps

Verifique as implantações das aplicações dos locatários.

Execute os comandos apresentados a seguir para verificar se as aplicações dos locatários foram implantadas.

  1. O Flux é capaz de se conectar ao CodeCommit repositório especificado no GitOps módulo:

    kubectl get gitrepositories -A
  2. O controlador de personalização do Flux implantou os arquivos YAML no repositório: CodeCommit

    kubectl get kustomizations -A
  3. Todos os recursos das aplicações foram implantados nos seus respectivos namespaces de locatários:

    kubectl get all -n <tenant_namespace>
  4. Uma entrada foi criada para cada locatário:

    kubectl get ingress -n <tenant_namespace>

Solução de problemas

ProblemaSolução

Você recebe uma mensagem de erro semelhante a esta:

Failed to checkout and determine revision: unable to clone unknown error: You have successfully authenticated over SSH. You can use Git to interact with AWS CodeCommit.

Siga estas etapas para solucionar o problema:

  1. Verifique o repositório da aplicação do locatário, pois um repositório vazio ou configurado incorretamente pode estar causando o erro. Certifique-se de que o repositório da aplicação do locatário contém o código necessário.

  2. Reimplante o módulo tenant_mgmt. No arquivo de configuração do módulo tenant_mgmt, localize o bloco app e, em seguida, defina o parâmetro deploy como 0:

    deploy = 0

    Após executar o comando apply do Terraform, altere o valor do parâmetro deploy de volta para 1:

    deploy = 1
  3. Verifique o status novamente. Após executar as etapas anteriores, use o seguinte comando para verificar se o problema persiste:

     kubectl get gitrepositories -A

    Se o problema persistir, considere analisar os logs do Flux mais aprofundadamente para obter mais detalhes ou consulte o guia geral de solução de problemas do Flux.

Recursos relacionados

Mais informações

A seguir, apresentamos um exemplo de estrutura de repositório para a implantação das aplicações dos locatários:

applications sample_tenant_app ├── README.md ├── base │ ├── configmap.yaml │ ├── deployment.yaml │ ├── ingress.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays ├── tenant-1 │ ├── configmap.yaml │ ├── deployment.yaml │ └── kustomization.yaml └── tenant-2 ├── configmap.yaml └── kustomization.yaml