Introduction to AKS-Part5

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

Overview on the series:

In this part, the topic is:

  • Advanced integration with other (Azure) services

In addition to the automatic creation of storage resources or the NSG configuration, there are numerous other integrations to Azure services and resources, some of which will be briefly discussed here.

Usage of Azure Application Gateway as Ingress

Ingress controllers are often used in a Kubernetes cluster to control traffic more granularly and implement certain rules. A common implementation is NGINX[1]. However, this leaves the resource load for the ingress controller in the cluster itself. An alternative is to use the Azure Application Gateway as the ingress controller.

The Azure Application Gateway is a Layer 7 load balancer with the option of an integrated firewall. The application gateway can also offer features such as TLS termination or URL path routing. With the Application Gateway Ingress Controller (AGIC) add-on enabled, it can be used as an ingress resource in the cluster, reduces the load in the cluster itself and can scale independently. Since the application gateway communicates directly with the pods via private IPs, it does not require node ports or KubeProxy services and thus takes additional load off the cluster. However, a CNI network is a prerequisite. Activating the add-on then creates the necessary Kubernetes Ingress resources, services and pods.[2]

Azure Application Gateway + AKS
AppGateway as Ingress [2]

With the following CLI command, the add-on can be activated in an existing cluster and the cluster is linked to an existing application gateway:

az aks enable-addons -n $aksClusterName -g $rgName -a ingress-appgw --appgw-id $appgwId

Azure Functions with KEDA

The KEDA framework has already been discussed in the Monitoring section. KEDA enables Azure Functions to be executed directly in the AKS cluster in a container. The Azure Function App must be created in container mode so that the runtime is available. After KEDA has been installed in the cluster, the function app can be loaded into the cluster, e.g. via the Function Core Tools. This process creates a manifest with deployment, ScaledObject and secrets for the environment variables from the local.settings.json file.

Again, KEDA works with the HPA to scale the function container based on events such as new messages in an Azure storage or service bus queue, using cron jobs or other triggers, as long as there is work to be done.[3]

KEDA architecture
KEDA Architecture ©KEDA

Azure Active Directory (AAD) Pod Identity

Provided that AAD integration is available for the cluster and a CNI network has been selected, AAD Pod Identity can be used for Azure resource access. It is not recommended for Kubenet due to security aspects. If the add-on is activated, again additional pods run as Deamon Sets on the nodes for the functionality. Using this approach, an identity of a pod can be linked to an identity from Azure, and the pod gets the necessary access to a cloud resource. This feature is currently only available on Linux nodes and is still in preview status[4].

Continuous Integration & Deployment

To round off the picture, the possible link to CI-CD pipelines, for example from Azure DevOps or GitHub Actions, should be mentioned here once again. A code commit, for example, triggers the automatic creation of new images that are loaded into the container repositories and make an updated version of the application available in the AKS cluster through a Helm upgrade step. Helm is a package manager for Kubernetes resources and is integrated into AKS.[5]






Leave a comment

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