Fazendo o Bootstrap do Argo CD e Deixando Ele se Gerenciar Sozinho

O Argo CD tem um problema de ovo e galinha no primeiro dia. O cluster não tem nada nele, então o kubectl é a única ferramenta capaz de instalar a primeira coisa. Depois disso, você quer que o Argo CD se gerencie da mesma forma que gerencia tudo o mais. O fluxo que eu uso: 1. Um único kubectl apply de bootstrap coloca o Argo CD no cluster. Eu uso o manifest de instalação oficial fixado em uma versão, não o latest. Isso te dá o namespace, os CRDs, o controller, o repo server, o API server. 2. Assim que o Argo CD está de pé, eu aplico manualmente uma Application CR. Essa Application aponta para um diretório no repositório de manifests, algo como argocd/bootstrap. Esse diretório contém outra Application que aponta para o próprio Helm chart ou overlay do Kustomize do Argo CD. Então o Argo CD começa a sincronizar a si mesmo. 3. O mesmo diretório de bootstrap contém AppProjects, credenciais de repositório (como sealed secrets ou external secrets) e uma Application pai que aponta para argocd/applications, que guarda todas as outras Application CRs do cluster. Depois desse kubectl apply inicial, você nunca mais toca no Argo CD com kubectl. Atualizar a versão do Argo CD vira um commit no Git mudando a versão do chart ou a tag da imagem em argocd/bootstrap. Adicionar uma nova aplicação ao cluster vira um commit no Git colocando uma nova Application YAML em argocd/applications. O layout de repositório que eu mantenho para isso: argocd/ bootstrap/ # Argo CD itself, plus the root app-of-apps kustomization.yaml values.yaml # Helm values for the argo-cd chart root-app.yaml # the parent Application that points at applications/ projects/ # AppProjects: per-team or per-environment applications/ # one Application YAML per workload or per env Uma pegadinha. O Argo CD sincronizando a si mesmo pode te trancar para fora se uma mudança ruim entrar. Se o controller falhar ao subir por causa de uma mudança de configuração que você acabou de mesclar, sem controller não há reconciliação, o que significa que não há rollback via Git. Mantenha a Application de bootstrap em sync manual, ou pelo menos mantenha um commit de rollback testado à disposição. Alguns times mantêm um cluster de gerenciamento separado rodando seu próprio Argo CD que observa os Argo CDs dos clusters de carga de trabalho, para que uma instância autogerenciada quebrada ainda possa ser reparada via GitOps.