Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Virtual nodes enable network communication between pods that run in Azure Container Instances (ACI) and Azure Kubernetes Service (AKS) clusters. To provide this communication, a virtual network subnet is created and delegated permissions are assigned. Virtual nodes only work with AKS clusters created using advanced networking (Azure CNI). AKS clusters are created with basic networking (kubenet) by default.
This article shows you how to create a virtual network and subnets, and then deploy an AKS cluster that uses advanced networking using the Azure portal.
Note
For an overview of virtual node region availability and limitations, see Use virtual nodes in AKS.
Before you begin
You need the ACI service provider registered on your subscription.
Check the status of the ACI provider registration using the
az provider listcommand.az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o tableThe following example output shows the Microsoft.ContainerInstance provider is Registered:
Namespace RegistrationState RegistrationPolicy --------------------------- ------------------- -------------------- Microsoft.ContainerInstance Registered RegistrationRequiredIf the provider is NotRegistered, register it using the
az provider registercommand.az provider register --namespace Microsoft.ContainerInstance
Create an AKS cluster
- Navigate to the Azure portal home page.
- Select Create a resource > Containers.
- On the Azure Kubernetes Service (AKS) resource, select Create.
- On the Basics page, configure the following options:
- Project details: Select an Azure subscription, then select or create an Azure resource group, such as myResourceGroup.
- Cluster details: Enter a Kubernetes cluster name, such as myAKSCluster. Select a region and Kubernetes version for the AKS cluster.
- Select Next: Node pools and check *Enable virtual nodes.
- Select Review + create.
- After the validation completes, select Create.
By default, this process creates a managed cluster identity, which is used for cluster communication and integration with other Azure services. For more information, see Use managed identities. You can also use a service principal as your cluster identity.
This process configures the cluster for advanced networking and the virtual nodes to use their own Azure virtual network subnet. The subnet has delegated permissions to connect Azure resources between the AKS cluster. If you don't already have a delegated subnet, the Azure portal creates and configures an Azure virtual network and subnet with the virtual nodes.
Connect to the cluster
The Azure Cloud Shell is a free interactive shell you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account. To manage a Kubernetes cluster, use kubectl, the Kubernetes command-line client. The kubectl client is pre-installed in the Azure Cloud Shell.
Configure
kubectlto connect to your Kubernetes cluster using theaz aks get-credentialscommand. The following example gets credentials for the cluster name myAKSCluster in the resource group named myResourceGroup:az aks get-credentials --resource-group myResourceGroup --name myAKSClusterVerify the connection to your cluster using the
kubectl get nodes.kubectl get nodesThe following example output shows the single VM node created and the virtual Linux node named virtual-node-aci-linux:
NAME STATUS ROLES AGE VERSION virtual-node-aci-linux Ready agent 28m v1.11.2 aks-agentpool-14693408-0 Ready agent 32m v1.11.2
Deploy a sample app
In the Azure Cloud Shell, create a file named
virtual-node.yamland copy in the following YAML:apiVersion: apps/v1 kind: Deployment metadata: name: aci-helloworld spec: replicas: 1 selector: matchLabels: app: aci-helloworld template: metadata: labels: app: aci-helloworld spec: containers: - name: aci-helloworld image: mcr.microsoft.com/azuredocs/aci-helloworld ports: - containerPort: 80 nodeSelector: kubernetes.io/role: agent beta.kubernetes.io/os: linux type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: ExistsThe YAML defines a nodeSelector and toleration, which allows the pod to be scheduled on the virtual node. The pod is assigned an internal IP address from the Azure virtual network subnet delegated for use with virtual nodes.
Run the application using the
kubectl applycommand.kubectl apply -f virtual-node.yamlView the pods scheduled on the node using the
kubectl get podscommand with the-o wideargument.kubectl get pods -o wideThe following example output shows the
virtual-node-helloworldpod scheduled on thevirtual-node-linuxnode.NAME READY STATUS RESTARTS AGE IP NODE virtual-node-helloworld-9b55975f-bnmfl 1/1 Running 0 4m 10.241.0.4 virtual-node-aci-linux
Note
If you use images stored in Azure Container Registry, configure and use a Kubernetes secret. A limitation of virtual nodes is you can't use integrated Microsoft Entra service principal authentication. If you don't use a secret, pods scheduled on virtual nodes fail to start and report the error HTTP response status code 400 error code "InaccessibleImage".
Test the virtual node pod
To test the pod running on the virtual node, browse to the demo application with a web client. The pod is assigned an internal IP address, so you can easily test the connectivity from another pod on the AKS cluster.
Create a test pod and attach a terminal session to it using the following
kubectl runcommand.kubectl run -it --rm virtual-node-test --image=mcr.microsoft.com/dotnet/runtime-deps:6.0Install
curlin the pod using the followingapt-getcommand.apt-get update && apt-get install -y curlAccess the address of your pod using the following
curlcommand and provide your internal IP address.curl -L http://10.241.0.4The following condensed example output shows the demo application.
<html> <head> <title>Welcome to Azure Container Instances!</title> </head> [...]Close the terminal session to your test pod with
exit, which also deletes the pod.exit
Next steps
In this article, you scheduled a pod on the virtual node and assigned a private, internal IP address. If you want, you can instead create a service deployment and route traffic to your pod through a load balancer or ingress controller. For more information, see Create a basic ingress controller in AKS.
Virtual nodes are one component of a scaling solution in AKS. For more information on scaling solutions, see the following articles:
Azure Kubernetes Service