Configuration système requise pour AKS activé par Azure Arc sur Azure Stack HCI 22H2
S’applique à : Azure Stack HCI, versions 22H2 ; Windows Server 2022, Windows Server 2019
Cet article décrit la configuration requise pour la configuration Azure Kubernetes Service (AKS) activée par Azure Arc. Pour obtenir une vue d’ensemble d’AKS activé par Arc, consultez la vue d’ensemble d’AKS.
Configuration matérielle requise
Microsoft recommande d’acheter une solution matérielle/logicielle Azure Stack HCI validée, proposée par nos partenaires. Ces solutions sont conçues, assemblées et validées pour s’exécuter sur notre architecture de référence et pour garantir la compatibilité et la fiabilité, ce qui vous permet d’être opérationnel rapidement. Vous devez vérifier que les systèmes, les composants, les appareils et les pilotes que vous utilisez sont certifiés Windows Server d’après le catalogue Windows Server. Pour connaître les solutions validées, consultez le site web des solutions Azure Stack HCI .
Important
Les systèmes hôtes pour les déploiements de production doivent être du matériel physique. La virtualisation imbriquée, caractérisée par le déploiement d’Azure Stack HCI ou Windows Server sur une machine virtuelle et l’installation d’AKS sur cette machine virtuelle, n’est pas prise en charge.
Spécifications matérielles maximales prises en charge
Les déploiements AKS sur Azure Stack HCI et Windows Server qui dépassent les spécifications suivantes ne sont pas pris en charge :
| Ressource | Maximale |
|---|---|
| Serveurs physiques par cluster | 8 (Azure Stack HCI version 22H2 et Windows Server) |
| Nombre total d'ordinateurs virtuels | 200 |
Exigences de calcul
Exigences minimales de mémoire
Vous pouvez configurer votre cluster AKS de la manière suivante, pour exécuter AKS sur un seul nœud Windows Server avec une RAM limitée :
| Type de cluster | Taille VM de plan de contrôle | Nœud Worker | Pour les opérations de mise à jour | Équilibrage de charge |
|---|---|---|---|---|
| Hôte AKS | Taille VM Standard_A4_v2 = 8 Go | N/A : l’hôte AKS n’a pas de nœuds Worker. | 8 Go | N/A : l’hôte AKS utilise kubevip pour l’équilibrage de charge. |
| Cluster de charge de travail | Taille VM Standard_A4_v2 = 8 Go | Standard_K8S3_v1 pour 1 nœud worker = 6 Go | Peut réutiliser ces 8 Go réservés pour la mise à niveau du cluster de charge de travail. | N/A si kubevip est utilisé pour l’équilibrage de charge (au lieu de l’équilibreur de charge HAProxy par défaut). |
Configuration minimale totale : 30 Go de RAM.
Cette exigence minimale concerne un déploiement AKS avec un nœud Worker pour l’exécution d’applications conteneurisées. Si vous choisissez d’ajouter des nœuds Worker ou un équilibreur de charge HAProxy, l’exigence finale de RAM change en conséquence.
Exigences de calcul recommandées
| Environnement | Cœurs de processeur par serveur | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256 Go |
| Cluster de basculement Windows Server | 32 | 256 Go |
| Windows Server mononœud | 16 | 128 Go |
Pour un environnement de production, le dimensionnement final dépend de l’application et du nombre de nœuds Worker que vous prévoyez de déployer sur le cluster Azure Stack HCI ou Windows Server. Si vous choisissez d’exécuter AKS sur un serveur Windows Server à nœud unique, vous n’obtenez pas de fonctionnalités telles que la haute disponibilité qui accompagnent l’exécution d’AKS sur un cluster Azure Stack HCI, Windows Server ou un cluster de basculement Windows Server.
Les autres exigences de calcul pour AKS sur Azure Stack HCI et Windows Server sont conformes aux exigences d’Azure Stack HCI. Pour plus d’informations sur la configuration requise pour le serveur Azure Stack HCI, consultez Configuration système requise pour Azure Stack HCI .
Vous devez installer le même système d’exploitation sur chaque serveur du cluster. Si vous utilisez Azure Stack HCI, le même système d’exploitation et la même version doivent être identiques sur chaque serveur du cluster. Si vous utilisez Windows Server Datacenter, le même système d’exploitation et la même version doivent être identiques sur chaque serveur du cluster. Chaque système d’exploitation doit utiliser la région en-us et les sélections de langue. Vous ne pouvez pas changer ces paramètres après l’installation.
Exigences de stockage
AKS sur Azure Stack HCI et Windows Server prend en charge les implémentations de stockage suivantes :
| Nom | Type de stockage | Capacité requise |
|---|---|---|
| Clusters Azure Stack HCI | Volumes partagés de cluster | 1 To |
| Cluster de basculement Windows Server Datacenter | Volumes partagés de cluster | 1 To |
| Windows Server Datacenter mononœud | Stockage en attachement direct | 500 Go |
Pour un cluster Azure Stack HCI ou Windows Server, deux configurations de stockage sont prises en charge pour l’exécution des charges de travail de machine virtuelle :
- Le stockage hybride équilibre les performances et la capacité en utilisant un stockage flash et des lecteurs de disque dur (HDD).
- Le stockage 100 % flash optimise les performances en utilisant des disques SSD (Solid-State Drives) ou NVMe.
Les systèmes qui ont uniquement un stockage HDD ne sont pas pris en charge par Azure Stack HCI et sont, dès lors, déconseillés pour exécuter AKS sur Azure Stack HCI et Windows Server. Pour plus d’informations sur les configurations de lecteur recommandées, consultez la documentation Azure Stack HCI. Tous les systèmes validés dans le catalogue Azure Stack HCI appartiennent à l’une de ces deux configurations de stockage prises en charge.
Kubernetes utilise etcd pour stocker l’état des clusters. Etcd stocke la configuration, les spécifications et l’état des pods en cours d’exécution. Par ailleurs, Kubernetes utilise le magasin pour la découverte de service. En tant que composant de coordination pour le fonctionnement de Kubernetes et des charges de travail qu’il prend en charge, la latence et le débit vers etcd sont essentiels. Vous devez exécuter AKS sur un disque SSD. Pour plus d’informations, consultez Performances au etcd.io.
Vous pouvez déployer un cluster Windows Server Datacenter avec un stockage local ou un stockage SAN. Pour le stockage local, il est recommandé d’utiliser le espaces de stockage direct intégré ou une solution virtual SAN certifiée équivalente pour créer une infrastructure hyperconvergée qui présente des volumes partagés de cluster à utiliser par les charges de travail. Pour les espaces de stockage direct, votre stockage doit être hybride (flash + HDD) pour équilibrer les performances et la capacité, ou 100 % flash (SSD, NVMe) pour optimiser les performances. Si vous optez pour un déploiement avec stockage SAN, assurez-vous que votre stockage SAN offre suffisamment de performances pour exécuter plusieurs charges de travail de machines virtuelles. Le stockage SAN basé sur hdD plus ancien peut ne pas fournir les niveaux de performances requis pour exécuter plusieurs charges de travail de machine virtuelle, et vous pouvez rencontrer des problèmes de performances et des délais d’expiration.
Pour les déploiements Windows Server mononœud avec un stockage local, l’utilisation d’un stockage 100 % flash (SSD, NVMe) est vivement recommandée afin d’offrir les performances nécessaires pour héberger plusieurs machines virtuelles sur un seul hôte physique. Sans stockage flash, les niveaux de performances inférieurs sur les disques durs peuvent entraîner des problèmes de déploiement et des délais d’expiration.
Configuration requise pour le réseau
Les exigences suivantes s’appliquent à un cluster Azure Stack HCI 22H2 et à un cluster Windows Server Datacenter. Pour connaître la configuration réseau requise sur Azure Stack HCI 23H2, consultez Configuration réseau requise.
- Pour Azure Stack HCI 22H2 et Windows Server, vérifiez qu’un commutateur virtuel externe existant est configuré si vous utilisez Windows Admin Center. Pour les clusters HCI ou Windows Server, ce commutateur et son nom doivent être identiques sur tous les nœuds de cluster. Pour HCI 23H2, consultez la configuration système réseau requise.
- Vérifiez que vous avez désactivé IPv6 sur toutes les cartes réseau.
- Pour un déploiement réussi, les nœuds de cluster Azure Stack HCI ou Windows Server et les machines virtuelles du cluster Kubernetes doivent disposer d’une connectivité Internet externe.
- Assurez-vous que tous les sous-réseaux que vous définissez pour le cluster sont routables entre eux et vers Internet.
- Vérifiez qu’il y a une connectivité réseau entre les hôtes Azure Stack HCI et les machines virtuelles du locataire.
- La résolution de noms DNS est requise pour que tous les nœuds puissent communiquer entre eux.
- (Recommandé) Activez les mises à jour DNS dynamiques dans votre environnement DNS pour permettre à AKS d’inscrire le nom de cluster générique de l’agent cloud dans le système DNS à des fins de découverte.
Affectation d’adresses IP
Dans AKS activé par Arc, les réseaux virtuels sont utilisés pour allouer des adresses IP aux ressources Kubernetes qui en ont besoin, comme indiqué précédemment. Vous avez le choix entre deux modèles de mise en réseau, en fonction de l’architecture réseau AKS souhaitée.
Notes
L’architecture de mise en réseau virtuelle définie ici pour vos déploiements AKS est différente de l’architecture de mise en réseau physique sous-jacente dans votre centre de données.
- Réseau IP statique : le réseau virtuel alloue des adresses IP statiques au serveur d’API de cluster Kubernetes, aux nœuds Kubernetes, aux machines virtuelles sous-jacentes, aux équilibreurs de charge et aux services Kubernetes que vous exécutez sur votre cluster.
- Mise en réseau DHCP : le réseau virtuel alloue des adresses IP dynamiques aux nœuds Kubernetes, aux machines virtuelles sous-jacentes et aux équilibreurs de charge à l’aide d’un serveur DHCP. Des adresses IP statiques sont toujours allouées au serveur d’API de cluster Kubernetes et à tous les services Kubernetes que vous exécutez sur votre cluster.
Réservation d’adresse IP minimale
Au minimum, vous devez réserver le nombre suivant d’adresses IP pour votre déploiement :
| Type de cluster | Nœud Plan de contrôle | Nœud Worker | Pour les opérations de mise à jour | Équilibrage de charge |
|---|---|---|---|---|
| Hôte AKS | 1 IP | N/D | 2 IP | N/D |
| Cluster de charge de travail | 1 IP par nœud | 1 IP par nœud | 5 IP | 1 IP |
En outre, vous devez réserver le nombre suivant d’adresses IP pour votre pool d’adresses IP virtuelles :
| Type de ressource | Nombre d’adresses IP |
|---|---|
| Serveur d’API de cluster | 1 par cluster |
| Services Kubernetes | 1 par service |
Comme vous pouvez le voir, le nombre d’adresses IP requises varie en fonction de l’architecture AKS et du nombre de services que vous exécutez sur votre cluster Kubernetes. Nous vous recommandons de réserver un total de 256 adresses IP (sous-réseau /24) pour votre déploiement.
Pour plus d’informations sur la configuration réseau requise, consultez Concepts de mise en réseau des nœuds dans AKS et Concepts de mise en réseau de conteneurs dans AKS.
Configuration requise des ports réseau et URL
AKS activé par les exigences d’Arc
Lors de la création d’un cluster Kubernetes sur Azure Stack HCI, les ports de pare-feu suivants sont automatiquement ouverts sur chaque serveur du cluster.
Si les nœuds de cluster physique Azure Stack HCI et les machines virtuelles de cluster Azure Kubernetes se trouvent sur deux réseaux virtuels isolés, ces ports doivent être ouverts au niveau du pare-feu entre eux :
| Port | Source | Description | Notes de pare-feu |
|---|---|---|---|
| 22 | Machines virtuelles AKS | Requis pour collecter les journaux lors de l’utilisation de Get-AksHciLogs. |
Si vous utilisez des réseaux locaux virtuels distincts, les hôtes Hyper-V physiques doivent accéder aux machines virtuelles AKS sur ce port. |
| 6443 | Machines virtuelles AKS | Requis pour communiquer avec les API Kubernetes. | Si vous utilisez des réseaux locaux virtuels distincts, les hôtes Hyper-V physiques doivent accéder aux machines virtuelles AKS sur ce port. |
| 45000 | Hôte Hyper-V physique | serveur wssdAgent gRPC. | Aucune règle inter-VLAN n’est nécessaire. |
| 45001 | Hôte Hyper-V physique | Authentification wssdAgent gRPC. | Aucune règle inter-VLAN n’est nécessaire. |
| 46000 | Machines virtuelles AKS | wssdCloudAgent à lbagent. | Si vous utilisez des réseaux locaux virtuels distincts, les hôtes Hyper-V physiques doivent accéder aux machines virtuelles AKS sur ce port. |
| 55000 | Ressource de cluster (-CloudServiceCIDR) | Serveur gRPC de l’agent cloud. | Si vous utilisez des réseaux locaux virtuels distincts, les machines virtuelles AKS doivent accéder à l’adresse IP de la ressource de cluster sur ce port. |
| 65 000 | Ressource de cluster (-CloudServiceCIDR) | Authentification gRPC de l’agent cloud. | Si vous utilisez des réseaux locaux virtuels distincts, les machines virtuelles AKS doivent accéder à l’adresse IP de la ressource de cluster sur ce port. |
Si votre réseau nécessite l’utilisation d’un serveur proxy pour se connecter à Internet, consultez Utiliser les paramètres du serveur proxy sur AKS.
Les URL suivantes doivent être ajoutées à votre liste d’autorisation :
| URL | Port | Notes |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Utilisé lors du téléchargement du catalogue de produits AKS sur Azure Stack HCI, des bits de produit et des images de système d’exploitation depuis SFS. Se produit lors de l’exécution Set-AksHciConfig et à chaque téléchargement à partir de SFS. |
| msk8s.f.tlu.dl.delivery.mp.microsoft.com msk8s.b.tlu.dl.delivery.mp.microsoft.com | 80 | Utilisé lors du téléchargement du catalogue de produits AKS sur Azure Stack HCI, des bits de produit et des images de système d’exploitation depuis SFS. Se produit lors de l’exécution Set-AksHciConfig et à chaque téléchargement à partir de SFS. |
| login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net | 443 | Utilisé pour la connexion à Azure pendant l’exécution de Set-AksHciRegistration. |
| point de terminaison ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net US : wus2replica*.blob.core.windows.net | 443 | Requis pour extraire des images conteneurs lors de l’exécution de Install-AksHci. |
| <region.dp.kubernetesconfiguration.azure.com> | 443 | Requis pour intégrer des clusters hybrides AKS à Azure Arc. |
| gbl.his.arc.azure.com | 443 | Requis pour obtenir le point de terminaison régional pour l’extraction des certificats d’identité managée affectée par le système. |
| *.his.arc.azure.com | 443 | Nécessaire pour tirer (pull) les certificats d’identité managée affectée par le système. |
| k8connecthelm.azureedge.net | 443 | Kubernetes avec Arc utilise Helm 3 pour déployer des agents Azure Arc sur le cluster de gestion AKS-HCI. Ce point de terminaison est nécessaire pour le téléchargement du client Helm afin de faciliter le déploiement du graphique helm de l’agent. |
| *.arc.azure.net | 443 | Requis pour gérer les clusters hybrides AKS dans Portail Azure. |
| dl.k8s.io | 443 | Requis pour télécharger et mettre à jour les fichiers binaires Kubernetes pour Azure Arc. |
| akshci.azurefd.net | 443 | Requis pour la facturation d’AKS sur Azure Stack HCI lors de l’exécution de Install-AksHci. |
| gcs.prod.monitoring.core.windows.net v20.events.data.microsoft.com | 443 | Utilisé régulièrement pour envoyer les données de diagnostic requises par Microsoft à partir de l’hôte Azure Stack HCI ou Windows Server. |
Notes
AKS activé par Arc stocke et traite les données client. Par défaut, les données client restent dans la région dans laquelle le client déploie le service instance. Ces données sont stockées dans des centres de données régionaux gérés par Microsoft. Pour les régions avec des exigences de résidence des données, les données client sont toujours conservées dans la même région.
Exigences d’URL supplémentaires pour les fonctionnalités Azure Arc
La liste d’URL précédente couvre les URL minimales requises pour connecter votre service AKS à Azure à des fins de facturation. Vous devez autoriser des URL supplémentaires si vous souhaitez utiliser la connexion au cluster, les emplacements personnalisés, Azure RBAC et d’autres services Azure tels qu’Azure Monitor, etc., sur votre cluster de charge de travail AKS. Pour obtenir la liste complète des URL Arc, consultez Configuration réseau requise pour Kubernetes avec Azure Arc.
Vous devez également consulter les URL Azure Stack HCI. Étant donné qu’Arc pour les agents serveur est désormais installé par défaut sur les nœuds Azure Stack HCI à partir d’Azure Stack HCI 21H2 et versions ultérieures, vous devez également passer en revue les URL des agents de serveur Arc pour les agents de serveur.
Clusters étendus dans AKS
Comme indiqué dans la vue d’ensemble des clusters étendus, le déploiement d’AKS sur Azure Stack HCI et Windows Server à l’aide de clusters étendus Windows n’est pas pris en charge. Nous vous recommandons d’utiliser une approche de sauvegarde et de récupération d’urgence pour la continuité des opérations de votre centre de données. Pour plus d’informations, consultez Effectuer une sauvegarde ou une restauration de cluster de charge de travail à l’aide de Velero et du stockage Blob Azure sur Azure Stack HCI et Windows Server, et Déployer des configurations sur AksHci à l’aide de GitOps avec Flux v2 pour la continuité des applications.
Impératifs liés à Windows Admin Center
Windows Admin Center est l’interface utilisateur permettant de créer et de gérer AKS activé par Azure Arc. Pour utiliser Windows Admin Center avec AKS sur Azure Stack HCI et Windows Server, vous devez répondre à tous les critères de la liste suivante.
Voici la configuration requise pour l’ordinateur exécutant la passerelle Windows Admin Center :
- Windows 10 ou Windows Server.
- Inscrit auprès d’Azure.
- Dans le même domaine que le cluster Azure Stack HCI ou Windows Server Datacenter.
- Un abonnement Azure sur lequel vous disposez de droits de propriétaire. Vous pouvez case activée votre niveau d’accès en accédant à votre abonnement et en sélectionnant Contrôle d’accès (IAM) sur le côté gauche du Portail Azure, puis en sélectionnant Afficher mon accès.
Conditions requises pour Azure
Vous devez vous connecter à votre compte Azure.
Compte et abonnement Azure
Si vous n’avez pas encore de compte Azure, créez-en un. Vous pouvez utiliser un abonnement existant de n’importe quel type :
- Compte gratuit avec des crédits Azure pour les étudiants ou les abonnés Visual Studio.
- Abonnement Paiement à l’utilisation avec une carte de crédit.
- Abonnement obtenu via un Contrat Entreprise.
- Abonnement obtenu via le programme Fournisseur de solutions cloud.
autorisations Microsoft Entra, rôle et niveau d’accès
Vous devez disposer des autorisations suffisantes pour inscrire une application auprès de votre locataire Microsoft Entra.
Pour vérifier que vous disposez d’autorisations suffisantes, suivez les informations ci-dessous :
- Accédez à la Portail Azure et sélectionnez Rôles et administrateurs sous Microsoft Entra ID pour case activée votre rôle.
- Si votre rôle est Utilisateur, vous devez vérifier que les non-administrateurs peuvent inscrire des applications.
- Pour case activée si vous pouvez inscrire des applications, accédez à Paramètres utilisateur sous le service Microsoft Entra pour case activée si vous êtes autorisé à inscrire une application.
Si le paramètre d’inscriptions d’applications est défini sur Non, seuls les utilisateurs disposant d’un rôle d’administrateur peuvent inscrire ces types d’applications. Pour en savoir plus sur les rôles d’administrateur disponibles et les autorisations spécifiques dans Microsoft Entra ID qui sont accordées à chaque rôle, consultez Microsoft Entra rôles intégrés. Si le rôle Utilisateur est attribué à votre compte, mais que le paramètre d’inscription d’applications est limité aux utilisateurs administrateurs, demandez à votre administrateur de vous attribuer l’un des rôles d’administrateur pouvant créer et gérer tous les aspects des inscriptions d’applications ou d’autoriser les utilisateurs à inscrire des applications.
Si vous ne disposez pas d’autorisations suffisantes pour inscrire une application et que votre administrateur ne peut pas vous accorder ces autorisations, le moyen le plus simple de déployer AKS consiste à demander à votre administrateur Azure de créer un principal de service avec les autorisations appropriées. Les administrateurs peuvent consulter la section suivante pour savoir comment créer un principal de service.
Rôle d’abonnement et niveau d’accès Azure
Pour vérifier votre niveau d’accès, accédez à votre abonnement, sélectionnez Contrôle d’accès (IAM) à gauche du portail Azure, puis Voir mon accès.
- Si vous utilisez Windows Admin Center pour déployer un hôte AKS ou un cluster de charge de travail AKS, vous devez disposer d’un abonnement Azure sur lequel vous êtes propriétaire.
- Si vous utilisez PowerShell pour déployer un hôte AKS ou un cluster de charge de travail AKS, l’utilisateur qui inscrit le cluster doit avoir au moins l’un des éléments suivants :
- Un compte d’utilisateur avec le rôle Propriétaire intégré.
- Un principal de service avec l’un des niveaux d’accès suivants :
- Rôle contributeur intégré.
- Rôle propriétaire intégré.
Si votre abonnement Azure passe par un contrat EA ou CSP, le moyen le plus simple de déployer AKS consiste à demander à votre administrateur Azure de créer un principal de service avec les autorisations appropriées. Les administrateurs peuvent case activée la section suivante sur la création d’un principal de service.
Facultatif : créer un principal de service
Exécutez les étapes suivantes pour créer un principal de service avec le rôle propriétaire intégré. Seuls les propriétaires d’abonnement peuvent créer des principaux de service avec l’attribution de rôle appropriée. Vous pouvez case activée votre niveau d’accès en accédant à votre abonnement, en sélectionnant Contrôle d’accès (IAM) sur le côté gauche du Portail Azure, puis en sélectionnant Afficher mon accès.
Définissez les variables PowerShell suivantes dans une fenêtre d’administration PowerShell. Vérifiez que l’abonnement et le locataire sont ce que vous souhaitez utiliser pour inscrire votre hôte AKS pour la facturation :
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Installez et importez le module PowerShell AKS :
Install-Module -Name AksHci
Connectez-vous à Azure avec la commande PowerShell Connect-AzAccount :
Connect-AzAccount -tenant $tenantID
Définissez l’abonnement que vous souhaitez utiliser pour inscrire votre hôte AKS à la facturation en tant qu’abonnement par défaut en exécutant la commande Set-AzContext :
Set-AzContext -Subscription $subscriptionID
Vérifiez que votre contexte de connexion est correct en exécutant la commande PowerShell Get-AzContext. Vérifiez que l’abonnement, le locataire et le compte sont les éléments que vous souhaitez utiliser pour inscrire votre hôte AKS pour la facturation :
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Créez un principal du service en exécutant la commande PowerShell New-AzADServicePrincipal . Cette commande crée un principal de service avec le rôle Propriétaire et définit l’étendue au niveau de l’abonnement. Pour plus d’informations sur la création de principaux de service, consultez Créer un principal de service Azure avec Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Récupérez le mot de passe du principal de service en exécutant la commande suivante. Notez que cette commande fonctionne uniquement pour Az.Accounts 2.6.0 ou version antérieure. Nous téléchargeons automatiquement le module Az.Accounts 2.6.0 lorsque vous installez le module AksHci PowerShell :
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
À partir de la sortie précédente, vous avez maintenant l’ID d’application et le secret disponibles lors du déploiement d’AKS. Vous devez prendre note de ces éléments et les stocker en toute sécurité. Avec cette création, dans le Portail Azure, sous Abonnements, Access Control, puis Attributions de rôles, vous devez voir votre nouveau principal de service.
Groupe de ressources Azure
Vous devez disposer d’un groupe de ressources Azure dans la région Australie Est, USA Est, Asie Sud-Est ou Europe Ouest avant l’inscription.
Régions Azure
Avertissement
AKS Arc prend actuellement en charge la création de cluster exclusivement dans les régions Azure spécifiées suivantes. Si vous tentez de déployer dans une région en dehors de cette liste, un échec de déploiement se produit.
Le service AKS Arc est utilisé pour l’inscription, la facturation et la gestion. Il est actuellement pris en charge dans les régions suivantes :
- USA Est
- États-Unis - partie centrale méridionale
- Europe Ouest
spécifications relatives à Active Directory ;
Pour qu’un cluster de basculement AKS avec au moins 2 nœuds physiques fonctionne de manière optimale dans un environnement Active Directory, vérifiez que les exigences suivantes sont remplies :
Notes
Active Directory n’est pas requis pour les déploiements Azure Stack HCI ou Windows Server à nœud unique.
- Configurez la synchronisation de l’heure pour que la divergence ne dépasse pas 2 minutes sur tous les nœuds de cluster et le contrôleur de domaine. Pour plus d’informations sur la définition de la synchronisation de l’heure, consultez Service de temps Windows.
- Vérifiez que le ou les comptes d’utilisateur utilisés pour ajouter une mise à jour et gérer les clusters AKS ou Windows Server Datacenter disposent des autorisations appropriées dans Active Directory. Si vous utilisez des unités d’organisation (UO) pour gérer les stratégies de groupe pour les serveurs et les services, le ou les comptes d’utilisateur nécessitent des autorisations de liste, de lecture, de modification et de suppression sur tous les objets de l’unité d’organisation.
- Utilisez une unité d’organisation distincte pour les serveurs et les services de vos clusters AKS ou Windows Server Datacenter. Cela vous permettra de contrôler l’accès et les autorisations avec plus de granularité.
- Si vous utilisez des modèles GPO sur des conteneurs dans Active Directory, vérifiez que le déploiement d’AKS sur Azure Stack HCI et Windows Server est exempté de la stratégie.
Étapes suivantes
Après avoir rempli tous les prérequis ci-dessus, vous pouvez configurer un hôte AKS sur Azure Stack HCI en utilisant :
Commentaires
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour