Imagine poder criar ambientes Kubernetes dedicados para cada usuário ou equipe sob demanda. Fazer isso manualmente pode ser demorado e cheio de erros. Este artigo mostra como automatizar esse processo usando ArgoCD, Sveltos e ClusterAPI. Vamos configurar um fluxo de trabalho GitOps onde adicionar um novo usuário por meio de um pull request dispara a criação automática de um cluster EKS. O ArgoCD manterá o estado desejado do nosso cluster de gerenciamento, o Sveltos detectará mudanças e orquestrará a criação do cluster, e o ClusterAPI cuidará do provisionamento de clusters EKS. Este guia oferece experiência prática na construção de um pipeline de provisionamento de clusters robusto e escalável.
O que é ArgoCD?
O Argo CD é uma ferramenta de entrega contínua (CD) de código aberto para Kubernetes. Ele automatiza a implementação, monitoramento e rollback de aplicações. Como uma ferramenta declarativa, o Argo CD utiliza os princípios de GitOps para garantir que o estado desejado de uma aplicação seja sempre refletido no estado real do cluster de gerenciamento ou de carga de trabalho do Kubernetes.
O que é Sveltos?
O Sveltos é um conjunto de controladores Kubernetes que operam dentro de um cluster de gerenciamento. A partir desse ponto central, o Sveltos gerencia add-ons e aplicações em diversos clusters Kubernetes gerenciados. Ele emprega uma abordagem declarativa, garantindo que o estado desejado seja consistentemente refletido nesses ambientes gerenciados.
O que é ClusterAPI?
O ClusterAPI (CAPI) é um subprojeto Kubernetes que traz APIs declarativas, no estilo Kubernetes, para a criação, configuração e gerenciamento de clusters. Ele permite gerenciar o ciclo de vida dos clusters Kubernetes usando a mesma abordagem declarativa utilizada para gerenciar aplicações.
Passo 1: Instalando o ClusterAPI no Cluster de Gerenciamento
Usaremos um cluster Kind como nosso cluster de gerenciamento. Para começar, precisamos implementar o ClusterAPI com o provedor de infraestrutura AWS. Primeiro, configure suas credenciais AWS:
export AWS_ACCESS_KEY_ID=<YOUR ACCESS KEY>
export AWS_SECRET_ACCESS_KEY=<YOUR SECRET ACCESS KEY>
clusterawsadm bootstrap iam create-cloudformation-stack --region us-east-1
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
Em seguida, inicialize o ClusterAPI:
export AWS_REGION=us-east-1
export EKS=true
export EXP_MACHINE_POOL=true
export CAPA_EKS_IAM=true
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.large
export AWS_NODE_MACHINE_TYPE=t3.large
export AWS_REGION=us-east-1
export AWS_SSH_KEY_NAME=capi-eks
clusterctl init --infrastructure aws
Passo 2: Instalando o ArgoCD no Cluster de Gerenciamento
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl config set-context --current --namespace=argocd
kubectl port-forward svc/argocd-server -n argocd 8080:443
A senha de administrador para se conectar ao painel do ArgoCD está no Secret chamado argocd-initial-admin-secret no namespace argocd.
Passo 3: Implementando o Sveltos
Usaremos o Argo CD para automatizar a implementação do Sveltos no seu cluster Kubernetes de gerenciamento.
argocd app create sveltos --repo https://github.com/projectsveltos/helm-charts.git --path charts/projectsveltos --dest-server https://kubernetes.default.svc --dest-namespace projectsveltos
Isso direciona o Argo CD para criar uma aplicação chamada sveltos, recuperando o gráfico Helm do Sveltos do repositório GitHub especificado e implementando-o no namespace projectsveltos dentro do cluster de gerenciamento. Em seguida, implementaremos as configurações do Sveltos usando o Argo CD.
argocd app create sveltos-configuration --repo https://github.com/gianlucam76/devops-tutorial.git --path argocd-sveltos-clusterapi-eks --dest-server https://kubernetes.default.svc
A configuração do Sveltos que estamos implementando estabelece um processo dinâmico de criação de cluster. Primeiro, ele monitora um ConfigMap chamado existing-users dentro do namespace default. Este ConfigMap mantém uma lista de usuários, cada entrada formatada como user-id: cluster-type, onde cluster-type designa production ou staging. Posteriormente, sempre que uma nova entrada de usuário é detectada neste ConfigMap, o Sveltos aciona a implementação de uma configuração ClusterAPI, que, por sua vez, inicia a criação de um novo cluster EKS. É importante ressaltar que cada novo cluster criado será rotulado com type:cluster-type, permitindo que o Sveltos aplique imediatamente a configuração apropriada, seja para ambientes de produção ou de staging, com base no rótulo do cluster.
Antes de prosseguirmos, rotule o cluster de gerenciamento com type: mgmt.
kubectl label sveltoscluster -n mgmt mgmt type=mgmt
Passo 4: Enviando um PR para adicionar um novo usuário
Para adicionar um novo usuário e acionar a criação de um cluster EKS correspondente, implementaremos um fluxo de trabalho GitOps direto. Primeiro, enviaremos um pull request (PR) que modifica o ConfigMap existing-users.yaml dentro do nosso repositório. Especificamente, este PR irá introduzir uma nova entrada de usuário, user1: production, dentro da seção de dados do ConfigMap, como mostrado no diff fornecido. Uma vez que o PR seja integrado, instruiremos o Argo CD a sincronizar essas mudanças com o cluster de gerenciamento. Essa sincronização aplicará o ConfigMap atualizado, sinalizando ao Sveltos para iniciar o provisionamento de clusters EKS para “user1” impulsionado pelo ClusterAPI.
diff --git a/argocd-sveltos-clusterapi-eks/existing-users.yaml b/argocd-sveltos-clusterapi-eks/existing-users.yaml
index ab0d862..10987b3 100644
--- a/argocd-sveltos-clusterapi-eks/existing-users.yaml
+++ b/argocd-sveltos-clusterapi-eks/existing-users.yaml
@@ -3,3 +3,5 @@ kind: ConfigMap
metadata:
name: existing-users
namespace: default
+data:
+ user1: production
Passo 5: Sveltos Aciona a Criação de um Novo Cluster EKS
O Sveltos detectará imediatamente a nova entrada de usuário, user1: production. Essa detecção aciona o Sveltos para implementar todos os recursos ClusterAPI necessários no cluster de gerenciamento, orquestrando efetivamente a criação de um novo cluster EKS. A execução de sveltosctl show addons revelará os recursos implementados, conforme mostrado abaixo:
sveltosctl show addons
+-----------+-------------------------------------------------------+-----------+------------------------------+---------+-------------------------------+---------------------------------+
| CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
+-----------+-------------------------------------------------------+-----------+------------------------------+---------+-------------------------------+---------------------------------+
| mgmt/mgmt | cluster.x-k8s.io:Cluster | user1 | capi-eks-user1 | N/A | 2025-03-04 12:10:02 +0100 CET | ClusterProfile/deploy-resources |
| mgmt/mgmt | infrastructure.cluster.x-k8s.io:AWSManagedCluster | user1 | capi-eks-user1 | N/A | 2025-03-04 12:10:02 +0100 CET | ClusterProfile/deploy-resources |
| mgmt/mgmt | controlplane.cluster.x-k8s.io:AWSManagedControlPlane | user1 | capi-eks-control-plane-user1 | N/A | 2025-03-04 12:10:02 +0100 CET | ClusterProfile/deploy-resources |
| mgmt/mgmt | cluster.x-k8s.io:MachinePool | user1 | capi-eks-pool-0-user1 | N/A | 2025-03-04 12:10:02 +0100 CET | ClusterProfile/deploy-resources |
| mgmt/mgmt | infrastructure.cluster.x-k8s.io:AWSManagedMachinePool | user1 | capi-eks-pool-0-user1 | N/A | 2025-03-04 12:10:02 +0100 CET | ClusterProfile/deploy-resources |
+-----------+-------------------------------------------------------+-----------+------------------------------+---------+-------------------------------+---------------------------------+
Passo 6: Sveltos Implementa Políticas de Produção
Depois que o ClusterAPI concluir o provisionamento de clusters EKS, o Sveltos implementará automaticamente os add-ons configurados para um ambiente de produção. Esta implementação inclui:
- O gráfico Helm cert-manager, para gerenciar e emitir certificados TLS.
- O gráfico Helm kyverno, para controle baseado em políticas de recursos Kubernetes.
- Os gráficos Helm prometheus e grafana, para fornecer recursos de monitoramento e visualização.
- Uma política de admissão kyverno especificamente configurada para disallow-latest-tag, aplicando o uso de tags de imagem explícitas para implementações de contêineres.
sveltosctl show addons --namespace=user1
+----------------------+--------------------------+--------------+---------------------+---------+-------------------------------+------------------------------------------+
| CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
+----------------------+--------------------------+--------------+---------------------+---------+-------------------------------+------------------------------------------+
| user1/capi-eks-user1 | helm chart | cert-manager | cert-manager | v1.16.3 | 2025-03-04 12:28:00 +0100 CET | ClusterProfile/deploy-cert-manager |
| user1/capi-eks-user1 | helm chart | prometheus | prometheus | 26.0.0 | 2025-03-04 12:29:20 +0100 CET | ClusterProfile/prometheus-grafana |
| user1/capi-eks-user1 | helm chart | grafana | grafana | 8.6.4 | 2025-03-04 12:29:29 +0100 CET | ClusterProfile/prometheus-grafana |
| user1/capi-eks-user1 | helm chart | kyverno | kyverno-latest | 3.3.4 | 2025-03-04 12:28:50 +0100 CET | ClusterProfile/deploy-kyverno-production |
| user1/capi-eks-user1 | kyverno.io:ClusterPolicy | | disallow-latest-tag | N/A | 2025-03-04 12:29:19 +0100 CET | ClusterProfile/deploy-kyverno-resources |
+----------------------+--------------------------+--------------+---------------------+---------+-------------------------------+------------------------------------------+
Passo 7: Removendo o Usuário
Assim como criamos um cluster adicionando um usuário, podemos remover um usuário e, consequentemente, excluir seu cluster EKS associado. Isso é feito através do mesmo fluxo de trabalho GitOps, mas ao contrário.
Para remover um usuário, simplesmente enviamos um pull request (PR) que remove a entrada do usuário do ConfigMap existing-users.yaml. Por exemplo, para remover user1, reverteríamos as mudanças feitas no Passo 4. Uma vez que este PR seja integrado e o Argo CD sincronize as mudanças com o cluster de gerenciamento, o Sveltos detecta a remoção do usuário do ConfigMap.
O Sveltos, ao detectar essa mudança, procede a excluir todos os recursos ClusterAPI que havia implementado anteriormente para aquele usuário. Isso inclui os recursos Cluster, AWSManagedCluster, AWSManagedControlPlane, MachinePool e AWSManagedMachinePool dentro do namespace do usuário (neste caso, “user1”).
Como o ClusterAPI opera de forma declarativa, excluir esses recursos ClusterAPI aciona a exclusão do cluster EKS subjacente. O provedor de infraestrutura AWS do ClusterAPI interpreta a remoção desses recursos como um pedido para encerrar os recursos de nuvem correspondentes.
Portanto, simplesmente removendo a entrada do usuário do ConfigMap existing-users.yaml e permitindo que o Argo CD e o Sveltos sincronizem as mudanças, automatizamos efetivamente todo o ciclo de vida do cluster EKS, desde a criação até a exclusão. Isso garante que os recursos sejam gerenciados de forma eficiente e que clusters órfãos sejam evitados, mantendo um ambiente limpo e econômico.
Este tutorial demonstrou como construir um pipeline totalmente automatizado, orientado por GitOps, para o provisionamento de clusters EKS sob demanda. Ao aproveitar o poder do Argo CD, Sveltos e ClusterAPI, estabelecemos uma solução robusta e escalável que elimina o esforço manual e os potenciais erros associados ao gerenciamento de clusters tradicional. Vimos como:
- Argo CD mantém o estado desejado do nosso cluster de gerenciamento, garantindo que todas as configurações sejam sincronizadas com nosso repositório Git.
- Sveltos atua como um orquestrador dinâmico, detectando mudanças na nossa configuração de usuário e acionando a criação de novos clusters EKS.
- ClusterAPI lida com o trabalho pesado de provisionamento de clusters EKS e gerenciamento dos próprios clusters EKS, fornecendo uma abordagem consistente e declarativa.
Este conteúdo foi auxiliado por Inteligência Artificiado, mas escrito e revisado por um humano.
Via dev.to