How to invoke a service on a VM from AKS pod when VM and AKS are in different/same resource group

Vimal K 1 Reputation point

I have a set of VMs in a resource group
I have an AKS cluster in another resource group.

The services running on VMs can talk to each other using local IPs, and these are important services, so dont want to expose them via a gateway.

How do i access a service on the VM from AKS pod, without exposing the service in any way. Basically services on the VM can be accessed via local IPs only. How to access them from AKS?

If i put the AKS in the same resource group as VM, then can i acesss using local IPs?

Azure Virtual Machines
Azure Virtual Machines
An Azure service that is used to provision Windows and Linux virtual machines.
7,513 questions
Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS)
An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.
1,976 questions
{count} votes

1 answer

Sort by: Most helpful
  1. prmanhas-MSFT 17,901 Reputation points Microsoft Employee

    @Vimal K Below is the response I got from our internal team:

    You can't move an AKS cluster across RG. [Not Supported] You can rebuild the AKS cluster in the same RG as VMs but the infra RG for AKS is going to be different. And in any case RG does not matter. Look at N/W. Are the VMs and the AKS worker nodes in the same N/W? If so they can directly access, else peer the AKS Vnet with the VM Vnet. If peering is not possible due to subnet overlap and if you are using AKS with multiple nodepool support (VMSS node pool type basically) then

    1) You can add another subnet in the AKS VNet (which does not overlap with the subnet CIDR of VMs) -> Add a new system mode node pool on AKS associated with the new subnet -> Drain earlier node pool and remove it -> peer new subnet in AKS Vnet with VM Subnet.

    2) You can create new subnet in the VM Vnet -> create a new system mode node pool on AKS associated with the newly created subnet -> Drain the old node pool and delete it. In this case since both AKS node pool subnet and VM subnet are in the same VNet, communication over private IPs should not be a problem.

    Hope it helps!!!

    Please "Accept as Answer" if it helped so it can help others in community looking for help on similar topics