Exigences de planification des adresses IP
S’applique à : Azure Local, version 23H2
La planification des adresses IP pour AKS activée par Azure Arc implique la conception d’un réseau qui prend en charge les applications, les pools de nœuds, les réseaux de pods, la communication de service et l’accès externe. Cet article vous guide tout au long de certaines considérations clés relatives à la planification efficace des adresses IP et au nombre minimal d’adresses IP requises pour déployer AKS en production. Consultez les concepts et exigences de mise en réseau AKS avant de lire cet article.
Planification d’adresses IP simples pour les clusters et applications Kubernetes
Dans le scénario suivant, vous réservez des adresses IP à partir d’un seul réseau pour vos clusters et services Kubernetes. Cet exemple est le scénario le plus simple et le plus simple pour l’attribution d’adresses IP.
| Exigence d’adresse IP | Nombre minimal d’adresses IP | Comment et où effectuer cette réservation |
|---|---|---|
| Adresses IP de machine virtuelle AKS Arc | Réservez une adresse IP pour chaque nœud Worker de votre cluster Kubernetes. Par exemple, si vous souhaitez créer 3 pools de nœuds avec 3 nœuds dans chaque pool de nœuds, vous avez besoin de 9 adresses IP dans votre pool d’adresses IP. | Réservez des adresses IP via des pools IP dans le réseau logique de machine virtuelle Arc. |
| Adresses IP de mise à niveau de version AKS Arc K8s | Étant donné que AKS Arc effectue des mises à niveau propagées, réservez une adresse IP pour chaque cluster AKS Arc pour les opérations de mise à niveau de version Kubernetes. | Réservez des adresses IP via des pools IP dans le réseau logique de machine virtuelle Arc. |
| ADRESSE IP du plan de contrôle | Réservez une adresse IP pour chaque cluster Kubernetes dans votre environnement. Par exemple, si vous souhaitez créer 5 clusters au total, réservez 5 adresses IP, une pour chaque cluster Kubernetes. | Réservez des adresses IP via des pools IP dans le réseau logique de machine virtuelle Arc. |
| Adresses IP de l’équilibreur de charge | Le nombre d’adresses IP réservées dépend de votre modèle de déploiement d’application. En guise de point de départ, vous pouvez réserver une adresse IP pour chaque service Kubernetes. | Réservez des adresses IP dans le même sous-réseau que le réseau logique de machine virtuelle Arc, mais en dehors du pool d’adresses IP. |
Exemple de procédure pas à pas pour la réservation d’adresses IP pour les clusters et applications Kubernetes
Jane est un administrateur informatique qui commence simplement par AKS activé par Azure Arc. Jane souhaite déployer deux clusters Kubernetes : le cluster Kubernetes A et le cluster Kubernetes B sur le cluster local Azure. Jane souhaite également exécuter une application de vote au-dessus du cluster A. Cette application a trois instances de l’interface utilisateur frontale s’exécutant sur les deux clusters et une instance de la base de données back-end. Tous les clusters et services AKS s’exécutent dans un seul réseau, avec un seul sous-réseau.
- Le cluster Kubernetes A a 3 nœuds de plan de contrôle et 5 nœuds Worker.
- Le cluster Kubernetes B a 1 nœud de plan de contrôle et 3 nœuds Worker.
- 3 instances de l’interface utilisateur frontale (port 443).
- 1 instance de la base de données back-end (port 80).
En fonction du tableau précédent, Jane doit réserver un total de 19 adresses IP dans le sous-réseau de Jane :
- 8 adresses IP pour les machines virtuelles de nœud AKS Arc dans le cluster A (une adresse IP par machine virtuelle de nœud K8s).
- 4 adresses IP pour les machines virtuelles de nœud AKS Arc dans le cluster B (une adresse IP par machine virtuelle de nœud K8s).
- 2 adresses IP pour l’exécution de l’opération de mise à niveau AKS Arc (une adresse IP par cluster AKS Arc).
- 2 adresses IP pour le plan de contrôle AKS Arc (une adresse IP par cluster AKS Arc)
- 3 adresses IP pour le service Kubernetes (une adresse IP par instance de l’interface utilisateur frontale, car elles utilisent tous le même port. La base de données back-end peut utiliser l’une des trois adresses IP tant qu’elle utilise un autre port).
En suivant cet exemple et en l’ajoutant au tableau suivant, vous obtenez :
| Paramètre | Nombre d’adresses IP | Comment et où effectuer cette réservation |
|---|---|---|
| Machines virtuelles AKS Arc, mise à niveau et adresse IP du plan de contrôle de version K8s | Réserver 16 adresses IP | Effectuez cette réservation via des pools IP dans le réseau logique local Azure. |
| Adresses IP de l’équilibreur de charge | 3 adresse IP pour les services Kubernetes, pour l’application de vote de Jane. | Ces adresses IP sont utilisées lorsque vous installez un équilibreur de charge sur le cluster A. Vous pouvez utiliser l’extension MetalLB Arc ou apporter votre propre équilibreur de charge tiers. Vérifiez que cette adresse IP se trouve dans le même sous-réseau que le réseau logique Arc, mais en dehors du pool d’adresses IP défini dans le réseau logique de machine virtuelle Arc. |
Exemples de commandes CLI pour la réservation d’adresses IP pour les clusters et applications Kubernetes
Cette section décrit l’ensemble des commandes exécutées par Jane pour son scénario. Tout d’abord, créez un réseau logique avec un pool d’adresses IP qui a au moins 16 adresses IP. Nous avons créé le pool d’adresses IP avec 20 adresses IP pour fournir la possibilité de mettre à l’échelle le jour N. Pour plus d’informations sur les options de paramètre dans les réseaux logiques, consultez az stack-hci-vm network lnet create:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Ensuite, créez un cluster AKS Arc avec le réseau logique précédent :
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
Vous pouvez maintenant activer l’équilibreur de charge MetalLB avec un pool d’adresses IP de 3 adresses IP, dans le même sous-réseau que le réseau logique de machine virtuelle Arc. Vous pouvez ajouter d’autres pools d’adresses IP ultérieurement si votre application a besoin d’une augmentation. Pour connaître les exigences détaillées, consultez la vue d’ensemble de l’extension MetalLB Arc.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Considérations relatives aux réseaux LNET pour les clusters AKS et les machines virtuelles Arc
Les réseaux logiques sur Azure Local sont utilisés par les clusters AKS et les machines virtuelles Arc. Vous pouvez configurer des réseaux logiques de l’une des 2 façons suivantes :
- Partagez un réseau logique entre les machines virtuelles AKS et Arc.
- Définissez des réseaux logiques distincts pour les clusters AKS et les machines virtuelles Arc.
Le partage d’un réseau logique entre les machines virtuelles AKS et Arc sur Azure Local offre l’avantage d’une communication simplifiée, d’économies de coûts et d’une gestion réseau simplifiée. Toutefois, cette approche présente également des défis potentiels tels que la contention des ressources, les risques de sécurité et la complexité de la résolution des problèmes.
| Critères | Partage d’un réseau logique | Définition de réseaux logiques distincts |
|---|---|---|
| Complexité de la configuration | Configuration plus simple avec un seul réseau, ce qui réduit la complexité de la configuration. | Configuration plus complexe, car vous devez configurer plusieurs réseaux logiques pour les machines virtuelles et les clusters AKS. |
| Évolutivité | Limitations de scalabilité potentielles, car les machines virtuelles Arc et les clusters AKS partagent des ressources réseau. | Plus scalable, car les ressources réseau sont séparées et peuvent être mises à l’échelle indépendamment. |
| Gestion des stratégies réseau | Plus facile à gérer avec un ensemble de stratégies réseau, mais plus difficile à isoler les charges de travail. | Plus facile à isoler les charges de travail, car des stratégies distinctes peuvent être appliquées par réseau logique. |
| Sécurité | Risque accru de vulnérabilités de communication croisée s’il n’est pas correctement segmenté. | Meilleure sécurité, car chaque réseau peut être segmenté et isolé plus strictement. |
| Impact des défaillances réseau | Une défaillance dans le réseau partagé peut affecter les machines virtuelles AKS et Arc simultanément. | Une défaillance d’un réseau affecte uniquement les charges de travail au sein de ce réseau, ce qui réduit le risque global. |
Allocation de plage d’adresses IP pour le CIDR de pod et le CIDR de service
Cette section décrit les plages d’adresses IP utilisées par Kubernetes pour la communication des pods et des services au sein d’un cluster. Ces plages d’adresses IP sont définies pendant le processus de création du cluster AKS et sont utilisées pour affecter des adresses IP uniques aux pods et services au sein du cluster.
CIDR du réseau de pods
CIDR de réseau de pods est une plage d’adresses IP utilisées par Kubernetes pour affecter des adresses IP uniques aux pods individuels s’exécutant dans un cluster Kubernetes. Chaque pod obtient sa propre adresse IP dans cette plage, ce qui permet aux pods de communiquer entre eux et avec les services au sein du cluster. Dans AKS, les adresses IP de pod sont affectées via Calico CNI en mode VXLAN. Calico VXLAN permet de créer des réseaux de superposition, où les adresses IP des pods (à partir du CIDR du réseau de pods) sont virtualisées et tunnelisées via le réseau physique. Dans ce mode, chaque pod reçoit une adresse IP à partir du CIDR du réseau de pods, mais cette adresse IP n’est pas routable directement sur le réseau physique. Au lieu de cela, il est encapsulé dans les paquets réseau et envoyé via le réseau physique sous-jacent pour atteindre son pod de destination sur un autre nœud.
AKS fournit une valeur par défaut 10.244.0.0/16 pour le CIDR du réseau de pods. AKS prend en charge les personnalisations pour le CIDR du réseau de pods. Vous pouvez définir votre propre valeur à l’aide du paramètre lors de la --pod-cidr création du cluster AKS. Vérifiez que la plage d’adresses IP CIDR est suffisamment grande pour prendre en charge le nombre maximal de pods par nœud et sur le cluster Kubernetes.
CIDR du réseau de services
Le CIDR du réseau de services est la plage d’adresses IP réservées aux services Kubernetes tels que LoadBalancers, ClusterIP et NodePort au sein d’un cluster. Kubernetes prend en charge les types de service suivants :
- ClusterIP : type de service par défaut, qui expose le service au sein du cluster. L’adresse IP attribuée à partir du CIDR du réseau de service est accessible uniquement au sein du cluster Kubernetes.
- NodePort : expose le service sur un port spécifique sur l’adresse IP de chaque nœud. ClusterIP est toujours utilisé en interne, mais l’accès externe est via les adresses IP de nœud et un port spécifique.
- LoadBalancer : ce type crée un équilibreur de charge géré par un fournisseur de cloud et expose le service en externe. Le fournisseur de cloud gère généralement l’attribution d’adresses IP externes, tandis que le clusterIP interne reste dans le CIDR du réseau de services.
AKS fournit une valeur par défaut de 10.96.0.0/12 pour le CIDR du réseau de services. AKS ne prend pas en charge les personnalisations pour le CIDR du réseau de services aujourd’hui.
Étapes suivantes
Créer des réseaux logiques pour les clusters Kubernetes sur Azure Local, version 23H2