Configuration requise pour AKS activé par Azure Arc sur Azure Local 22H2
S’applique à : Azure Local, 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 Local 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 Local pour voir les solutions validées.
Important
Les systèmes hôtes pour les déploiements de production doivent être matériels physiques. La virtualisation imbriquée, qui consiste à déployer Azure Local ou Windows Server dans une machine virtuelle et à installer 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 Local et Windows Server qui dépassent les spécifications suivantes ne sont pas pris en charge :
| Ressource | Maximum |
|---|---|
| Serveurs physiques par cluster | 8 (Azure Local 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 Local | 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 Local ou Windows Server. Si vous choisissez d’exécuter AKS sur un serveur Windows à nœud unique, vous ne bénéficiez pas de fonctionnalités telles que la haute disponibilité, qui sont offertes par l’exécution d’AKS sur un cluster Azure Local ou Windows Server, ou encore sur un cluster de basculement Windows Server.
Les autres exigences de calcul pour AKS sur Azure Local et Windows Server sont conformes aux exigences d’Azure Local. Consultez configuration système requise pour Azure Local pour plus d'informations sur le serveur Azure Local.
Vous devez installer le même système d’exploitation sur chaque serveur du cluster. Si vous utilisez Azure Local, le même système d’exploitation et la même version doivent être présents 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 Local et Windows Server prend en charge les implémentations de stockage suivantes :
| Nom | Type de stockage | Capacité requise |
|---|---|---|
| Cluster Azure local | 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 Local ou Windows Server, deux configurations de stockage sont prises en charge pour l’exécution des charges de travail des machines virtuelles :
- 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 disposent uniquement d’un stockage HDD ne sont pas pris en charge par Azure Local et ne sont donc pas recommandés pour l’exécution d’AKS sur Azure Local et Windows Server. Pour plus d’informations sur les configurations de lecteur recommandées, consultez la documentation Azure Local. Tous les systèmes validés dans le catalogue local Azure 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 exigences suivantes s’appliquent à un cluster Azure Local 22H2 et à un cluster Windows Server Datacenter. Pour connaître les exigences de mise en réseau sur Azure Local 23H2, consultez les Exigences réseau.
- Pour Azure Local 22H2 et Windows Server, vérifiez qu’un commutateur virtuel externe existant est configuré si vous utilisez Windows Admin Center. Pour des clusters Azure Local ou Windows Server, ce commutateur et son nom doivent être identiques sur tous les nœuds de cluster. Pour Azure Local 23H2, consultez les exigences du système 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 Local ou Windows Server et les machines virtuelles de 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 existe une connectivité réseau entre les hôtes Azure Local 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 Local, les ports de pare-feu suivants sont automatiquement ouverts sur chaque serveur du cluster.
Si les nœuds de cluster physique local Azure et les machines virtuelles de cluster Azure Kubernetes se trouvent sur deux réseaux locaux virtuels isolés, ces ports doivent être ouverts au niveau du pare-feu qui les sépare :
| 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 passer en revue les URL Azure Local. Dans la mesure où Arc pour les agents serveur est maintenant installé par défaut sur les nœuds Azure Local à partir d’Azure Local 21H2 et les versions ultérieures, vous devez également revoir les URL Arc pour les agents serveur.
Clusters étendus dans AKS
Comme indiqué dans la Vue d’ensemble des clusters étendus, le déploiement d’AKS sur Azure Local 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 Local 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 Local 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 Local 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 Local 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 de stratégie de groupe sur des conteneurs dans Active Directory, vérifiez que le déploiement d'AKS sur Azure Local ainsi que sur Windows Server est exclu de la politique.
Étapes suivantes
Une fois que vous avez satisfait à toutes les conditions préalables ci-dessus, vous pouvez configurer un hôte AKS sur Azure Local à l’aide de :