This is part nr. six of the blog series which introduces the Azure Kubernetes Service (AKS).
Overview on the series:
- AKS Part 1 – general terms and availability options
- AKS Part 2 – network, storage and tools
- AKS Part 3 – security topics
- AKS Part 4 – scaling and monitoring
- AKS Part 5 – advanced integration with other services
- AKS Part 6 – cluster architecture, hints & tricks and hands-on
In this part, the topic is:
- Cluster Architecture
- Hints & Tricks
- Hands-on start
The figure down illustrates the structure of an example microservice architecture using an AKS cluster. The various services are implemented by containers in pods, but databases are often located outside the cluster to simplify a stateless architecture. It is generally recommended to store data rather in PaaS services that support multi-region replication. NGINX is used as the ingress controller, and a load balancer routes Internet traffic to the ingress. The AAD is connected as an identity provider and secrets are stored in the Azure Key Vault. Updates of the applications are carried out via CI/CD pipelines, images are pushed into the container registry, and they are pooled from the cluster after a Helm upgrade command.
Hints, tricks & hands-on
If a cluster is not productive and is not needed permanently, but should also not be re-provisioned every time it is used, it can be stopped. This means that all worker nodes are deallocated and no longer incur (CPU) costs. Only the costs for network resources and storage remain. This can be achieved in the Azure Portal and by the following CLI command:
az aks stop --name $aksClusterName --resource-group $rgName
To restart the cluster, the following command is sufficient:
az aks start --name $aksClusterName --resource-group $rgName
- When creating the node pools, virtual machines with standard HDDs cannot be taken.
- With the CNI network type, IP address planning should definitely not be underestimated. Each pod needs an address and subsequent changes to address ranges can become difficult or practically impossible. Therefore, the amount of workloads in the cluster should be estimated as well as possible and taken into account when defining the address ranges.
It is also a good idea to define and staff specific processes and roles, such as a Cluster Admin or an AKS Team. Although AKS can support in many areas, it cannot replace a good operational base.
The resources, which are created by the AKS, can be found in another, automatically generated resource group according to the scheme: MC_<Resourcegroupe AKS>_<Cluster Name> _<Region>
If you would like to experience hands-on with a good tutorial, you can do so at the following address:
The example builds an AKS cluster step by step and covers topics such as scaling, ingress, certificate management and monitoring.
If you want to host a multi-container application with Kubernetes, AKS is a service that offers a lot of support compared to an in-house Kubernetes landscape and reduces the effort required for setup and operation. Those who want to run simpler container architectures in the Azure Cloud may be better off with Azure Container Instances or the Azure App Service .
The new service Azure Container Apps is also worth a look. To get a great overview on that, check Mohammad Nofal’s session from Azure Zurich User Group
Things are developing fast! To get some insights on latest changes for example in the networking topics, watch another great session from Mo here