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.
Registro de clusters de destino
Registre clusters para permitir que o Argo CD implante aplicações neles. É possível registrar o mesmo cluster em que o Argo CD está em execução (cluster local) ou clusters remotos em diferentes contas ou regiões. Depois que um cluster for registrado, ele permanecerá em um estado de conexão desconhecido até que você crie uma aplicação dentro desse cluster. Para criar uma aplicação do Argo CD após o registro do cluster, consulte Criação de Applications.
Pré-requisitos
-
Um cluster de EKS com a funcionalidade para o Argo CD criada
-
kubectlconfigurado para o estabelecimento de comunicação com o cluster -
Para clusters remotos: permissões do IAM e entradas de acesso adequadas
Registro do cluster local
Para implantar aplicações no mesmo cluster em que o Argo CD está em execução, registre-o como um destino de implantação.
Importante
A funcionalidade do Argo CD não realiza o registro automático do cluster local. É necessário registrá-lo explicitamente para fazer a implantação de aplicações no mesmo cluster. É possível usar o nome in-cluster do cluster para compatibilidade com a maioria dos exemplos do Argo CD online.
nota
Uma entrada de acesso EKS é criada automaticamente para o cluster local com o perfil de funcionalidade do Argo CD, mas nenhuma permissão RBAC do Kubernetes é concedida por padrão. Isso segue o princípio do privilégio mínimo, sendo necessário configurar explicitamente as permissões que o Argo CD precisa com base no seu caso de uso. Por exemplo, se você usar esse cluster apenas como um hub do Argo CD para gerenciar clusters remotos, ele não precisará de nenhuma permissão de implantação local. Consulte a seção Requisitos de entrada de acesso do RBAC abaixo para ver as opções de configuração.
Com a CLI do Argo CD:
argocd cluster add <cluster-context-name> \ --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/my-cluster \ --name local-cluster
Com um Kubernetes Secret:
apiVersion: v1 kind: Secret metadata: name: local-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: local-cluster server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster project: default
Aplique a configuração:
kubectl apply -f local-cluster.yaml
nota
Use o ARN do cluster de EKS no campo server, e não o URL do servidor da API do Kubernetes. A funcionalidade gerenciada requer ARNs para identificar os clusters. O valor padrão kubernetes.default.svc não é compatível.
Registro de clusters remotos
Para implantar em clusters remotos:
Etapa 1: criação da entrada de acesso no cluster remoto
Substitua region-code pela região da AWS em que seu cluster remoto está, substitua remote-cluster pelo nome do cluster remoto e substitua o ARN pelo ARN do perfil da funcionalidade para o Argo CD.
aws eks create-access-entry \ --regionregion-code\ --cluster-nameremote-cluster\ --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole\ --type STANDARD
Etapa 2: associar uma política de acesso às permissões de RBAC do Kubernetes
A entrada de acesso requer permissões do Kubernetes RBAC para o Argo CD implantar aplicações. Para começar a usar rapidamente, é possível utilizar a AmazonEKSClusterAdminPolicy.
aws eks associate-access-policy \ --regionregion-code\ --cluster-nameremote-cluster\ --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole\ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster
Importante
A AmazonEKSClusterAdminPolicy fornece acesso total ao administrador do cluster (equivalente a system:masters). Isso é conveniente para começar, mas não deve ser usado em produção. Para ambientes de produção, use permissões mais restritivas associando a entrada de acesso a grupos personalizados do Kubernetes e criando associações apropriadas de Role ou ClusterRole. Consulte a seção de configuração de produção abaixo para ver a configuração de privilégios mínimos.
Etapa 3: registro do cluster no Argo CD
Com a CLI do Argo CD:
argocd cluster add <cluster-context-name> \ --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster \ --name remote-cluster
Com um Kubernetes Secret:
apiVersion: v1 kind: Secret metadata: name: remote-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster stringData: name: remote-cluster server: arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster project: default
Aplique a configuração:
kubectl apply -f remote-cluster.yaml
Clusters entre contas
Para realizar a implantação em clusters localizados em contas da AWS distintas:
-
Na conta de destino, crie uma entrada de acesso no cluster de destino do EKS usando o ARN do perfil da funcionalidade do IAM do Argo CD da conta de origem como a entidade principal
-
Associe uma política de acesso com as permissões RBAC apropriadas do Kubernetes
-
Registre o cluster no Argo CD usando o ARN do cluster de EKS
Não é necessária a criação de perfis do IAM adicionais nem a configuração de política de confiança. As entradas de acesso do EKS gerenciam o acesso entre contas.
O formato do ARN do cluster inclui a região; portanto, implantações entre regiões seguem o mesmo processo das implantações na mesma região.
Verificação do registro do cluster
Consulte os clusters que estão registrados:
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster
Como opção, verifique o status do cluster na interface do Argo CD em Configurações → Clusters.
Clusters privados
A funcionalidade do Argo CD fornece acesso transparente a clusters de EKS totalmente privados, sem exigir emparelhamento da VPC ou configurações de rede especializadas.
A AWS gerencia automaticamente a conectividade entre a funcionalidade do Argo CD e os clusters remotos privados.
Basta registrar o cluster privado usando seu ARN. Nenhuma configuração de rede adicional é necessária.
Requisitos do RBAC de entrada de acesso
Quando você cria uma funcionalidade do Argo CD, uma entrada de acesso do EKS é criada automaticamente para o perfil de funcionalidade, mas nenhuma permissão de RBAC do Kubernetes é concedida por padrão. Esse design intencional segue o princípio de privilégio mínimo, em que diferentes casos de uso exigem permissões diferentes.
Por exemplo: * Se você usar o cluster somente como um hub do Argo CD para gerenciar clusters remotos, ele não precisará de permissões de implantação locais * Se você implantar aplicações localmente, ele precisará de acesso de leitura em todo o cluster e acesso de gravação a namespaces específicos * Se for preciso criar CRDs, serão necessárias permissões adicionais de administrador de cluster
É necessário configurar explicitamente as permissões que o Argo CD precisa com base em seus requisitos.
Permissões mínimas para o Argo CD
O Argo CD precisa de dois tipos de permissões para funcionar sem erros:
Permissões de leitura (em todo o cluster): o Argo CD deve ser capaz de ler todos os tipos de recursos e definições de recursos personalizadas (CRDs) em todo o cluster para:
-
Descoberta de recursos e verificações de integridade
-
Detecção do desvio entre o estado desejado e o real
-
Validação de recursos antes da implantação
Permissões de gravação (específicas do namespace): o Argo CD precisa criar, atualizar e excluir permissões para recursos definidos em Applications:
-
Implantar workloads de aplicações (implantações, serviços, ConfigMaps etc.)
-
Aplicar recursos personalizados (CRDs específicos para suas aplicações)
-
Gerenciamento do ciclo de vida do aplicação
Configuração rápida
Para começar rapidamente, testar ou desenvolver ambientes, use a AmazonEKSClusterAdminPolicy:
aws eks associate-access-policy \ --regionregion-code\ --cluster-namemy-cluster\ --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole\ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \ --access-scope type=cluster
Importante
A AmazonEKSClusterAdminPolicy fornece acesso total ao administrador do cluster (equivalente a system:masters), incluindo a capacidade de criar CRDs, modificar recursos em todo o cluster e implantar em qualquer namespace. Isso é conveniente para desenvolvimento e POCs, mas não deve ser usado em ambientes de produção. Para produção, use a configuração de privilégios mínimos abaixo.
Configuração de produção com privilégio mínimo
Para ambientes de produção, crie um RBAC personalizado do Kubernetes que conceda:
-
Acesso de leitura em todo o cluster a todos os recursos (para descobertas e verificações de integridade)
-
Acesso de gravação específico ao namespace (para implantações)
Etapa 1: associar a entrada de acesso a um grupo de Kubernetes personalizado
aws eks associate-access-policy \ --regionregion-code\ --cluster-namemy-cluster\ --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole\ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \ --access-scope type=namespace,namespaces=app-namespace
Etapa 2: criar um ClusterRole para acesso de leitura
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: argocd-read-all rules: # Read access to all resources for discovery and health checks - apiGroups: ["*"] resources: ["*"] verbs: ["get", "list", "watch"]
Etapa 3: criar um perfil para acesso de gravação aos namespaces da aplicação
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: argocd-deploy namespace: app-namespace rules: # Full access to deploy application resources - apiGroups: ["*"] resources: ["*"] verbs: ["*"]
Etapa 4: vincular perfis ao grupo de Kubernetes
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: argocd-read-all subjects: - kind: Group name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: argocd-read-all apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: argocd-deploy namespace: app-namespace subjects: - kind: Group name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: argocd-deploy apiGroup: rbac.authorization.k8s.io
nota
O formato do nome do grupo para entradas de acesso é eks-access-entry: seguido pelo ARN principal. Repita o RoleBinding para cada namespace em que o Argo CD deva implantar aplicações.
Importante
O Argo CD deve ser capaz de ler todos os tipos de recursos em todo o cluster para verificações de integridade e descoberta, mesmo que seja implantado apenas em namespaces específicos. Sem acesso de leitura em todo o cluster, o Argo CD mostrará erros ao verificar a integridade da aplicação.
Restrição do acesso ao cluster com o Projects
Use Projects para controlar em quais clusters e namespaces as Applications podem ser implantadas configurando os clusters e namespaces de destino permitidos em spec.destinations:
apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: production namespace: argocd spec: destinations: - server: arn:aws:eks:us-west-2:111122223333:cluster/prod-cluster namespace: '*' - server: arn:aws:eks:eu-west-1:111122223333:cluster/prod-eu-cluster namespace: '*' sourceRepos: - 'https://github.com/example/production-apps'
Para obter detalhes, consulte Trabalho com o Argo CD Projects.
Recursos adicionais
-
Trabalho com o Argo CD Projects: organize as Applications e aplique limites de segurança
-
Criação de Applications: implante sua primeira aplicação
-
Uso de ApplicationSets: realize implantações em vários clusters com ApplicationSets
-
Considerações sobre o Argo CD: acesse padrões com vários clusters e a configuração entre contas
-
Declarative Cluster Setup
: acesse a referência de configuração da versão original do cluster