Member-only story
How I Would Design Kubernetes for 100+ Microservices
Running 100 services is easy. Letting 10 teams run them without you is the hard part.
A hundred microservices across three environments is 300 deployments. Give each one the usual Deployment, Service, HPA, PDB, ServiceAccount, ConfigMap, and ExternalSecret, and you’re managing around 2,000 Kubernetes objects before anyone writes a CronJob. Kubernetes handles that number without blinking. People don’t.
The YAML was never the hard part. At this scale, the hard part is ownership: ten teams who need to deploy, scale, debug, and secure their own services without filing a ticket with the platform team or breaking each other’s workloads. This article walks through the decisions I’d make for each layer of that platform, the failure mode behind each one, and how they fit together on EKS with Argo CD, Karpenter, and centralized observability.
Single Cluster vs Multiple Clusters
My default is one cluster per environment per region: prod, staging, and dev, plus a small management cluster for shared tooling. Not one cluster per team, and not one giant cluster for everything.
Per-team clusters sound clean until you’re upgrading ten of them every four months and maintaining ten copies of…
