Partager via

Utiliser la mise en réseau kubenet avec vos propres plages d’adresses IP dans Azure Kubernetes Service (AKS)

  • Article

Les clusters AKS utilisent kubenet et créent un réseau et un sous-réseau virtuels Azure automatiquement par défaut. Avec kubenet, les nœuds obtiennent une adresse IP du sous-réseau du réseau virtuel Azure. Les pods reçoivent une adresse IP du sous-réseau de réseau virtuel Azure des nœuds à partir d’un espace d’adressage logiquement différent. La traduction d’adresses réseau (NAT) est ensuite configurée afin que les pods puissent accéder aux ressources sur le réseau virtuel Azure. L’adresse IP source du trafic fait l’objet d’une opération NAT sur l’adresse IP principale du nœud. Cette approche réduit considérablement le nombre d’adresses IP que vous devez réserver dans votre espace réseau pour que les pods les utilisent.

Avec l’interface Azure Container Networking Interface (CNI), chaque pod reçoit une adresse IP du sous-réseau et est accessible directement. Ces adresses IP doivent être planifiées et être uniques dans votre espace réseau. Chaque nœud possède un paramètre de configuration pour le nombre maximal de pods qu’il prend en charge. Le nombre équivalent d’adresses IP par nœud est alors réservé à l’avance pour ce nœud. Cette approche nécessite davantage de planification. De plus, elle conduit souvent à l’épuisement des adresses IP ou à la nécessité de regénérer les clusters dans un sous-réseau plus vaste à mesure que vos demandes d’applications augmentent. Vous pouvez configurer le nombre maximal de modules pouvant être déployés sur un nœud au moment de la création du cluster ou lors de la création de pools de nœuds. Si vous ne spécifiez pas maxPods lors de la création de pools de nœuds, vous recevez la valeur par défaut de 110 pour kubenet.

Cet article vous montre comment utiliser la mise en réseau kubenet pour créer et utiliser un sous-réseau de réseau virtuel pour un cluster AKS. Pour plus d’informations sur les options et considérations relatives aux réseaux, consultez Concepts de réseau pour Kubernetes et AKS.

Prérequis

  • Le réseau virtuel du cluster AKS doit autoriser les connexions Internet sortantes.
  • Ne créez pas plus d’un cluster AKS dans le même sous-réseau.
  • Les clusters AKS ne peuvent pas utiliser 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ou 192.0.2.0/24 pour la plage d’adresses de service Kubernetes, la plage d’adresses de pod ou la plage d’adresses de réseau virtuel de cluster. Cette plage ne peut pas être mise à jour après la création de votre cluster.
  • L'identité de cluster utilisée par le cluster AKS doit au moins disposer du rôle Contributeur de réseau sur le sous-réseau de votre réseau virtuel. L’interface CLI permet d’attribuer automatiquement les rôles. Si vous utilisez un modèle ARM ou d’autres clients, vous devez définir manuellement l’attribution de rôle. Vous devez également disposer des autorisations appropriées (propriétaire de l'abonnement, par exemple) pour créer une identité de cluster et lui attribuer des autorisations. Si vous voulez définir un rôle personnalisé au lieu d’utiliser le rôle intégré Contributeur de réseau, vous devez avoir les autorisations suivantes :
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read

Avertissement

Pour utiliser des pools de nœuds Windows Server, vous devez utiliser Azure CNI. Le modèle de réseau kubenet n’est pas disponible pour les conteneurs Windows Server.

Avant de commencer

Azure CLI version 2.0.65 ou ultérieure doit être installé et configuré. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.

Vue d’ensemble de la mise en réseau kubenet avec votre propre sous-réseau

Dans de nombreux environnements, vous avez défini des réseaux virtuels et des sous-réseaux avec des plages d’adresses IP allouées, et vous utilisez ces ressources pour prendre en charge plusieurs services et applications. Pour fournir une connectivité réseau, les clusters AKS peuvent utiliser kubenet (mise en réseau de base) ou Azure CNI (mise en réseau avancée).

