Considerações sobre o ACK para o EKS - Amazon EKS
Padrões de configuração do IAMIntegração com outras funcionalidades do EKSOrganização dos recursosMigração de outras ferramentas de infraestrutura como códigoPolíticas de exclusãoDocumentação originalPróximas etapas

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.

Considerações sobre o ACK para o EKS

Este tópico aborda considerações importantes para o uso da funcionalidade do EKS para o ACK, incluindo a configuração do IAM, os padrões para várias contas e a integração com outras funcionalidades do EKS.

Padrões de configuração do IAM

A funcionalidade do ACK usa um perfil de funcionalidade do IAM para se autenticar na AWS. Escolha o padrão do IAM mais adequado às suas necessidades.

Simples: um único perfil de funcionalidade

Para ambientes de desenvolvimento, testes ou casos de uso simples, atribua todas as permissões necessárias diretamente ao perfil de funcionalidade.

Quando utilizar:

  • Conceitos básicos do ACK

  • Implantações em uma única conta

  • Todos os recursos são gerenciados por uma única equipe

  • Ambientes de desenvolvimento e de teste

Exemplo: adicione permissões do S3 e do RDS ao seu perfil de funcionalidade com condições de marcação de recursos:

{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": ["rds:*"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-west-2", "us-east-1"]
        },
      }
    }
  ]
}

Este exemplo restringe as operações do S3 e do RDS a regiões específicas e requer que os recursos do RDS tenham uma etiqueta ManagedBy: ACK.

Produção: seletores de perfil do IAM

Para ambientes de produção, use os seletores de perfil do IAM para implementar o acesso de privilégio mínimo e o isolamento em nível de namespace.

Quando utilizar:

  • Ambientes de produção

  • Clusters gerenciados por várias equipes

  • Gerenciamento de recursos em várias contas

  • Requisitos de segurança de privilégio mínimo

  • Diferentes serviços que necessitam de permissões distintas

Benefícios:

  • Cada namespace recebe apenas as permissões de que necessita

  • Isolamento de equipes, portanto, a Equipe A não pode usar as permissões da Equipe B

  • Auditoria e conformidade facilitadas

  • Obrigatório para o gerenciamento de recursos entre contas

Para obter a configuração detalhada do seletor de perfil do IAM, consulte Configuração das permissões do ACK.

Integração com outras funcionalidades do EKS

GitOps com Argo CD

Empregue a funcionalidade do EKS para o Argo CD a fim de implantar recursos do ACK de repositórios do Git, permitindo fluxos de trabalho do GitOps para o gerenciamento de infraestrutura.

Considerações:

  • Armazene os recursos do ACK junto aos manifestos da aplicação para um GitOps de ponta a ponta

  • Organize por ambiente, serviço ou tipo de recurso com base na estrutura da sua equipe

  • Use a sincronização automática do Argo CD para reconciliação contínua

  • Habilite a supressão para remover automaticamente recursos excluídos

  • Considere o uso de padrões hub-and-spoke para o gerenciamento da infraestrutura de vários clusters

O GitOps oferece trilhas de auditoria, funcionalidades de reversão e gerenciamento declarativo da infraestrutura. Para saber mais sobre o Argo CD, consulte Como trabalhar com o Argo CD.

Composição de recursos com o kro

Use a funcionalidade do EKS para o kro (Kube Resource Orchestrator) para compor vários recursos do ACK em abstrações de nível superior e APIs personalizadas.

Situações para o uso do kro com o ACK:

  • Criação de padrões reutilizáveis para pilhas de infraestrutura comuns (banco de dados + backup + monitoramento)

  • Desenvolvimento de plataformas de autoatendimento com APIs simplificadas para as equipes destinadas ao trabalho com APIs aplicação

  • Gerenciamento de dependências de recursos e transferência de valores entre recursos (como o ARN de um bucket do S3 para uma função do Lambda)

  • Padronização das configurações de infraestrutura entre as equipes

  • Redução da complexidade ao ocultar detalhes de implementação atrás de recursos personalizados

Padrões de exemplo:

  • Pilha da aplicação: bucket do S3 + fila do SQS + configuração de notificação

  • Configuração do banco de dados: instância do RDS + grupo de parâmetros + grupo de segurança + segredos

  • Rede: VPC + sub-redes + tabelas de rotas + grupos de segurança

O kro gerencia a ordenação de dependências, a propagação de status e o gerenciamento do ciclo de vida dos recursos compostos. Para saber mais sobre o kro, consulte Conceitos do kro.

Organização dos recursos

Organize os recursos do ACK usando namespaces do Kubernetes e etiquetas de recursos da AWS para obter melhor gerenciamento, controle de acesso e rastreamento de custos.

Organização de namespaces

Use namespaces do Kubernetes para a separação lógica de recursos do ACK por ambiente (por exemplo, produção, preparação e desenvolvimento), equipe (como plataforma, dados e ML) ou aplicação.

Benefícios:

  • RBAC com escopo de namespace para controle de acesso

  • Definição de regiões padrão por namespace usando anotações

  • Gerenciamento e limpeza de recursos facilitados

  • Separação lógica alinhada à estrutura organizacional

Marcação de recursos

