## Description This reference architecture details how to run multiple instances of an Azure Kubernetes Service (AKS) cluster across multiple regions in an active/active and highly available configuration. **N.B:** - The Terraform code is automatically generated with best practices and contains variables that you can customize to fir your needs. - You have full control to change, add, delete resources or their configuration. The newly generated code will reflect these changes. - You can replace some resources with Terraform modules. > terraform apply status: successful > ## Architecture components Many components and Azure services are used in the multi-region AKS reference architecture. Only those components with uniqueness to this multi-cluster architecture are listed here. For the remaining, refer to the AKS Baseline architecture. - Regional AKS clusters: Multiple AKS clusters are deployed, each in a separate Azure region. During normal operations, network traffic is routed between all regions. If one region becomes unavailable, traffic is routed to a region closest to the user who issued the request. - Regional hub-spoke networks: A regional hub-spoke network pair is deployed for each regional AKS instance. Azure Firewall Manager policies are used to manage firewall policies across all regions. - Regional key vault: Azure Key Vault is provisioned in each region. Key vaults are used for storing sensitive values and keys specific to the AKS cluster and supporting services that are in that region. - Multiple log workspaces: Regional Log Analytics workspaces are used for storing regional networking metrics and diagnostic logs. Additionally, a shared Log Analytics instance is used to store metrics and diagnostic logs for all AKS instances. - Global Azure Front Door profile: Azure Front Door is used to load balance and route traffic to a regional Azure Application Gateway instance, which sits in front of each AKS cluster. Azure Front Door allows for layer 7 global routing, both of which are required for this reference architecture. - Global container registry: The container images for the workload are stored in a managed container registry. In this architecture, a single Azure Container Registry is used for all Kubernetes instances in the cluster. Geo-replication for Azure Container Registry enables replicating images to the selected Azure regions and providing continued access to images even if a region is experiencing an outage. ## Requirements | Name | Configuration | | --- | --- | | Terraform | all versions | | Provider | Azure | | Provider version | >= 5.10.8.0 | | Access | Admin access | ## How to use the architecture Clone the architecture and modify the following variables according to your needs: | Variable | Description | | --- | --- | | custom_domain_hostname | Hostname for the DNS zone | | frontdoor_domain | Domain name of the frontdoor | | location_a | Primary location where resources will be deployed | | location_a_app_cidr | The address prefix of the application subnet | | location_a_cluster_cidr | The address prefix of the kubernetes cluster subnet | | location_a_vnet | The address prefix of the virtual network in location A | | location_b | Secondary location where resources will be deployed | | location_b_app_cidr | The address prefix of the application subnet in the second location | | location_b_cluster_cidr | The address prefix of the kubernetes cluster subnet in the second location | | location_b_vnet | The address prefix of the virtual network in location B | | tags | Tags that will be applied to all resources | **N.B:** - Feel free to remove the resources that are not relevant to your use-case. - Some variables have default values, please change it if it doesn't fit your deployment. ## Maintainer(s) You can reach out to these maintainers if you need help or assistance: - [Brainboard team](mailto:support@brainboard.co)