In the prior step, you've set up a Microsoft Entra tenant to fullfil your deployed share resources needs for this reference implementation deployment. Now we will start with the network resources.
This reference implementation is split across several resource groups in a single subscription. This is to replicate the fact that many organizations will split certain responsibilities into specialized subscriptions (such as regional hubs/VWAN in a Connectivity subscription and workloads in landing zone subscriptions). We expect you to explore this reference implementation within a single subscription, but when you implement this cluster at your organization, you will need to take what you've learned here and apply it to your expected subscription and resource group topology (such as those offered by the Cloud Adoption Framework.) This single subscription, multiple resource group model is for simplicity of demonstration purposes only.
The following two resource groups will be created and populated with networking resources in the following steps.
| Name | Purpose |
|---|---|
rg-enterprise-networking-hubs |
Contains all of your organization's regional hubs. A regional hubs include an egress firewall and Log Analytics for network logging. |
rg-enterprise-networking-spokes |
Contains all of your organization's regional spokes and related networking resources. All spokes will peer with their regional hub and subnets will egress through the regional firewall in the hub. |
- Regional Azure Firewall in each hub Virtual Network
- One network spoke per cluster
- Network Peering from the spokes to their corresponding regional hub
- Force tunnel UDR for cluster subnets to their hubs
- Network Security Groups for all subnets that support them
-
Create the networking hub-spoke resource groups.
📖 The networking team has all their regional networking hubs and spokes in the following centrally-managed Azure Resource Groups.
az group create -n rg-enterprise-networking-hubs -l centralus az group create -n rg-enterprise-networking-spokes -l centralus
💡 The groups' default location does not matter, as it's not tied to the resource locations. (These resource groups would have typically already existed.)
-
Create two hubs, and two spokes that will be home to the AKS clusters and its adjacent resources and then enroll the spokes into the hubs.
📖 The networking team had created two generic hubs awaiting for customers to join. They receive a request from an app team in business unit (BU) 0001. This is for the creation of network spokes to house their new AKS-based application (Internally know as Application ID: A0042). The network team talks with the app team to understand their requirements and aligns those needs with Microsoft's best practices for a secure AKS cluster deployment. As part of the non-functional requirements, the app team mentions they need to run two separate infrastructure instances of the same application from two different regions, so they can increase the availability. The networking team realizes they are going to need two different spokes to fulfil the app team's requirements. They capture those specific requirements and deploy the spokes (
BU0001A0042-03andBU0001A0042-04), aligning to those specs, and connecting it to the corresponding regional hub.The networking team has decided that
10.200.[0-9].0will be where all regional hubs are homed on their organization's network space. Theeastus2andwestus2hubs (created below) will be10.200.3.0/24and10.200.4.0/24respectively.Note: The subnets for Azure Bastion and cross-premises connectivity are deployed in this reference architecture, but the resources are not deployed. Since this reference implementation is expected to be deployed isolated from existing infrastructure; these IP addresses should not conflict with any existing networking you have, even if those IP addresses overlap. If you need to connect the reference implementation to existing networks, you will need to adjust the IP space as per your requirements as to not conflict in the reference ARM templates.
The Azure Firewall Base Policies for the Contoso organization were created by the networking team as another shared resource. This way, they became available for each regional cluster that requires inherit them and create children Azure Firewall Policy rules on top of. An important Azure Resource Manager requirement at the time writing this is that all derivative Azure Firewall Policies must reside on the same parent's location.
# [Creating the generic hubs takes about ten minutes to run (each).] BASE_FIREWALL_POLICIES_ID=$(az deployment group show -g $SHARED_RESOURCE_GROUP_NAME_AKS_MRB -n shared-svcs-stamp --query properties.outputs.baseFirewallPoliciesId.value -o tsv) echo BASE_FIREWALL_POLICIES_ID: $BASE_FIREWALL_POLICIES_ID az deployment group create -g rg-enterprise-networking-hubs -f networking/hub-region.v1.json -n hub-regionA -p baseFirewallPoliciesId=$BASE_FIREWALL_POLICIES_ID firewallPolicyLocation=eastus2 @networking/hub-region.parameters.eastus2.json az deployment group create -g rg-enterprise-networking-hubs -f networking/hub-region.v1.json -n hub-regionB -p baseFirewallPoliciesId=$BASE_FIREWALL_POLICIES_ID firewallPolicyLocation=eastus2 @networking/hub-region.parameters.centralus.json # [Creating the spokes takes about ten minutes to run.] RESOURCEID_VNET_HUB_REGIONA=$(az deployment group show -g rg-enterprise-networking-hubs -n hub-regionA --query properties.outputs.hubVnetId.value -o tsv) RESOURCEID_VNET_HUB_REGIONB=$(az deployment group show -g rg-enterprise-networking-hubs -n hub-regionB --query properties.outputs.hubVnetId.value -o tsv) echo RESOURCEID_VNET_HUB_REGIONA: $RESOURCEID_VNET_HUB_REGIONA echo RESOURCEID_VNET_HUB_REGIONB: $RESOURCEID_VNET_HUB_REGIONB az deployment group create -g rg-enterprise-networking-spokes -f networking/spoke-BU0001A0042.json -n spoke-BU0001A0042-03 -p hubVnetResourceId="${RESOURCEID_VNET_HUB_REGIONA}" @networking/spoke-BU0001A0042.parameters.eastus2.json az deployment group create -g rg-enterprise-networking-spokes -f networking/spoke-BU0001A0042.json -n spoke-BU0001A0042-04 -p hubVnetResourceId="${RESOURCEID_VNET_HUB_REGIONB}" @networking/spoke-BU0001A0042.parameters.centralus.json # [Enrolling the spokes into the hubs takes about ten minutes to run (each).] RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_03=$(az deployment group show -g rg-enterprise-networking-spokes -n spoke-BU0001A0042-03 --query properties.outputs.nodepoolSubnetResourceIds.value -o tsv) RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_04=$(az deployment group show -g rg-enterprise-networking-spokes -n spoke-BU0001A0042-04 --query properties.outputs.nodepoolSubnetResourceIds.value -o tsv) echo RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_03: $RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_03 echo RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_04: $RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_04 az deployment group create -g rg-enterprise-networking-hubs -f networking/hub-region.v1.1.json -n hub-regionA -p nodepoolSubnetResourceIds="['${RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_03}']" baseFirewallPoliciesId=$BASE_FIREWALL_POLICIES_ID firewallPolicyLocation=eastus2 @networking/hub-region.parameters.eastus2.json az deployment group create -g rg-enterprise-networking-hubs -f networking/hub-region.v1.1.json -n hub-regionB -p nodepoolSubnetResourceIds="['${RESOURCEID_SUBNET_NODEPOOLS_BU0001A0042_04}']" baseFirewallPoliciesId=$BASE_FIREWALL_POLICIES_ID firewallPolicyLocation=eastus2 @networking/hub-region.parameters.centralus.json
The AKS baseline has already covered the hows and whys of the current network topology segmentation. Something to remember while preparing for an active/active architecture is that the network needs to be right-sized to absorb a sudden increase in traffic that might request twice the number of IPs when scheduling more pods to handle failover of a region.