Partager via

Limites de ressources, tailles de machine virtuelle et régions pour AKS activées par Azure Arc

  • Article

S’applique à : AKS sur Azure Local 22H2, AKS sur Windows Server

Cet article fournit des informations sur les configurations testées, les limites de ressources, les tailles de machine virtuelle et les régions pour Azure Kubernetes Service (AKS) activées par Azure Arc. Les tests ont utilisé la dernière version d’AKS sur Azure Local.

Spécifications maximales

AKS activé par les déploiements Arc a été validé avec les configurations suivantes, y compris les maximums spécifiés. N’oubliez pas que le dépassement de ces limites est sous votre entière responsabilité, et peut entraîner des comportements et défaillances inattendus. Cet article fournit des conseils afin d’éviter les erreurs de configuration courantes, et peut aider à créer une plus grande configuration. En cas de doute, contactez votre bureau Microsoft local pour obtenir de l’aide ou soumettre une question dans la communauté locale Azure.

Ressource Maximum
Serveurs physiques par cluster 8
Nombre total de machines virtuelles 200

Les limites recommandées ont été testées avec les tailles de machine virtuelle par défaut, en fonction du tableau suivant :

Rôle du système Taille de la machine virtuelle
AKS-Host Standard_A4_v2
Nœud plan de contrôle du cluster cible Par défaut
Équilibreur de charge HAProxy du cluster cible (facultatif) Standard_A4_v2
Nœud Worker Linux du cluster cible Standard_K8S3_v1
Nœud Worker windows du cluster cible Standard_K8S3_v1

La configuration matérielle de chaque nœud physique dans le cluster local Azure est la suivante :

  • Châssis : Dell PowerEdge R650 Server ou similaire.
  • RAM : RDIMM, 3200 MT/s, Double rang, total de 256 Go.
  • PROCESSEUR : Deux (2) Intel Xeon Silver 4316 2.3G, 20C/40T, 10,4 GT/s, 30M Cache, Turbo, HT (150 W) DDR4-2666.
  • Disque : disques durs 8x (2 To ou plus) et 2x 1,6 To NVMe pour prendre en charge les configurations de stockage S2D.
  • Réseau : quatre cartes réseau (4) 100 Gbits (Mellanox ou Intel).

Microsoft engineering a testé AKS activé par Arc à l’aide de la configuration ci-dessus. Pour un nœud unique. 2 nœuds, 4 nœuds et 8 clusters de basculement Windows. Si vous avez besoin de dépasser la configuration testée, consultez Mise à l’échelle d’AKS sur Azure Local.

Important

Lorsque vous mettez à niveau un déploiement d’AKS, des ressources supplémentaires sont temporairement consommées. Chaque machine virtuelle est mise à niveau dans un flux de mise à jour propagé, en commençant par les nœuds du plan de contrôle. Pour chaque nœud du cluster Kubernetes, une nouvelle machine virtuelle de nœud est créée. L’ancienne machine virtuelle de nœud est limitée afin d’empêcher le déploiement des charges de travail. La machine virtuelle restreinte est ensuite vidée de tous les conteneurs pour distribuer les conteneurs à d’autres machines virtuelles du système. La machine virtuelle vidée est ensuite supprimée du cluster, arrêtée et remplacée par la nouvelle machine virtuelle mise à jour. Ce processus se répète jusqu’à ce que toutes les machines virtuelles soient mises à jour.

Tailles de VM disponibles

Les tailles de machine virtuelle suivantes pour les nœuds de plan de contrôle, les nœuds Worker Linux et les nœuds Worker Windows sont disponibles pour AKS sur Azure Local. Bien que les tailles de machine virtuelle telles que Standard_K8S2_v1 et Standard_K8S_v1 soient prises en charge pour les tests et les déploiements à faible exigence de ressources, utilisez ces tailles avec soin et appliquez des tests rigoureux, car elles peuvent entraîner des défaillances inattendues en raison de conditions de mémoire insuffisantes.

