Christos Polydorou

In some of the previous articles of this blog, we went through the process of installing NGINX as the Ingress Controller in AKS clusters. Either for applications that should be available directly from the public internet, or for applications that should only be accessed from networks considered internal. In the majority of the cases, however, and given that an AKS cluster is an environment that is designed to host multiple applications and provide economy at scale, additional ingress controllers may be required. In this post, we're going to go through the process of deploying an additional NGINX ingress controller that is going to be used for internal applications. The below diagram depicts the desired outcome: The Angular application is published via the public NGINX through the Azure Load Balancer that has been assigned a public IP. The .NET app is published by a different set of NGINX pods that are deployed in a different namespace and their ingress controller service is connect...

In one of the previous posts, we used NGINX as the ingress controller in Azure Kubernetes Service, to publish applications and services running in the cluster (article is available here ). In that deployment, NGINX was using a public IP for the ingress service, something that may not be suitable for services that should be kept private or protected by another solution. In today's post, we're going to deploy NGINX in a way that the ingress service uses a private IP, from the same vNet that the cluster is built on top. Following the usual steps of logging in and selecting the subscription to use in Azure CLI, you just have to execute the deployment script that will deploy the main.bicep file and all of its sub-resources to create the AKS platform on Azure. The next step would be to get the credentials for the cluster using the  az aks get-credentials command, as shown in the getAKSCredentials.sh  script, in order to connect with using the kubectl tool. If you get the services ...

In a Kubernetes cluster, the resources we deploy are assigned IPs from the cluster's network that makes them unreachable from other networks. The most common way to expose an app to the world outside the cluster is to create a service. The service will load balance the traffic across pods and will also bridge the gap between the two worlds (cluster and outside network) using a concept much like NAT. This, however, does now allow us control over how the app is published, from which pods, etc. This is where ingress controllers come into play. An ingress controller is a way to publish apps having full control on how each and every component is being accessed. Compared to traditional application deployment, we could say that the role and functionality of the ingress controller are much like those of application delivery controllers such as Citrix ADC and F5 BigIP.  The below diagram shows the basic functionality of an ingress controller: In this example, we have three namespaces config...