A deployment of AKS-hosted workloads typically requires a separation of duties and lifecycle management in different areas, such as prerequisites, the host network, the cluster infrastructure, the shared services and finally the workload itself. This reference implementation is no different. Also, be aware that our primary purpose is to illustrate the topology and decisions involved in the deployment of an AKS cluster. We feel a "step-by-step" flow will help you learn the pieces of the solution and will give you insight into the relationship between them. Ultimately, lifecycle/SDLC management of your cluster and its dependencies will depend on your situation (organizational structures, standards, processes and tools), and will be implemented as appropriate for your needs.
There are various ways to secure your AKS cluster. From a network security perspective, these can be classified into securing the control plane and securing the workload. When it comes to securing the control plane, one of the best ways to do that is by using a private cluster, where the control plane or API server has internal IP addresses that are defined in the RFC1918 - Address Allocation for Private Internet document. By using a private cluster, you can ensure network traffic between your API server and your node pools remains on the private network only. For more details about private clusters, check out the documentation.
When using a private cluster, the control plane can only be accessed from computers in the private network or peered networks. For this reason, in this reference implementation, we will be deploying a virtual machine in the Hub network through which we can connect to the control plane.
By the end of this, you would have deployed a secure AKS cluster, compliant with AKS Landing Zone Accelerator guidance and best practices. We will also be deploying a workload known as the Ratings app. Check out the Introduction to Kubernetes on Azure Training path on Microsoft Learn for some intermediate level training on AKS.
For this scenario, we have various IaC technology that you can choose from depending on your preference. At this time only the Terraform and Bicep versions are available. Below is an architectural diagram of this scenario.
- AKS Private Cluster
- Azure Virtual Networks (hub-spoke)
- Azure Firewall managed egress
- Azure Application Gateway (WAF)
- Application Gateway Ingress Controller
- AKS-managed Internal Load Balancer
- Azure CNI
- Azure Keyvault
- Azure Container registry
- Azure Bastion
- Azure Monitor for containers
- Azure firewall
- MongoDB
- Helm
- Secret store CSI driver
- Azure RBAC for Kubernetes Authorization
- Microsoft Entra pod-managed identities
- Horizontal Pod Autoscaling
- Cluster Autoscaling
- Readiness/Liveness Probes
- Azure Service Bus
- Azure CosmosDb
- Azure MongoDb
- Azure Redis Cache
A video explaining the architecture used for AKS Landing Zone is available here: https://www.youtube.com/watch?v=vwGo9tZPngU&list=PLpbcUe4chE79sB7Jg7B4z3HytqUUEwcNE
Pick one of the IaC options below and follow the instructions to deploy the AKS reference implementation.