Avec kubenet, seuls les nœuds reçoivent une adresse IP dans le sous-réseau de réseau virtuel. Les pods ne peuvent pas communiquer directement entre eux. Au lieu de cela, les routes définies par l’utilisateur (UDR) et le transfert IP gère la connectivité entre les pods sur les nœuds. La configuration des itinéraires définis par l’utilisateur et des transferts IP est créée et gérée par le service AKS par défaut, mais vous pouvezutiliser votre propre table de routage pour la gestion des itinéraires personnalisés si vous le souhaitez. Vous pouvez également déployer des pods derrière un service qui reçoit une adresse IP attribuée et équilibre la charge du trafic pour l’application. Le diagramme suivant illustre la façon dont les nœuds AKS reçoivent une adresse IP dans le sous-réseau de réseau virtuel, mais pas les pods :

Modèle de réseau kubenet avec un cluster AKS

Azure prend en charge un maximum de 400 routes dans une route UDR. Vous ne pouvez donc pas avoir un cluster AKS comportant plus de 400 nœuds. Les nœuds virtuels AKS et les stratégies réseau Azure ne sont pas pris en charge avec kubenet. Les stratégies réseau Calico sont prises en charge.

Avec Azure CNI, chaque pod reçoit une adresse IP dans le sous-réseau IP et peut communiquer directement avec d’autres pods et services. La taille de vos clusters peut être identique à la plage d’adresses IP que vous spécifiez. Toutefois, la plage d’adresses IP doit être planifiée à l’avance, et toutes les adresses IP sont consommées par les nœuds AKS en fonction du nombre maximal de pods qu’ils peuvent prendre en charge. Les scénarios et fonctionnalités réseau avancé comme les nœuds virtuels ou les stratégies réseau (Azure ou Calico) sont pris en charge avec Azure CNI.

Limitations et considérations relatives à kubenet

Remarque

Certains pods système tels que konnectivity dans le cluster utilisent l’adresse IP du nœud hôte plutôt qu’une adresse IP de l’espace d’adressage de superposition. Les pods système n’utilisent que l’adresse IP du nœud et non une adresse IP du réseau virtuel.

Disponibilité et épuisement des adresses IP

Avec Azure CNI, une plage d’adresses IP attribuée trop petite pour ensuite ajouter des nœuds supplémentaires quand vous mettez à l’échelle ou mettez à niveau un cluster constitue un problème courant. L’équipe réseau peut également ne pas être en mesure d’émettre une plage d’adresses IP suffisamment grande pour prendre en charge vos demandes d’applications attendues.

À titre de compromis, vous pouvez créer un cluster AKS qui utilise kubenet et vous connecter à un sous-réseau de réseau virtuel existant. Cette approche permet aux nœuds de recevoir des adresses IP définies sans avoir besoin de réserver un grand nombre d’adresses IP à l’avance pour tous les pods potentiels qui pourraient s’exécuter dans le cluster. Avec kubenet, vous pouvez utiliser une plage d’adresses IP beaucoup plus petite et prendre en charge de grands clusters et les demandes d’applications. Par exemple, avec une plage d’adresses IP /27sur votre sous-réseau, vous pouvez exécuter un cluster de 20 à 25 nœuds avec suffisamment de place pour effectuer une mise à l’échelle ou une mise à niveau. Cette taille de cluster prend en charge jusqu’à 2 200 à 2 750 pods (avec un maximum par défaut de 110 pods par nœud). Le nombre maximal de pods par nœud que vous pouvez configurer avec kubenet dans AKS est 250.

