Créer et configurer un cluster Azure Kubernetes Services (AKS) pour utiliser des nœuds virtuels à l'aide d'Azure CLI

Article
08/02/2024

Les nœuds virtuels permettent la communication réseau entre les pods qui s'exécutent dans Instances de conteneur Azure (ACI) et les clusters AKS. Pour fournir cette communication, vous créez un sous-réseau de réseau virtuel et attribuez des autorisations déléguées. Les nœuds virtuels ne fonctionnent qu’avec des clusters AKS créés avec un réseau avancé (Azure CNI). Par défaut, les clusters AKS sont créés avec un réseau simple (kubenet). Cet article vous montre comment créer un réseau virtuel et des sous-réseaux, puis déployer un cluster AKS qui utilise un réseau avancé.

Cet article vous montre comment utiliser Azure CLI pour créer et configurer des ressources de réseau virtuel et un cluster AKS activé avec des nœuds virtuels.

Avant de commencer

Important

Avant d’utiliser des nœuds virtuels avec AKS, passez en revue les limitations relatives aux nœuds virtuels AKS et les limitations d’ACI relatives aux réseaux virtuels. Ces limitations affectent l’emplacement, la configuration réseau, ainsi que d’autres informations de configuration du cluster AKS et des nœuds virtuels.

Vous avez besoin du fournisseur de services ACI enregistré avec votre abonnement. Vous pouvez vérifier l'état de l'enregistrement du fournisseur ACI à l'aide de la commande az provider list.
```
az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table
```
Le fournisseur de Microsoft.ContainerInstance doivent être signalé comme Registered (Inscrit), comme dans l’exemple de sortie suivant :
```
Namespace                    RegistrationState    RegistrationPolicy
---------------------------  -------------------  --------------------
Microsoft.ContainerInstance  Registered           RegistrationRequired
```
Si le fournisseur s'affiche comme Non enregistré, enregistrez le fournisseur à l'aide de az provider register.
```
az provider register --namespace Microsoft.ContainerInstance
```
Si vous utilisez Azure CLI, cet article nécessite Azure CLI version 2.0.49 ou ultérieure. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI. Vous pouvez également utiliser Azure Cloud Shell.

Lancement d’Azure Cloud Shell

Le service Azure Cloud Shell est un interpréteur de commandes interactif et gratuit que vous pouvez utiliser pour exécuter les étapes décrites dans cet article. Il a des outils Azure communs préinstallés et configurés.

Pour ouvrir Cloud Shell, sélectionnez Essayer en haut à droite d’un bloc de code. Vous pouvez aussi lancer Cloud Shell dans un onglet distinct du navigateur en accédant à https://shell.azure.com/bash. Sélectionnez Copier pour copier les blocs de code, collez-les dans Cloud Shell, puis appuyez sur Entrée pour les exécuter.

Créer un groupe de ressources

Un groupe de ressources Azure est un groupe logique dans lequel des ressources Azure sont déployées et gérées.

Créez un groupe de ressources avec la commande az group create.
```
az group create --name myResourceGroup --location eastus
```

Créez un réseau virtuel

Important

Un nœud virtuel nécessite un réseau virtuel personnalisé et un sous-réseau associé. Il ne peut pas être associé au même réseau virtuel que le cluster AKS.

Créer un réseau virtuel en utilisant la commande az network vnet create. L'exemple suivant crée un réseau virtuel nommé myVnet avec un préfixe d'adresse de 10.0.0.0/8 et un sous-réseau nommé myAKSSubnet. Le préfixe d'adresse de ce sous-réseau est par défaut 10.240.0.0/16.
```
az network vnet create \
    --resource-group myResourceGroup \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16
```
Créez un sous-réseau supplémentaire pour les nœuds virtuels à l'aide de la commande az network vnet subnet create. L'exemple suivant crée un sous-réseau nommé myVirtualNodeSubnet avec un préfixe d'adresse de 10.241.0.0/16.
```
az network vnet subnet create \
    --resource-group myResourceGroup \
    --vnet-name myVnet \
    --name myVirtualNodeSubnet \
    --address-prefixes 10.241.0.0/16
```

Créer un cluster AKS avec identité managée

Obtenez l’ID du sous-réseau à l’aide de la commande az network vnet subnet show.

az network vnet subnet show --resource-group myResourceGroup --vnet-name myVnet --name myAKSSubnet --query id -o tsv

Créez un cluster AKS à l'aide de la commande az aks create et remplacez <subnetId> par l'ID obtenu à l'étape précédente. L'exemple suivant crée un cluster nommé myAKSCluster avec cinq nœuds.
```
az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5 \
    --network-plugin azure \
    --vnet-subnet-id <subnetId> \
    --generate-ssh-keys
```
Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster.

Pour plus d'informations sur les identités managées, consultez Utiliser des identités managées.

Activer l'addon des nœuds virtuels

Activez les nœuds virtuels à l'aide de la commande az aks enable-addons. L'exemple suivant utilise le sous-réseau nommé myVirtualNodeSubnet créé à une étape précédente.
```
az aks enable-addons \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --addons virtual-node \
    --subnet-name myVirtualNodeSubnet
```

Se connecter au cluster

