Configuration système requise pour AKS activée 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 les conditions requises pour configurer 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. Consultez le site web des solutions Azure Stack HCI pour obtenir des solutions validées.
Important
Les systèmes hôtes pour les déploiements de production doivent être matériels physiques. La virtualisation imbriquée, caractérisée par le déploiement d’Azure Stack HCI ou de Windows Server sur une machine virtuelle et l’installation d’AKS dans 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 | Maximum |
|---|---|
| Serveurs physiques par cluster | 8 (Azure Stack HCI version 22H2 et Windows Server) |
| Nombre total de machines virtuelles | 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 | Équilibreur 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 cette 8 Go réservée 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 requise : 30 Go de RAM.
Cette configuration minimale est requise pour 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, la dernière exigence de RAM change en conséquence.
Exigences de calcul recommandées
| Environment | 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 envisagez de déployer sur le cluster Azure Stack HCI ou Windows Server. Si vous choisissez d’exécuter AKS sur un serveur Windows à nœud unique, vous n’obtenez pas de fonctionnalités telles que la haute disponibilité qui sont fournies avec l’exécution d’AKS sur un cluster Azure Stack HCI ou un cluster Windows Server ou un cluster de basculement Windows Server.
D’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 la 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 et les sélections linguistiques en-us . 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 attaché directement | 500 Go |
Pour un cluster Azure Stack HCI ou Windows Server, il existe deux configurations de stockage prises en charge pour l’exécution de 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 à 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 SAN virtuelle 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. Un 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 conditions 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 la configuration réseau requise.
- Pour Azure Stack HCI 22H2 et Windows Server, vérifiez que vous disposez d’un commutateur virtuel externe existant 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 requise pour le réseau.
- 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.
- Vérifiez que tous les sous-réseaux que vous définissez pour le cluster sont routables entre eux et sur 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 les nécessitent, comme indiqué précédemment. Il existe deux modèles de mise en réseau parmi lesquels choisir, en fonction de l’architecture de mise en réseau AKS souhaitée.
Remarque
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.
- Mise en 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 | Équilibreur de charge |
|---|---|---|---|---|
| Hôte AKS | 1 IP | NA | 2 IP | NA |
| 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 est variable 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 les exigences de mise en réseau, consultez les concepts de mise en réseau des nœuds dans AKS et les concepts de mise en réseau de conteneurs dans AKS.
Configuration requise des ports réseau et URL
Configuration requise pour AKS activée par 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 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 gRPC wssdAgent. | 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. |
| 65000 | 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 verte :
| URL | Port | Notes |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Utilisé lors du téléchargement d’AKS sur le catalogue de produits local Azure, les bits de produit et les images de système d’exploitation à partir de SFS. Se produit lors de l’exécution Set-AksHciConfig et de tout téléchargement à partir de SFS. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Utilisé lors du téléchargement d’AKS sur le catalogue de produits local Azure, les bits de produit et les images de système d’exploitation à partir de SFS. Se produit lors de l’exécution Set-AksHciConfig et de tout 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. |
ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net point de terminaison AMÉRICAIN : 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 locale Azure. Ce point de terminaison est nécessaire au téléchargement du client Helm pour faciliter le déploiement du graphique helm de l’agent. |
| *.arc.azure.net | 443 | Nécessaire pour gérer les clusters hybrides AKS dans Portail Azure. |
| dl.k8s.io | 443 | Requis pour télécharger et mettre à jour des fichiers binaires Kubernetes pour Azure Arc. |
| akshci.azurefd.net | 443 | Obligatoire pour AKS sur la facturation locale Azure lors de l’exécution Install-AksHci. |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Utilisé régulièrement pour envoyer des données de diagnostic requises par Microsoft à partir de l’hôte Azure Local ou Windows Server. |
Remarque
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 l’instance de service. Ces données sont stockées dans des centres de données gérés par Microsoft régionaux. Pour les régions avec les 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 d’Azure Arc
La liste d’URL précédente couvre les URL minimales requises pour vous permettre de connecter votre service AKS à Azure pour la 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 comme Azure Monitor, etc., sur votre cluster de charge de travail AKS. Pour obtenir la liste complète des URL Arc, consultez la configuration réseau Kubernetes avec Azure Arc.
Vous devez également consulter les URL Azure Stack HCI. Dans la mesure où Arc pour les agents de serveur est maintenant 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 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é opérationnelle 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 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 assurer 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 les conditions requises 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 des droits de propriétaire. Vous pouvez vérifier 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 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, rôle et niveau d’accès Microsoft Entra
Vous devez disposer d’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 au Portail Azure, puis sélectionnez Rôles et administrateurs sous Microsoft Entra ID pour vérifier votre rôle.
- Si votre rôle est Utilisateur, vous devez vérifier que les non-administrateurs peuvent inscrire des applications.
- Pour vérifier si vous pouvez inscrire des applications, accédez aux paramètres utilisateur sous le service Microsoft Entra pour vérifier si vous êtes autorisé à inscrire une application.
Si le paramètre d’inscriptions d’application 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 l’ID Microsoft Entra qui sont attribués à chaque rôle, consultez rôles intégrés Microsoft Entra. 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 n’avez pas suffisamment d’autorisations 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’une des options suivantes :
Si votre abonnement Azure est via 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 vérifier 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 vérifier 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 Sur 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 pour 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 ce 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 d’un 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 PowerShell AksHci :
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
À partir de la sortie précédente, vous disposez maintenant de l’ID d’application et du secret disponibles lors du déploiement d’AKS. Vous devez noter ces articles et les stocker en toute sécurité. Avec cela créé, dans le Portail Azure, sous Abonnements, Contrôle d’accès, 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
Configuration requise pour Active Directory
Pour qu’un cluster de basculement AKS avec 2 nœuds physiques fonctionne de manière optimale dans un environnement Active Directory, vérifiez que les exigences suivantes sont remplies :
Remarque
Active Directory n’est pas nécessaire 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 le 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 pour gérer les stratégies de groupe pour les serveurs et les services, 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 par 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 :