Limites de ressources, tailles de machine virtuelle et régions pour AKS activés par Azure Arc
S’applique à : AKS sur Azure Stack HCI 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 les Azure Kubernetes Service (AKS) activées par Azure Arc. Les tests ont utilisé la dernière version d’AKS sur Azure Stack HCI.
Spécifications maximales
AKS activé par les déploiements Arc ont été validés 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 publiez une question dans la communauté Azure Stack HCI.
| Ressource | Maximale |
|---|---|
| Serveurs physiques par cluster | 8 |
| Nombre total d'ordinateurs virtuels | 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 du cluster Azure Stack HCI est la suivante :
- Châssis : Serveur Dell PowerEdge R650 ou similaire.
- RAM : RDIMM, 3200 Mt/s, Double classement, 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 : 8 disques durs (2 To ou plus) et 2x 1,6 To NVMe pour prendre en charge les configurations de stockage S2D.
- Réseau : quatre (4) cartes réseau de 100 Gbits (Mellanox ou Intel).
L’ingénierie Microsoft a testé AKS activé par Arc à l’aide de la configuration ci-dessus. Pour un nœud unique. Clusters de basculement Windows à 2 nœuds, 4 nœuds et 8 nœuds. Si vous devez dépasser la configuration testée, consultez Mise à l’échelle d’AKS sur Azure Stack HCI.
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 continu, 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 restreinte afin d’empêcher le déploiement de charges de travail sur celle-ci. La machine virtuelle restreinte est ensuite vidée de tous les conteneurs pour les distribuer à 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 Stack HCI. Bien que les tailles de machines virtuelles telles que les Standard_K8S2_v1 et les Standard_K8S_v1 soient prises en charge pour les déploiements de tests et de faibles besoins en ressources, utilisez ces tailles avec soin et appliquez des tests rigoureux, car elles peuvent entraîner des défaillances inattendues en raison d’un manque de mémoire.
| 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 AKS sur Azure Stack HCI
La mise à l’échelle d’un déploiement AKS sur Azure Stack HCI implique une planification à l’avance en connaissant vos charges de travail et l’utilisation du cluster cible. En outre, tenez compte des ressources matérielles de votre infrastructure sous-jacente, telles que le nombre total de cœurs d’uc, 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, ce 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.
Notes
Un seul hôte AKS peut gérer uniquement 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 prévoyez de déployer dans chaque cluster cible.
Paramètres par défaut qui ne peuvent actuellement pas être modifiés dans AKS
Il existe des configurations et des paramètres par défaut actuellement 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 dans 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 sur la mise à l’échelle kubernetes 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 pool d’adresses
10.96.0.0/16. Le système consomme 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 pouvez uniquement définir la taille des machines virtuelles du plan de contrôle du cluster cible et 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 Azure Stack HCI
- 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 de l’équilibreur de charge.
- Vous souhaitez réserver une partie de la capacité globale d’Azure Stack HCI 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 (7) autres nœuds. Cette configuration garantit que vous disposez d’une réserve pour effectuer une mise à niveau ou d’autres opérations AKS jour 2.
Si vous souhaitez dépasser la limite de 200 machines virtuelles pour un cluster Azure Stack HCI de taille matérielle maximale de huit (8) nœuds, augmentez la taille de la machine virtuelle hôte AKS. Le doublement de la taille entraîne environ le double du nombre de machines virtuelles qu’il peut gérer. Dans un cluster Azure Stack HCI à 8 nœuds, vous pouvez accéder à 8 192 machines virtuelles (8x1024) en fonction des limites de ressources recommandées d’Azure Stack HCI documentées dans les spécifications matérielles maximales prises en charge. Vous devez réserver environ 30 % de la capacité, ce qui vous laisse 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.
Notes
Étant donné que cette configuration n’a pas été testée en grande partie, elle nécessite une approche et une validation minutieuses.
À une telle échelle, 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 que lors de 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 entre les nœuds Azure Stack HCI disponibles à l’aide de la logique de placement Azure Stack HCI.
Important
L’emplacement du nœud n’est pas conservé pendant les mises à niveau de la plateforme et d’AKS et change au fil du temps. Un nœud physique défaillant a également un impact sur la distribution des machines virtuelles entre les nœuds de cluster restants.
Notes
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 temporaires. Lors de la mise à l’échelle des pools de nœuds de cluster cible en 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 les environnements très volumineux, ces opérations, lorsqu’elles sont exécutées en parallèle, peuvent entraîner un épuisement rapide des ressources.
En cas de doute, contactez votre bureau Microsoft local pour obtenir de l’aide ou publiez dans le forum de la communauté Azure Stack HCI.
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour