Introduction to AKS-Part6

This is part nr. six of the blog series which introduces the Azure Kubernetes Service (AKS).

Overview on the series:

In this part, the topic is:

  • Cluster Architecture
  • Hints & Tricks
  • Hands-on start
  • Summary

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.[1]

AKS Cluster Architektur ©Microsoft

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:

Cluster stop:

az aks stop --name $aksClusterName --resource-group $rgName
stopped AKS Cluster

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>

generated AKS resource group


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.

AKS Cluster tutorial ©Microsoft


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[2] or the Azure App Service [3].

The new service Azure Container Apps is also worth a look.[4] To get a great overview on that, check Mohammad Nofal’s session from Azure Zurich User Group[5]

Things are developing fast! To get some insights on latest changes for example in the networking topics, watch another great session from Mo here[6]







Leave a comment

Your email address will not be published. Required fields are marked *