Configurez kubectl afin de vous connecter à votre cluster Kubernetes avec la commande az aks get-credentials. Cette étape télécharge les informations d’identification et configure l’interface de ligne de commande Kubernetes pour leur utilisation.
```
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```
Vérifiez la connexion à votre cluster à l’aide de la commande kubectl get, qui retourner la liste des nœuds du cluster.
```
kubectl get nodes
```
L'exemple de sortie suivant montre le nœud de machine virtuelle unique créé et le nœud virtuel pour Linux, 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
```

Déployer un exemple d’application

Créez un fichier nommé virtual-node.yaml et copiez-y le YAML suivant. Le YAML planifie le conteneur sur le nœud en définissant un nodeSelector et une toleration.

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: Exists
      - key: azure.com/aci
        effect: NoSchedule

Exécutez l’application à l’aide de la commande kubectl apply.
```
kubectl apply -f virtual-node.yaml
```
Obtenez une liste des pods et le nœud planifié à l'aide de la commande kubectl get pods avec l'argument -o wide.
```
kubectl get pods -o wide
```
Le pod est planifié sur le nœud virtuel virtual-node-aci-linux, comme illustré dans l'exemple de sortie suivant :
```
NAME                            READY     STATUS    RESTARTS   AGE       IP           NODE
aci-helloworld-9b55975f-bnmfl   1/1       Running   0          4m        10.241.0.4   virtual-node-aci-linux
```
Le pod reçoit une adresse IP interne du sous-réseau de réseau virtuel Azure délégué de façon à être utilisé avec des nœuds virtuels.

Notes

Si vous utilisez des images stockées dans Azure Container Registry, configurez et utilisez un secret Kubernetes. Compte-tenu de la limitation actuelle des nœuds virtuels, vous ne pouvez pas utiliser l’authentification de principal de service Microsoft Entra intégrée. Si vous n'utilisez pas de secret, les pods planifiés sur les nœuds virtuels ne parviennent pas à démarrer et renvoient l'erreur HTTP response status code 400 error code "InaccessibleImage".

Tester le pod de nœud virtuel

Testez le pod en cours d'exécution sur le nœud virtuel en accédant à l'application de démonstration avec un client Web. Comme le pod possède une adresse IP interne, vous pouvez tester facilement cette connectivité à partir d’un autre pod sur le cluster AKS.
Créez un pod de test et attachez-lui une session de terminal à l’aide de la commande suivante kubectl run -it.
```
kubectl run -it --rm testvk --image=mcr.microsoft.com/dotnet/runtime-deps:6.0
```
Installez curl dans le pod en utilisant apt-get.
```
apt-get update && apt-get install -y curl
```
Accédez à l'adresse de votre pod à l'aide de curl, par exemple http://10.241.0.4. Fournissez votre propre adresse IP interne indiquée dans la commande kubectl get pods précédente.
```
curl -L http://10.241.0.4
```
L’application de démonstration s’affiche, comme l’illustre l’exemple de sortie condensé suivant :
```
<html>
<head>
  <title>Welcome to Azure Container Instances!</title>
</head>
[...]
```
Fermez la session de terminal sur votre pod de test avec exit. Lorsque votre session est terminée, le module est supprimé.

Supprimer des nœuds virtuels

Supprimez le pod aci-helloworld en cours d'exécution sur le nœud virtuel à l'aide de la commande kubectl delete.
```
kubectl delete -f virtual-node.yaml
```

Désactivez les nœuds virtuels à l'aide de la commande az aks disable-addons.

az aks disable-addons --resource-group myResourceGroup --name myAKSCluster --addons virtual-node

Supprimez les ressources du réseau virtuel et le groupe de ressources à l'aide des commandes suivantes.

# Change the name of your resource group, cluster and network resources as needed
RES_GROUP=myResourceGroup
AKS_CLUSTER=myAKScluster
AKS_VNET=myVnet
AKS_SUBNET=myVirtualNodeSubnet

# Get AKS node resource group
NODE_RES_GROUP=$(az aks show --resource-group $RES_GROUP --name $AKS_CLUSTER --query nodeResourceGroup --output tsv)

# Get network profile ID
NETWORK_PROFILE_ID=$(az network profile list --resource-group $NODE_RES_GROUP --query "[0].id" --output tsv)

# Delete the network profile
az network profile delete --id $NETWORK_PROFILE_ID -y

# Grab the service association link ID
SAL_ID=$(az network vnet subnet show --resource-group $RES_GROUP --vnet-name $AKS_VNET --name $AKS_SUBNET --query id --output tsv)/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default

# Delete the service association link for the subnet
az resource delete --ids $SAL_ID --api-version 2021-10-01

# Delete the subnet delegation to Azure Container Instances
az network vnet subnet update --resource-group $RES_GROUP --vnet-name $AKS_VNET --name $AKS_SUBNET --remove delegations

Étapes suivantes

Dans cet article, vous avez planifié un pod sur le nœud virtuel et attribué une adresse IP interne privée. Vous auriez tout aussi bien pu créer un déploiement de service et router le trafic vers votre pod au moyen d’un équilibreur de charge ou d’un contrôleur d’entrée. Pour plus d’informations, consultez Créer un contrôleur d’entrée de base dans AKS.

Les nœuds virtuels constituent souvent l’un des composants d’une solution de mise à l’échelle dans AKS. Pour plus d’informations sur ces solutions, consultez les articles suivants :

Partage via