Skip to content
Annas Ali

Emumba · Dec 2025 – present

Multi-cluster GitOps delivery platform

One ArgoCD ApplicationSet control plane shipping a 35+ microservice AI system to 50+ EKS clusters across two regions, with zero credentials in Git.

  • EKS
  • Argo CD
  • ApplicationSets
  • Helm
  • Vault
  • GitHub Actions
  • Jenkins

The problem

The system is an enterprise AI product made of 35+ microservices, deployed to more than 50 Amazon EKS clusters. At that size, per-cluster manual steps and hand-edited manifests stop working. Every cluster needs the same baseline and its own configuration, and on-call engineers need a safe way to override one cluster during an incident without drifting the rest.

What I built

Multi-cluster GitOps delivery platformREGION · GDCREGION · RDCService reposapp code + valuesGitHub Actionspre-merge quality gatesHelm golden pathshared chart templatesGitOps config reposper-env / per-cluster overridesArgo CDApplicationSet control planeHashiCorp Vaultper-cluster secret pathsEKS clustersregional ApplicationSetEKS clustersregional ApplicationSetPRmergechartsyncAVPauthenticated gRPC
Service changes are gated in CI, merged into GitOps config repos, and fanned out by regional ApplicationSets. Secrets are resolved from Vault at sync time.
  • ArgoCD ApplicationSet control plane. One place that generates and governs the application lifecycle for every cluster. Per-cluster configuration is isolated, and there’s a controlled override pattern for incident response.
  • Helm golden path. Chart templates that service teams build on instead of writing Kubernetes YAML from scratch. Environment differences live in a per-environment override model in the GitOps config repositories.
  • Shift-left quality gates. GitHub Actions checks run before merge, so integration failures surface in the pull request rather than in a cluster.
  • Dual-region topology (GDC / RDC). Regional ApplicationSets, authenticated gRPC ingress for cross-cluster traffic, and network-level egress controls.
  • Pipeline-as-code for lifecycle operations. Jenkins deploy / upgrade / destroy pipelines with regional parameters replaced ad-hoc runbooks with version-controlled code.
  • Centralized secrets. HashiCorp Vault with the ArgoCD Vault Plugin, with per-cluster secret isolation and zero credentials in source control.

Design decisions

Generate, don’t copy. With 50+ targets, copying an Application per cluster multiplies every change. ApplicationSets make the cluster list the input and the application definition the template, so adding a cluster is a data change, not a code change.

Overrides are explicit and scoped. Incident response sometimes needs one cluster pinned or patched. Overrides live in the GitOps config repo at cluster scope, so they’re reviewed, visible in Git history, and easy to remove, instead of hot-fixes applied with kubectl that ArgoCD would fight.

Secrets resolve at sync time. Manifests reference Vault paths, never values. That keeps the config repos safe to share widely, and gives each cluster only the secrets under its own path.

Stack

EKS · Argo CD / ApplicationSets · Helm · HashiCorp Vault + ArgoCD Vault Plugin · GitHub Actions · Jenkins · gRPC ingress

Next case study

Hybrid on-prem infrastructure & secure remote access lab →