Taille de la machine virtuelle UC Mémoire (Go) Type de GPU Nombre de GPU
Par défaut 4 4
Standard_A2_v2 2 4
Standard_A4_v2 4 8
Standard_D2s_v3 2 8
Standard_D4s_v3 4 16
Standard_D8s_v3 8 32
Standard_D16s_v3 16 64
Standard_D32s_v3 32 128
Standard_DS2_v2 2 7
Standard_DS3_v2 2 14
Standard_DS4_v2 8 28
Standard_DS5_v2 16 56
Standard_DS13_v2 8 56
Standard_K8S_v1 4 2
Standard_K8S2_v1 2 2
Standard_K8S3_v1 4 6
Standard_NK6 6 12 Tesla T4 1
Standard_NK12 12 24 Tesla T4 2

Régions Azure prises en charge pour l’enregistrement sur Azure

AKS activé par Arc est pris en charge dans les régions Azure suivantes :

  • Australie Est
  • USA Est
  • Asie Sud-Est
  • Europe Ouest

Mise à l’échelle d’AKS sur Azure Local

La mise à l’échelle d’un déploiement AKS sur Azure Local implique la planification en sachant vos charges de travail et l’utilisation cible du cluster. En outre, tenez compte des ressources matérielles dans votre infrastructure sous-jacente, telles que le nombre total de cœurs de processeur, la mémoire totale, le stockage, les adresses IP, etc.

Les exemples suivants supposent que seules les charges de travail AKS sont déployées sur l’infrastructure sous-jacente. Le déploiement de charges de travail non AKS telles que des machines virtuelles autonomes ou en cluster, ou des serveurs de base de données, réduit les ressources disponibles pour AKS, que vous devez prendre en compte.

Avant de commencer, tenez compte des points suivants pour déterminer votre échelle maximale et le nombre de clusters cibles que vous devez prendre en charge :

  • Nombre d’adresses IP disponibles pour les pods dans un cluster cible
  • Nombre d’adresses IP disponibles pour les services Kubernetes dans un cluster cible
  • Nombre de pods dont vous avez besoin pour exécuter vos charges de travail.

Pour déterminer la taille de votre machine virtuelle hôte Azure Kubernetes Service, vous devez connaître le nombre de nœuds Worker et de clusters cibles, car cela détermine la taille de la machine virtuelle hôte AKS. Par exemple :

  • Nombre de clusters cibles dans le système déployé final.
  • Nombre de nœuds, y compris le plan de contrôle, l’équilibreur de charge et les nœuds Worker sur tous les clusters cibles.

Remarque

Un seul hôte AKS ne peut gérer que les clusters cibles sur la même plateforme.

En outre, pour déterminer la taille de votre nœud de plan de contrôle de cluster cible, vous devez connaître le nombre de pods, de conteneurs et de nœuds Worker que vous envisagez de déployer dans chaque cluster cible.

Paramètres par défaut qui ne peuvent actuellement pas être modifiés dans AKS

Il existe actuellement des configurations et des paramètres par défaut non disponibles pour le contrôle client pendant ou après le déploiement. Ces paramètres peuvent limiter la mise à l’échelle d’un cluster cible donné.

  • Le nombre d’adresses IP pour les pods Kubernetes dans un cluster cible est limité au sous-réseau 10.244.0.0/16. Autrement dit, 255 adresses IP par nœud Worker sur tous les espaces de noms Kubernetes peuvent être utilisées pour les pods. Pour voir le CIDR de pod attribué à chaque nœud Worker dans votre cluster, utilisez la commande suivante dans PowerShell :
