1. Start here

1.1 Overview

Requirements: R1, R2, R4, R7, R19.

Hub-and-spoke landing zone with one hub per exposure and internal and external workloads in separate subscriptions and clusters. What the picture does not show: the internal hub’s Firewall inspects all egress and east-west traffic, and the hub also holds Bastion. With no gateway in the external hub and no peering between the hubs, the clusters the Internet reaches have no path to the corporate network at all. The management VNet hosts jump hosts and CI/CD agents; peering is not transitive, so it joins nothing, and it is the only place the Kubernetes API can be reached from. Every cluster of the fleet - stateless or stateful, internal or external - has this same inner layout; how the clusters are placed in the frontend and backend networks is shown in picture 3.1. External zones are reached on a public load balancer of the zone’s gateway in every cell, with Azure Traffic Manager choosing the cell by DNS; internal zones directly at the zone’s gateway in the cell that hosts the application (private DNS kept up to date by ExternalDNS). In both cases the traffic ends at the zone’s gateway in a stateless cluster - the stateful cluster is never reached from outside the platform.