Azure Container Services (AKS) - Exposing containers to other VNET resources

1
votes

I am using Azure Container Services (AKS - not ACS) to stand up some API's - some of which are for public consumption, some of which are not.

For the public access route everything is as you might expect, a load-balancer service bound to a public IP is created, DNS zone contains our A record forwarding to the public IP, traffic is routed through to an NGINX controller and then onwards to the correct internal service endpoints.

Currently the preview version assigns a new VNET to place the AKS resource group within, moving forwards I will place the AKS instance inside an already existing VNET which houses other components (App Services, on an App Service Environment).

My question is how to grant access to the private APIs to other components inside the same VNET, as well as components in other VNETS?

I believe AKS supports an ILB-type load balancer, which I think might be what is required for routing traffic from other VNETS? But what about where the components reside already inside the same VNET?

Thank you in advance!

1
azurekubernetesazure-container-servicevnet
Hi, If the components resides in the same cluster you can use the internal k8s DNS. you can check out the following link dns-pod&services - Suresh Vishnoi
hey - yes understood, if the other components are inside the same AKS cluster I resolve them by kube-dns already, however the other components in this instance are actually Azure App Services - hosted inside a VNET (the same VNET as the AKS instance will be in) - watdo
Hi, Hmm alright.Perhaps Egress rule might be useful here. - Suresh Vishnoi

1 Answers

1
votes

If you need to access these services from other services outside the AKS cluster, you still need an ILB to load balance across your service on the different nodes in your cluster. You can either use the ILB created by using the annotation in your service. The alternative is using NodePort and then stringing up your own way to spread the traffic across all the nodes that host the endpoints.

I would use ILB instead of trying to make your own using NodePort service types. The only thing would be perhaps using some type of API Gateway VM inside your vnet where you can define the backend Pool, that may be a solution if you are hosting API's or something through a 3rd party API Gateway hosted on an Azure VM in the same VNet.

Eddie Villalba MCSD: Azure Solutions Architect | CKA: Certified Kubernetes Administrator