kubectl get nodes -o json | findstr 'hostname podCIDR'

                    "kubernetes.io/hostname": "moc-lip6cotjt0f",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.2.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-lmb6zqozk4m",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.4.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-wgwhhijxtfv",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.5.0/24",
                "podCIDRs": [

Dans l’exemple, vous pouvez voir trois nœuds avec trois CIDR, chacun capable d’héberger 254 pods. La documentation de mise à l’échelle Kubernetes vous recommande de ne pas dépasser 110 pods par nœud pour des raisons de performances. Consultez considérations relatives aux clusters volumineux.

Autres points à considérer :

  • Le nombre d’adresses IP pour les services Kubernetes, en dehors du pool d’adresses IP virtuelles que vous avez alloué, provient du 10.96.0.0/16 pool d’adresses. Le système utilise l’une des 255 adresses disponibles pour le serveur d’API Kubernetes.
  • La taille de la machine virtuelle hôte AKS ne peut être définie qu’au moment de l’installation, lorsque vous exécutez Set-AksHciConfig pour la première fois. Vous ne pouvez pas la changer ultérieurement.
  • Vous ne pouvez définir la taille du plan de contrôle du cluster cible que les machines virtuelles de l’équilibreur de charge au moment de la création du cluster cible.

Exemple de mise à l’échelle

L’exemple de mise à l’échelle suivant est basé sur ces hypothèses/cas d’usage généraux :

  • Vous souhaitez être en mesure de tolérer complètement la perte d’un nœud physique dans le cluster local Azure.
  • Vous souhaitez prendre en charge la mise à niveau des clusters cibles vers des versions plus récentes
  • Vous souhaitez autoriser la haute disponibilité des nœuds du plan de contrôle de cluster cible et des nœuds d’équilibreur de charge.
  • Vous souhaitez réserver une partie de la capacité locale Azure globale pour ces cas.

Suggestions

  • Pour des performances optimales, veillez à définir au moins 15 % (100/8=12,5) de capacité de cluster de côté pour permettre à toutes les ressources d’un nœud physique d’être redistribuées aux sept autres nœuds (7). Cette configuration garantit que vous disposez d’une réserve disponible pour effectuer une mise à niveau ou une autre opération AKS jour deux.

  • Si vous souhaitez dépasser la limite de 200 machines virtuelles pour un cluster local Azure de taille maximale de huit (8) nœuds, augmentez la taille de la machine virtuelle hôte AKS. Le doublement de la taille entraîne environ un doublement du nombre de machines virtuelles qu’il peut gérer. Dans un cluster local Azure à 8 nœuds, vous pouvez accéder à 8 192 machines virtuelles (8x1024) basées sur les limites de ressources recommandées par Azure Local documentées dans les spécifications matérielles maximales prises en charge. Vous devez réserver environ 30 % de capacité, ce qui vous laisse avec une limite théorique de 5 734 machines virtuelles sur tous les nœuds.

    • Standard_D32s_v3, pour l’hôte AKS avec 32 cœurs et 128 Go, peut prendre en charge un maximum de 1 600 nœuds.

    Remarque

    Étant donné que cette configuration n’a pas été testée de manière approfondie, elle nécessite une approche et une validation minutieuses.

  • À une échelle comme celle-ci, vous pouvez fractionner l’environnement en au moins 8 clusters cibles avec 200 nœuds Worker chacun.

  • Pour exécuter 200 nœuds Worker dans un cluster cible, vous pouvez utiliser le plan de contrôle et la taille de l’équilibreur de charge par défaut. Selon le nombre de pods par nœud, vous pouvez monter au moins une taille sur le plan de contrôle et utiliser Standard_D8s_v3.

  • Selon le nombre de services Kubernetes hébergés dans chaque cluster cible, vous devrez peut-être augmenter la taille de la machine virtuelle de l’équilibreur de charge, ainsi qu’à la création du cluster cible pour vous assurer que les services peuvent être atteints avec des performances élevées et que le trafic est acheminé en conséquence.

Le déploiement d’AKS activé par Arc distribue les nœuds Worker pour chaque pool de nœuds d’un cluster cible sur les nœuds locaux Azure disponibles à l’aide de la logique de placement locale Azure.

Important

Le positionnement du nœud n’est pas conservé pendant les mises à niveau de la plateforme et AKS et change au fil du temps. Un nœud physique ayant échoué a également un impact sur la distribution des machines virtuelles sur les nœuds de cluster restants.

Remarque

N’exécutez pas plus de quatre créations de cluster cible en même temps si le cluster physique est déjà plein à 50 %, car cela peut entraîner une contention de ressources temporaire. Lors de la mise à l’échelle des pools de nœuds de cluster cibles par un grand nombre, prenez en compte les ressources physiques disponibles, car AKS ne vérifie pas la disponibilité des ressources pour les processus de création/mise à l’échelle en parallèle. Veillez à toujours disposer de suffisamment de réserve pour permettre les mises à niveau et le basculement. En particulier dans des environnements très volumineux, ces opérations, lorsqu’elles sont exécutées en parallèle, peuvent entraîner une épuisement rapide des ressources.

En cas de doute, contactez votre bureau Microsoft local pour obtenir de l’aide ou publier dans le forum de la communauté locale Azure.

Étapes suivantes