Les calculs de base suivants comparent la différence entre les modèles de réseaux :

  • kubenet : une plage d’adresses IP /24 simple peut prendre en charge jusqu’à 251 nœuds dans le cluster. Chaque sous-réseau de réseau virtuel Azure réserve les trois premières adresses IP pour les opérations de gestion. Ce nombre de nœuds peut prendre en charge jusqu’à 27 610 pods (avec un maximum par défaut de 110 pods par nœud.
  • Azure CNI : cette même plage de sous-réseau /24 de base peut seulement prendre en charge un maximum de 8 nœuds dans le cluster. Ce nombre de nœuds peut prendre en charge jusqu’à 240 pods, avec un maximum par défaut de 30 pods par nœud.

Remarque

Ces valeurs maximales ne prennent pas en compte les opérations de mise à niveau ou de mise à l’échelle. Dans la pratique, vous ne pouvez pas exécuter le nombre maximal de nœuds que la plage d’adresses IP de sous-réseau prend en charge. Vous devez laisser certaines adresses IP disponibles pour qu’elles puissent être utilisées pendant les opérations de mise à l’échelle et de mise à niveau.

Peering de réseau virtuel et connexions ExpressRoute

Pour fournir une connectivité locale, les approches des réseaux kubenet et Azure CNI peuvent toutes les deux utiliser le Peering de réseaux virtuels Azure ou les connexions ExpressRoute. Planifiez vos plages d’adresses IP avec soin pour éviter le chevauchement et un routage incorrect du trafic. Par exemple, de nombreux réseaux locaux utilisent une plage d’adresses 10.0.0.0/8 qui est publiée sur la connexion ExpressRoute. Nous vous recommandons de créer vos clusters AKS dans des sous-réseaux de réseau virtuel Azure en dehors de cette plage d’adresses, comme 172.16.0.0/16.

Choisir un modèle de réseau à utiliser

Les considérations suivantes aident à déterminer quand chaque modèle de réseau peut être le plus approprié :

Utilisez kubenet quand :

  • Vous avez un espace d’adressage IP limité.
  • La majeure partie de la communication des pods s’effectue dans le cluster.
  • Vous n’avez pas besoin de fonctionnalités AKS avancées comme des nœuds virtuels ou une stratégie réseau Azure.

Utilisez Azure CNI quand :

  • Vous disposez d’espace d’adressage IP disponible.
  • La majeure partie de la communication des pods s’effectue avec des ressources hors du cluster.
  • Vous ne souhaitez pas gérer les itinéraires définis par l’utilisateur pour la connectivité des pods.
  • Vous avez besoin de fonctionnalités avancées AKS comme des nœuds virtuels ou une stratégie réseau Azure.

Pour vous aider à déterminer quel modèle de réseau utiliser, consultez les sections Comparer des modèles de réseau et Étendue du support.

Créer un réseau virtuel et un sous-réseau

  1. Créez un groupe de ressources avec la commande az group create.

    az group create --name myResourceGroup --location eastus

  2. Si vous n’avez pas de réseau virtuel et de sous-réseau existants à utiliser, créez ces ressources réseau à l’aide de la commande az network vnet create. L’exemple de commande suivant crée un réseau virtuel nommé myAKSVnet avec le préfixe d’adresse 192.168.0.0/16 et un sous-réseau nommé myAKSSubnet avec le préfixe d’adresse 192.168.1.0/24 :

    az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus

  3. Obtenez l’ID de ressource de sous-réseau à l’aide de la commande az network vnet subnet show et stockez-le en tant que variable nommée SUBNET_ID pour une utilisation ultérieure.

    SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

Créer un cluster AKS dans le réseau virtuel

Créer un cluster AKS avec des identités managées affectées par le système

Remarque

Lors de l’utilisation de l’identité attribuée par le système, Azure CLI accorde le rôle Contributeur réseau à l’identité attribuée par le système une fois le cluster créé. Si vous utilisez un modèle ARM ou d’autres clients, vous devez utiliser l’identité managée affectée par l’utilisateur à la place.

  • Créer un cluster AKS avec des identités managées affectées par le système en utilisant la commande az aks create.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

    Paramètres de déploiement :

    • --service-cidr est facultatif. Cette adresse est utilisée pour attribuer une adresse IP aux services internes du cluster AKS. Cette plage d’adresses IP doit être un espace d’adressage qui n’est pas utilisé ailleurs dans votre environnement réseau, y compris dans des plages réseau locales, si vous connectez, ou envisagez de connecter, vos réseaux virtuels Azure à l’aide d’ExpressRoute ou d’une connexion VPN site à site. La valeur par défaut est 10.0.0.0/16.
    • --dns-service-ip est facultatif. L’adresse doit être l’adresse .10 de la plage d’adresses IP de votre service. La valeur par défaut est 10.0.0.10.
    • --pod-cidr est facultatif. Cette adresse doit être un grand espace d’adressage qui n’est pas utilisé ailleurs dans votre environnement réseau. Cette plage inclut les plages de réseau local si vous connectez ou envisagez de connecter vos réseaux virtuels Azure à l’aide d’Express Route ou d’une connexion VPN de site à site. La valeur par défaut est 10.244.0.0/16.
      • Cette plage d’adresses doit être suffisamment grande pour contenir le nombre de nœuds que vous prévoyez d’obtenir par le biais d’un scale-up. Vous ne pouvez pas modifier cette plage d’adresses une fois que le cluster est déployé.
      • La plage d’adresses IP de pod est utilisée pour attribuer un espace d’adressage /24 pour chaque nœud du cluster. Dans l’exemple suivant, l’adresse --pod-cidr10.244.0.0/16 attribue le premier nœud 10.244.0.0/24, le deuxième nœud 10.244.1.0/24 et le troisième nœud 10.244.2.0/24.
      • À mesure que le cluster est mis à l’échelle ou à niveau, la plateforme Azure continue d’attribuer une plage d’adresses IP de pod à chaque nouveau nœud.

Créer un cluster AKS avec une identité managée affectée par l’utilisateur

Créer une identité managée

  • Créez une identité managée à l’aide de la commande az identity. Si vous disposez d’une identité managée existante, vous pouvez trouver l’identifiant du principal en exécutant la commande az identity show --ids <identity-resource-id> à la place.

    az identity create --name myIdentity --resource-group myResourceGroup

    Votre sortie doit ressembler à l’exemple suivant :

    {                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Ajouter une attribution de rôle pour l’identité managée

Si vous utilisez Azure CLI, le rôle est ajouté automatiquement et vous pouvez ignorer cette étape. Si vous utilisez un modèle ARM ou un autre client, vous devez utiliser l’ID du principal de l’identité managée du cluster pour effectuer une attribution de rôle.

  • Obtenez l’ID de ressource du réseau virtuel à l’aide de la commande az network vnet show et stockez-le en tant que variable nommée VNET_ID.

    VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

  • Attribuez l’identité managée pour les autorisations de Contributeur réseau à votre cluster AKS sur le réseau virtuel à l’aide de la commande az role assignment create et fournissez le <principalId>.

    az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Remarque

L’autorisation accordée à l’identité managée de votre cluster utilisée par Azure peut prendre jusqu’à 60 minutes pour être effective.

Créer un cluster AKS

  • Créez un cluster AKS à l’aide de la commande az aks create et fournissez l’ID de ressource d’identité du plan de contrôle pour l’argument assign-identity pour attribuer l’identité managée affectée par l’utilisateur.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

Lorsque vous créez un cluster AKS, un groupe de sécurité réseau et une table de route sont automatiquement créés. Ces ressources réseau sont gérées par le plan de contrôle AKS. Le groupe de sécurité réseau est automatiquement associé aux cartes réseau virtuelles sur vos nœuds. La table de routage est automatiquement associée au sous-réseau de réseau virtuel. Les règles de groupe de sécurité réseau et les tables de routage sont automatiquement mises à jour quand vous créez et exposez des services.

Utiliser votre propre sous-réseau et votre propre table de route avec kubenet

Avec kubenet, une table de route doit exister sur les sous-réseaux de votre cluster. AKS prend en charge l'utilisation de votre propre sous-réseau et de votre propre table de route. Si votre sous-réseau personnalisé ne contient pas de table de routage, AKS en crée une pour vous et y ajoute des règles tout au long du cycle de vie du cluster. Si votre sous-réseau personnalisé contient une table de route lorsque vous créez votre cluster, AKS la reconnaît lors des opérations de cluster et ajoute/met à jour les règles en conséquence pour les opérations du fournisseur de cloud.

Avertissement

Vous pouvez ajouter/mettre à jour des règles personnalisées sur la table de routage personnalisée. Toutefois, des règles sont ajoutées par le fournisseur de cloud Kubernetes, lesquelles ne doit pas être mises à jour ni supprimées. Les règles telles que 0.0.0.0/0 doivent toujours exister sur une table de route donnée et être mappées à la cible de votre passerelle Internet, telle qu’une appliance virtuelle réseau ou une autre passerelle de sortie. Soyez prudent lors de la mise à jour des règles.

En savoir plus sur la configuration d’une table de route personnalisée.

La mise en réseau Kubenet nécessite que les règles de la table de route soient organisées pour acheminer correctement les demandes. En raison de cette conception, les tables de route doivent être soigneusement tenues à jour pour chaque cluster qui en dépend. Plusieurs clusters ne peuvent pas partager de table de route, car les CIDR de pods des différents clusters peuvent se chevaucher, ce qui provoque des scénarios de routage inattendus et interrompus. Lorsque vous configurez plusieurs clusters sur le même réseau virtuel ou dédiez un réseau virtuel à chaque cluster, prenez en compte les limitations suivantes :

  • Une table de route personnalisée doit être associée au sous-réseau avant de créer le cluster AKS.
  • La ressource de table de route associée ne peut pas être mise à jour après la création du cluster. Cependant, les règles personnalisées peuvent être modifiées sur la table de routage.
  • Chaque cluster AKS doit utiliser une table de route unique pour tous les sous-réseaux associés au cluster. Vous ne pouvez pas réutiliser une table de route avec plusieurs clusters en raison du risque de chevauchement des CIDR de pods et de règles d’acheminement contradictoires.
  • Pour l’identité managée affectée par le système, il est uniquement pris en charge pour fournir votre propre sous-réseau et votre propre table de routage via Azure CLI, car Azure CLI ajoute automatiquement l’attribution de rôle. Si vous utilisez un modèle ARM ou d’autres clients, vous devez utiliser une identité managée affectée par l’utilisateur, attribuer des autorisations avant la création du cluster et vérifier que l’identité affectée par l’utilisateur dispose d’autorisations en écriture sur votre sous-réseau personnalisé et table de routage personnalisée.
  • L’utilisation de la même table de routage avec plusieurs clusters AKS n’est pas prise en charge.

Remarque

Lorsque vous créez et utilisez votre propre réseau virtuel et votre propre table de routage avec un plug-in réseau kubenet, vous devez configurer une identité managée affectée par l'utilisateur. Avec une identité managée affectée par le système, vous ne pouvez pas récupérer l’identifiant d’identité avant la création d’un cluster, ce qui entraîne un retard lors de l’attribution du rôle.

Les identités managées affectées par le système et affectées par l’utilisateur sont prises en charge lorsque vous créez et utilisez vos propres réseau virtuel et table de routage avec le plug-in réseau Azure. Nous vous recommandons vivement d’utiliser une identité managée affectée par l’utilisateur pour les scénarios BYO.

Ajoutez une table de routage avec une identité managée affectée par l’utilisateur à votre cluster AKS

Après avoir créé une table de routage personnalisée et l’avoir associée à un sous-réseau dans votre réseau virtuel, vous pouvez créer un cluster AKS spécifiant votre table de routage avec une identité managée affectée par l’utilisateur. Vous devez utiliser l’ID de sous-réseau pour l’emplacement où vous envisagez de déployer votre cluster AKS. Ce sous-réseau doit également être associé à votre table de route personnalisée.

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

    az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

  2. Créez un cluster AKS avec un sous-réseau personnalisé préconfiguré avec une table de routage à l’aide de la commande az aks create et en fournissant vos valeurs pour les paramètres --vnet-subnet-id et --assign-identity.

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys

Étapes suivantes

Cet article vous a montré comment déployer votre cluster AKS dans votre sous-réseau de réseau virtuel existant. Vous pouvez désormais commencer à créer des applications à l’aide de Helm ou à déployer des applications existantes à l’aide de Helm.