Escalando um repositório de manifests para muitos serviços, ambientes e clusters

Nesse tamanho, Application CRs escritos à mão são peso morto. A saída é migrar para ApplicationSets gerados a partir do layout de diretórios, empurrar as diferenças de ambiente para arquivos de parâmetros estruturados e dividir o repositório em um lado de workloads e um lado de plataforma. Três mudanças resolvem isso. Primeiro, o layout. Dois eixos: app e ambiente-ou-cluster. Eu mantenho o eixo de app como a divisão principal de diretórios porque a maioria das mudanças acontece dentro de um único app. workloads/ checkout/ base/ overlays/ dev/ staging/ preprod/ prod-us-east/ prod-eu-west/ prod-ap-south/ ledger/ base/ overlays/ ... mesma estrutura ... clusters/ dev/ config.yaml # metadados do cluster: nome, server, região, labels staging/ preprod/ prod-us-east/ prod-eu-west/ prod-ap-south/ argocd/ applicationsets/ workloads.yaml # um ApplicationSet que expande apps x envs projects/ Segundo, um único ApplicationSet faz o fan-out. Um gerador matrix combina uma lista de apps com a lista de clusters. O template produz uma Application para cada par (app, cluster). Adicionar um app novo: basta criar um diretório sob workloads/. Adicionar uma região nova: registrar o cluster e adicionar um overlay. Os dois fluxos são puro Git, sem duplicação de YAML. Terceiro, empurre as diferenças reais de ambiente para arquivos bem nomeados, não para uma parede de patches de overlay. Cada overlay guarda um values.yaml ou config.yaml com os parâmetros que mudam: número de réplicas, resource requests, sufixo de DNS, feature flags. O kustomization.yaml do overlay é uma camada fina que puxa o base, aplica alguns patches e mescla o arquivo de values em um ConfigMap. Quando alguém quer saber 'o que é diferente no eu-west prod', ela lê um único arquivo, não cinco. Coisas que dão errado nessa escala se você não planejar com antecedência: 1. Performance do Argo CD. 90 Applications fazendo polling no mesmo repositório Git fazem do seu repo server um gargalo. Habilite a integração via webhook do Git para que os commits disparem um refresh imediato em vez de cada Application fazer polling no seu próprio intervalo. Ajuste o timeout.reconciliation no argocd-cm. 2. Memória do repo server. Renderizar Kustomize ou Helm para 90 Applications consome bastante RAM. Aumente as réplicas do argocd-repo-server, dê mais memória a elas e considere rodar uma instância separada do Argo CD para os clusters de produção, para que uma tempestade de reconciliação no dev não sufoque o reconcile do prod. 3. Raio de impacto de uma mudança no base. Uma mudança em workloads/checkout/base/deployment.yaml atinge 6 ambientes de uma vez. Use sync waves e sync windows para que o prod-eu-west não sincronize no mesmo instante que o prod-us-east. Ou, para as mudanças mais arriscadas, use uma branch de release como alvo dos overlays em vez da main, para poder promover as regiões uma de cada vez. 4. Capacidade de encontrar as coisas. Com 90 Applications, a UI do Argo CD fica difícil de navegar. Use labels no template do ApplicationSet (app, env, region, team) e conte com os filtros de label da UI em vez de ficar rolando a tela. Um padrão que eu evito nesse tamanho: um repositório de manifests por cluster. Parece organizado, mas te mata na primeira vez que você precisa aplicar um patch de segurança em 6 clusters de uma vez. Um repositório, muitas Applications, geradas a partir de um único template. O drift entre regiões é o inimigo.