Service Mesh Platform · View 01 of 31 · 1 · Context and scope
Decisions
- The mesh owns the east-west path only. North-south ingress is a caller: it hands the mesh admitted traffic, and the mesh treats the edge gateway as one more workload with its own identity.
- Kubernetes is drawn outside. The mesh reads pods and endpoints and never schedules anything, so a scheduling incident and a mesh incident have different owners and different runbooks.
- The root CA is an authority the mesh visits once a year, not a service it calls. It is offline, and nothing on this page can reach it over a network.
Assumptions
- Three data centres, 20 clusters, 600 services and 12,000 proxies at launch, rising to 2,000 services and 40,000 proxies. All figures are the requirement's stated assumptions.
- The requirement names AWS. This design runs the same problem on hardware the organisation owns with open-source software only; section-by-section mappings are in the README.
Deliberately out
- Workload scheduling, the north-south edge, application-level user authentication and service-to-database traffic that does not pass through a sidecar.