O EKS aplica etiquetas automaticamente aos recursos da AWS gerenciados pelo ACK, incluindo o ARN do recurso de funcionalidade. Adicione etiquetas adicionais para alocação de custos, rastreamento de propriedade e fins organizacionais.

Etiquetas recomendadas:

  • Ambiente (por exemplo, produção, preparação e desenvolvimento)

  • Propriedade da equipe ou do departamento

  • Centro de custo para alocação de faturamento

  • Nome da aplicação ou do serviço

  • ManagedBy: ACK (para identificar recursos gerenciados pelo ACK)

Migração de outras ferramentas de infraestrutura como código

Muitas organizações estão encontrando valor na padronização do Kubernetes além da orquestração de suas workloads. Migrar a infraestrutura e o gerenciamento de recursos da AWS para o ACK permite que você padronize o gerenciamento da infraestrutura utilizando as APIs do Kubernetes em conjunto com as workloads da aplicação.

Benefícios da padronização no Kubernetes para infraestrutura:

  • Fonte única de verdade: gerencie tanto aplicações quanto infraestrutura no Kubernetes, permitindo uma prática de GitOps de ponta a ponta

  • Ferramentas unificadas: as equipes usam recursos e ferramentas do Kubernetes em vez de aprender diversas ferramentas e frameworks

  • Reconciliação consistente: o ACK reconcilia continuamente os recursos da AWS assim como o Kubernetes faz com as workloads, detectando e corrigindo desvios em comparação com ferramentas imperativas

  • Composições nativas: com o kro e o ACK juntos, referencie recursos da AWS diretamente nos manifestos da aplicação e de recursos, transferindo strings de conexão e ARNs entre os recursos

  • Operações simplificadas: um único ambiente de gerenciamento para implantações, reversões e observabilidade em todo o sistema

O ACK permite a adoção de recursos da AWS já existentes sem recriá-los, possibilitando migrações sem tempo de inatividade provenientes do CloudFormation, do Terraform ou de recursos externos ao cluster.

Adote um recurso existente:

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: existing-bucket
  annotations:
    services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
  name: my-existing-bucket-name

Após a adoção, o recurso passa a ser gerenciado pelo ACK e pode ser atualizado por meio de manifestos do Kubernetes. Você pode realizar a migração de forma incremental, adotando recursos conforme necessário, enquanto mantém as ferramentas de IaC existentes para outros recursos.

O ACK também oferece suporte a recursos somente de leitura. Para recursos gerenciados por outras equipes ou ferramentas que você deseja referenciar, mas não modificar, combine a adoção com a política de exclusão retain e conceda permissões somente de leitura no IAM. Isso permite que as aplicações localizem infraestruturas compartilhadas (por exemplo, VPCs, perfis de funcionalidade do IAM e chaves do KMS) por meio das APIs do Kubernetes, sem o risco de modificações acidentais.

Para obter mais informações sobre a adoção de recursos, consulte Conceitos do ACK.

Políticas de exclusão

As políticas de exclusão controlam o que acontece com os recursos da AWS quando você exclui o recurso correspondente no Kubernetes. Escolha a política adequada com base no ciclo de vida do recurso e em seus requisitos operacionais.

Exclusão (padrão)

O recurso da AWS é excluído quando você exclui o recurso correspondente no Kubernetes. Isso mantém a consistência entre o cluster e a AWS, garantindo que não ocorra o acúmulo de recursos.

Situações para o uso da exclusão:

  • Ambientes de desenvolvimento e de teste nos quais a limpeza é importante

  • Recursos efêmeros vinculados ao ciclo de vida da aplicação (por exemplo, bancos de dados de teste e buckets temporários)

  • Recursos que não devem existir sem a aplicação (por exemplo filas do SQS e clusters do ElastiCache)

  • Otimização de custos com a limpeza automática de recursos não utilizados

  • Ambientes gerenciados com GitOps, nos quais a remoção do recurso no Git deve excluir a infraestrutura

A política de exclusão padrão alinha-se ao modelo declarativo do Kubernetes, ou seja, o que está no cluster corresponde ao que existe na AWS.

Reter

O recurso da AWS é mantido quando você exclui o recurso correspondente no Kubernetes. Esta opção protege dados críticos e permite que os recursos permaneçam ativos mesmo após a remoção da representação no Kubernetes.

Situações para o uso da retenção:

  • Bancos de dados de produção com dados críticos que devem ser mantidos apesar de mudanças no cluster

  • Buckets de armazenamento de longo prazo com requisitos de conformidade ou auditoria

  • Recursos compartilhados usados por diversas aplicações ou equipes

  • Recursos em processo de migração para diferentes ferramentas de gerenciamento

  • Cenários de recuperação de desastres em que você deseja preservar a infraestrutura

  • Recursos com dependências complexas que exigem uma desativação cuidadosa

apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
  name: production-db
  annotations:
    services.k8s.aws/deletion-policy: "retain"
spec:
  dbInstanceIdentifier: prod-db
  # ... configuration
Importante

Recursos retidos continuam a gerar custos na AWS e devem ser excluídos manualmente da AWS quando não forem mais necessários. Use a marcação de recursos para rastrear recursos retidos para limpeza posterior.

Para saber mais sobre as políticas de exclusão, consulte Conceitos do ACK.

Documentação original

Para obter informações detalhadas sobre o uso do ACK:

Próximas etapas