咨询Azure Kubernetes Pod通过VPN访问受访问限制的Azure App Service的实现方法

Absolutely, you can set up a VPN for your Kubernetes pods to access your Azure App Service—and this will solve the whitelisting issue you're facing (since pod IPs are internal and get NAT'd to node/public IPs anyway). Let's break this down step by step, tailored for someone new to Kubernetes.

First, let's quickly clarify why adding the pod IP to your App Service whitelist didn't work: Kubernetes pods use internal cluster IPs. When a pod makes an outbound request to your App Service, the traffic gets SNAT'd (Source Network Address Translated) to the public IP of the cluster node it's running on. So the App Service sees the node's public IP, not the pod's internal IP—hence the whitelist didn't take effect.

Now, onto the VPN solution (plus a simpler Azure-native alternative you might prefer):

This approach creates a secure VPN tunnel between your Kubernetes cluster's network and the Azure virtual network hosting your App Service, letting pods access the App Service via private IPs.

Prerequisites #

• Your App Service should be in an Azure Virtual Network (VNet) (enable VNet Integration in the App Service's "Network" settings if it isn't already).
• Your Kubernetes cluster (I'll assume it's Azure AKS for simplicity, but steps adapt to other clusters) should be in its own VNet, with no overlapping address spaces with the App Service's VNet.

Step 1: Create an Azure VPN Gateway #

1. In the Azure Portal, navigate to the VNet connected to your App Service.
2. Create a VPN Gateway:
   • Select "Route-based" as the VPN type.
   • Choose a SKU (e.g., VpnGw1 for small workloads).
   • Assign a public IP address to the gateway.
3. Wait for the gateway to deploy (this can take 15-20 minutes).

Step 2: Link Your Kubernetes Cluster's VNet to the VPN Gateway #

1. In your Kubernetes cluster's VNet (e.g., AKS VNet), create a Local Network Gateway:
   • Enter the address space of your App Service's VNet.
   • Input the public IP address of the VPN Gateway you created earlier.
2. Go back to the VPN Gateway, create a Site-to-Site Connection:
   • Select the Local Network Gateway you just created.
   • Set a pre-shared key (make a note of this—you'll need it for the cluster side).
3. Wait for the connection status to show "Connected".

Step 3: Configure Routing on Kubernetes Nodes #

You need to tell your cluster nodes to send traffic destined for the App Service's VNet through the VPN tunnel:

1. SSH into an AKS node using:

   az aks ssh --name <your-aks-cluster> --resource-group <your-rg>
   

2. Add a static route to direct traffic to the App Service's VNet:

   sudo ip route add <app-service-vnet-cidr> via <vpn-gateway-private-ip-in-aks-vnet> dev eth0
   

   • To make this route permanent (survives node reboots), add the command to /etc/rc.local or use the VMSS Custom Script Extension if your AKS uses Virtual Machine Scale Sets.
3. Repeat this step for all nodes in your cluster (or automate it with a DaemonSet if you want to scale easily).

Step 4: Test the Connection #

1. Deploy a test pod in your cluster:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-vpn-pod
   spec:
     containers:
     - name: curl-test
       image: curlimages/curl
       command: ["sleep", "3600"]
   

2. Exec into the pod:

   kubectl exec -it test-vpn-pod -- bash
   

3. Access your App Service using its private IP (from VNet Integration) or private link domain (e.g., http://<your-app-name>.privatelink.azurewebsites.net). You should get a successful response.

If you're working entirely within Azure, Private Link is a better, lower-maintenance option than VPN. It lets your Kubernetes pods access the App Service directly via a private IP, no public internet involved:

1. Create a Private Endpoint for your App Service, selecting your Kubernetes cluster's VNet as the target.
2. Create a Private DNS Zone for privatelink.azurewebsites.net and link it to your Kubernetes cluster's VNet. This ensures pods resolve your App Service's domain to its private IP.
3. That's it! Pods can now access the App Service using its regular domain name, and traffic stays within Azure's private network—no whitelisting needed.

• If you stick with the VPN approach, consider using a DaemonSet to automatically add the static route to new nodes as your cluster scales.
• For non-AKS clusters, the core idea remains the same: set up a VPN tunnel between your cluster's network and the App Service's VNet, then route pod traffic through the tunnel.

内容的提问来源于stack exchange，提问作者user14856694