Connecting AKS and Web App with VNet integration - azure

I'm trying to connect my Web App to the AKS LoadBalancer through the VNet integration instead of a public load balancer.
The problem here is to integrate VNet into the web app, the VNet needs to have a subnet delegated to Microsoft.Web/serverFarms. On the other hand, AKS cannot be assigned with a subnet that has a delegation.
I have found this that seemingly has done the exact same thing but it seems to be old as I cannot reproduce the same result. Either I get
VNET aks-subnet is missing a delegation to Microsoft.Web/serverFarms. Please add the delegation and try again. or aks-subnet cannot be used as it's a delegated subnet
I have tried to add two subnets one with delegation to managedClusters and use that for my AKS but the same ... cannot be used as it's a delegated subnet happens.
sidenote: I'm using the bicep script to deploy.

VNET Integration requires a dedicated subnet for the App Service that is going to be integrated. This means the subnet cannot be used for any other purpose, i.E. hosting AKS or VMs.
The App Service can then reach services in other subnets on the same VNET or in peered VNETs.
Subnet Size Requirements are a minimum of /27 and Microsoft recommends /26 for production grade environments.
It is sometimes a little tricky to troubleshoot issues with VNET integration, some good hints are documented here.

Related

Why Azure app service VNET integration failing with new subnet?

I'm trying to connect my app service plan in to VNET. But always failed. I have red threads and everywhere saying App service plan should be Standard or higher.
My App service Plan is S1.
It's just an empty app.
I'm creating new subnet (not select existing one) when configuring VNET.
I have run the trouble-shooter and no issue found with connectivity
Can someone help on this?
There are some limitations with using regional virtual network integration:
Refer MsDoc
If you have already one VNet associated with an app service plan, it would be better if you create a new app service plan and then configure the VNet. I found the same fix here by #Asish Punnose.
"App service plan, VNet as well as App" should be in the same region.
The integration subnet can only use one App Service plan
After considering all the above limitations, I was able to configure VNet successfully.
By adding a new subnet, enabling inbound & outbound traffic addresses with a new virtual network as well as new app service plan I could create an app with standard s1 plan.
Added subnets under VNet integration:
Configured VNet with an app service plan without any error:
Issue was my VNET and App service in different subscription .
But in same region. move app service in to other subscription which contains VNET. Problem solved.
Seems to be VNET integration not working between Resorces in multipole subscriptions .Cheers

How to add user route to Azure App Services

I have an Azure VM with inside custom vpn to 172.254.254.0/24 route.
I am able to reach that VM from another azure VM adding an "user route" to a "route table" in that VM. It works perfectly.
Now I have an Azure App Services web application.
I need to add the route above too.
But I am stuck I am not able to do it.
Integrate your app with an Azure Virtual Network
The VNet Integration feature has two variations.
Regional VNet Integration - When connecting to Resource Manager VNets in the same region, you must have a dedicated subnet in the VNet you are integrating with.
Gateway required VNet Integration - When connecting to VNets in other regions or to a Classic VNet in the same region you need a Virtual Network gateway provisioned in the target VNet.
Gateway required VNet Integration only provides access to resources in the target VNet or in networks connected to the target VNet with peering or VPNs. Gateway required VNet Integration doesn't enable access to resources available across ExpressRoute connections or works with service endpoints.
Refer: https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet#enable-vnet-integration

Connecting App Service to Load Balanced cluster in different Resource Groups

I have 2 separate resource groups in Azure:
Contains some Services including a Linux App Service hosting Python Django
Contains an ElasticSearch cluster which I created using the ARM template from here
I want to connect from the App service in (1) to the ElasticSearch service load balancer in (2)
I tried to create a virtual network peering using
az network vnet peering create -g $webResourceGroup -n web2es --vnet-name vnet --remote-vnet $remote_vnet --allow-vnet-access
where $webResourceGroup => (1) and $remote_vnet => (2)
However, when I try to do an HTTP request to the ElasticSearch Service, it just does not work.
How do I fix or troubleshoot this?
There are some requirements and constraints for virtual network peering.
Resources in one virtual network cannot communicate with the front-end
IP address of a Basic internal load balancer in a globally peered
virtual network. Support for Basic Load Balancer only exists within
the same region. Support for Standard Load Balancer exists for both,
VNet Peering and Global VNet Peering. Services that use a Basic load
balancer which will not work over Global VNet Peering are documented
here.
So, if the peered VNets are in a different region, you cannot connect to resources that are behind a Basic Load Balancer through the Front End IP of the Load Balancer. This restriction does not exist for a Standard Load Balancer. From the parameters, you will see that loadBalancerInternalSku or loadBalancerExternalSku is by default basic, you should use a standard load balancer.
Also, you should have integrated your app with an Azure Virtual Network. Please note that you cannot reach resources across global peering connections(VNets are located in different regions) when you are using Regional VNet Integration which requires the app and the VNet must be in the same region. If so, you need to use Gateway required VNet Integration and VNet peering with gateway transit.
If possible, you could create all resources like VNet, app service, cluster in the same region. Then you do not need a VPN gateway for your VNet Integration. This may have fewer limitations and easier to deploy in your scenario.
Hope this could help you.

Azure: Failed to add delegation to the existing subnet

I'm trying to include in an app service an existing VNET but I have this issue:
Failed to add delegation to the existing subnet.:
Delegations of subnet /subscriptions
Cannot be changed from [] to [Microsoft.Web/serverfarms] because it is being used by the resource
Azure Limitation ? How many resources can be used by one VNET ?
The limit is that you have to use an unused subnet for your app service integration When you add VNet (preview) in the networking configuration of app service. Please check if you have any VM resources in that subnet. If it is, you could create an empty subnet for the VNet integration. Read more details here.

Is it possible to use Azure API Management and Azure ACS (kubernetes) as frontend and backend?

I would like to create a simple architecture on Azure. My high level design is very similar to the picture below (source: https://www.import.io/post/using-amazon-lambda-and-api-gateway/)
I do want to access the internal services via the Azure API Management. What I can see on Microfos documentation page is that this simple and secure architecture is not mentioned as a reference:
https://learn.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough
I have the following issues:
API Management cannot be assigned to a Virtual Network if there is at least one NIC is using the same network (why?)
Even with peered Virtual Networks I cannot access 10.244.X.0/24 network (pods' network) because only 10.240.0.0/16 is owned by the k8s Virtual Network. How can I access cluster ips (10.0.0.0/16) and pod ips (10.244.0.0/16)?
Well, you don't need an Extra VNET, but just an extra Subnet. That Subnet could lie within your existing VNET. The Size of Subnet can be the smallest /29 which Azure supports.
The Extra Subnet requirement for API Management comes from the fact, that it is built on PAAS V1 (Classic) technology. While we can deploy into a Resource Manager VNET (V2 layer), there are consequences to that. The Classic deployment model in Azure are not tightly coupled with Resource Manager model and so if you create a resource in V2 stuff, the V1 doesn't know about it and problems can happen such as API Management trying to use an IP that is already allocated to a NIC (built on V2).
To learn more about difference of Classic and Resource Manager models in Azure refer to blog difference between Classic and ResourceManager models
The answer is basically YES although the setup is not trivial.
You need:
One extra VNet for the API Management (EDIT: an extra subnet is enough)
One service (kubernetes terminology)
Steps:
Peer the Kubernetes VNet and the extra VNet you have created (test it)
API Management -> Virtual network: change to External
Choose as Virtual Network the one extra VNet (lets call it 'apimgmntvnet') and a Subnet
Save it! Drink a beer because it took me 1h!
Meanwhile expose your deployment internally:
kubectl expose deployment app --port=<serviceport> --name=app --target-port=<containerport> --type=NodePort (NodePort is important!LoadBalancer type triggers kubernetes to dynamically configure the Azure External LB for Kubernetes install)
Check node IP:PORT on kubernetes (kubectl proxy) BUI
API Management -> Publisher portal: modify your API to the IP address (AgentIP:30361)
Theoretically it should work. It is advised to start with a VM in the apimgmntvnet and try peering first from the VM and than delete it (API Management cannot be part of a VNet where at least one NIC is present (?!) ).

Resources