Freigeben über


Systemanforderungen für AKS unter Windows Server

Gilt für: Windows Server 2022, Windows Server 2019

In diesem Artikel werden die Anforderungen für das Einrichten von Azure Kubernetes Service (AKS) unter Windows Server beschrieben. Eine Übersicht über AKS unter Windows Server finden Sie in der AKS-Übersicht.

Hardwareanforderungen

Microsoft empfiehlt, eine validierte Windows Server-Hardware- und Softwarelösung von unseren Partnern zu erwerben. Diese Lösungen sind für die Ausführung unserer Referenzarchitektur konzipiert, zusammengestellt und validiert. Sie überprüfen Kompatibilität und Zuverlässigkeit, damit Sie schnell auf dem Laufenden sind. Überprüfen Sie, ob die Systeme, Komponenten, Geräte und Treiber, die Sie verwenden, Windows Server-Zertifiziert gemäß dem Windows Server-Katalog sind.

Wichtig

Die Hostsysteme für Produktionsumgebungen müssen physische Hardware sein. Die geschachtelte Virtualisierung, die als Bereitstellung von Windows Server auf einem virtuellen Computer und die Installation von AKS auf diesem virtuellen Computer gekennzeichnet ist, wird nicht unterstützt.

Maximal unterstützte Hardwarespezifikationen

AKS für Windows Server-Bereitstellungen, die die folgenden Spezifikationen überschreiten, werden nicht unterstützt:

Ressource Höchstwert
Physische Server pro Cluster 8 (Windows Server)
Gesamtzahl der virtuellen Computer 200

Computeanforderungen

Mindestens erforderlicher Arbeitsspeicher

Richten Sie Ihren AKS-Cluster wie folgt ein, um AKS auf einem einzelnen Knoten eines Windows-Servers mit eingeschränktem RAM auszuführen:

Clustertyp Größe des virtuellen Computers auf Steuerungsebene Workerknoten Für Aktualisierungsvorgänge Lastverteiler
AKS-Host Standard_A4_v2-VM-Größe: 8 GB Nicht zutreffend – AKS-Host hat keine Workerknoten. 8 GB N/A – AKS-Host verwendet kubevip für den Lastenausgleich.
Workloadcluster Standard_A4_v2 VM-Größe = 8 GB Standard_K8S3_v1 für 1 Workerknoten = 6 GB Kann die reservierten 8 GB für das Upgrade des Workload-Clusters wiederverwenden. N/A, wenn kubevip für den Lastenausgleich verwendet wird (anstelle des standardmäßigen HAProxy-Lastenausgleichsmoduls).

Mindestanforderung: 30 GB RAM.

Diese Mindestanforderung gilt für eine AKS-Bereitstellung mit einem Arbeitsknoten für die Ausführung containerisierter Anwendungen. Wenn Sie Arbeitsknoten oder einen HAProxy-Lastenausgleich hinzufügen, ändert sich die endgültige RAM-Anforderung entsprechend.

Umwelt CPU-Kerne pro Server Arbeitsspeicher
Windows Server-Failovercluster 32 256 GB
Windows Server mit einzelnem Knoten 16 128 GB

Für eine Produktionsumgebung hängt die endgültige Größenanpassung von der Anwendung und der Anzahl der Workerknoten ab, die Sie im Windows Server-Cluster bereitstellen möchten. Wenn Sie AKS auf einem Windows Server mit einem einzigen Knoten ausführen, sind Features wie Hochverfügbarkeit nicht verfügbar, die bei der Ausführung von AKS auf einem Windows Server-Failovercluster verfügbar sind.

Auf jedem Server im Cluster muss das gleiche Betriebssystem installiert werden. In Windows Server Datacenter muss jeder Server im Cluster über das gleiche Betriebssystem und dieselbe Version verfügen. Jedes Betriebssystem muss die Regions- und Sprachauswahl "en-us " verwenden. Diese Einstellungen können nach der Installation nicht mehr geändert werden.

Speicheranforderungen

AKS unter Windows Server unterstützt die folgenden Speicherimplementierungen:

Name Speichertyp Erforderliche Kapazität
Windows Server Datacenter-Failovercluster Freigegebene Clustervolumes 1 TB (Terabyte)
Windows Server Datacenter mit einzelnem Knoten Direkt angeschlossener Speicher 500 GB

Für einen Windows Server-Cluster unterstützen zwei Speicherkonfigurationen die Ausführung virtueller Computerworkloads:

  • Hybridspeicher gleicht Leistung und Kapazität mithilfe von Flashspeicher und Festplattenlaufwerken (HDDs) aus.
  • Der gesamte Flash-Speicher maximiert die Leistung mithilfe von Solid State Drives (SSDs) oder NVMe.

Kubernetes verwendet etcd , um den Status der Cluster zu speichern. etcd speichert die Konfiguration, die Spezifikationen und den Status laufender Pods. Darüber hinaus wird der Speicher von Kubernetes für die Dienstermittlung verwendet. Als koordinierende Komponente für den Betrieb von Kubernetes und der unterstützten Workloads sind Wartezeit und Durchsatz in Richtung etcd von entscheidender Bedeutung. AKS muss auf einer SSD ausgeführt werden. Weitere Informationen finden Sie unter Performance.

Bei einem Windows Server Datacenter-basierten Cluster können Sie die Bereitstellung mit lokalem Speicher oder mit SAN-basiertem Speicher durchführen. Verwenden Sie für den lokalen Speicher das integrierte Storage Spaces Direct oder eine gleichwertige zertifizierte virtuelle SAN-Lösung, um eine hyperkonvergierte Infrastruktur zu erstellen, die Cluster Shared Volumes zur Nutzung durch Workloads bereitstellt. Für Direkte Speicherplätze muss Ihr Speicher entweder hybrid (Flash + HDD) sein, das die Leistung und Kapazität ausgleicht, oder all-Flash (SSD, NVMe), die die Leistung maximiert. Wenn Sie sich für die Bereitstellung mit SAN-basiertem Speicher entscheiden, muss Ihr SAN-Speicher genügend Leistung liefern können, um die Workloads mehrerer virtueller Computer ausführen zu können. Ältere HDD-basierte SAN-Speicher liefern möglicherweise nicht die erforderlichen Leistungsstufen, um mehrere Arbeitslasten virtueller Computer auszuführen, und Möglicherweise werden Leistungsprobleme und Timeouts angezeigt.

Verwenden Sie für Bereitstellungen mit einem knotenübergreifenden Windows Server, die lokalen Speicher verwenden, den gesamten Flashspeicher (SSD, NVMe), um die erforderliche Leistung bereitzustellen, um mehrere virtuelle Computer auf einem einzigen physischen Host zu hosten. Ohne Flashspeicher können die niedrigeren Leistungsstufen auf HDDs zu Bereitstellungsproblemen und Timeouts führen.

Netzwerkanforderungen

Die folgenden Anforderungen gelten für einen Windows Server Datacenter-Cluster.

  • Vergewissern Sie sich, dass ein vorhandener, externer virtueller Switch konfiguriert ist, falls Sie Windows Admin Center verwenden. Bei Windows Server-Clustern muss dieser Switch und sein Name für alle Clusterknoten gleich sein.
  • Vergewissern Sie sich, dass Sie IPv6 für alle Netzwerkadapter deaktiviert haben.
  • Für eine erfolgreiche Bereitstellung müssen die Windows Server-Clusterknoten und die Kubernetes-Cluster-VMs über eine externe Internetverbindung verfügen.
  • Stellen Sie sicher, dass alle Subnetze, die Sie für den Cluster definieren, zwischeneinander und in das Internet routingfähig sind.
  • Stellen Sie sicher, dass es eine Netzwerkkonnektivität zwischen Windows Server-Hosts und Mandanten-VMs gibt.
  • Die DNS-Namensauflösung ist erforderlich, damit alle Knoten miteinander kommunizieren können.
  • (Empfohlen) Aktivieren Sie dynamische DNS-Updates in Ihrer DNS-Umgebung, damit AKS den generischen Clusternamen des Cloud-Agents im DNS-System für die Ermittlung registrieren kann.

IP-Adresszuweisung

In AKS unter Windows Server weisen virtuelle Netzwerke IP-Adressen den Kubernetes-Ressourcen zu, die sie erfordern, wie zuvor aufgeführt. Wählen Sie je nach gewünschter AKS-Netzwerkarchitektur aus zwei Netzwerkmodellen aus.

Hinweis

Die hier für Ihre AKS-Bereitstellungen definierte virtuelle Netzwerkarchitektur unterscheidet sich von der zugrunde liegenden physischen Netzwerkarchitektur in Ihrem Rechenzentrum.

  • Statische IP-Netzwerke: Das virtuelle Netzwerk weist statische IP-Adressen dem Kubernetes-Cluster-API-Server, Kubernetes-Knoten, zugrunde liegenden VMs, Lastenausgleichsdiensten und allen Kubernetes-Diensten zu, die Sie über Ihrem Cluster ausführen.
  • DHCP-Netzwerk: Das virtuelle Netzwerk weist dynamische IP-Adressen den Kubernetes-Knoten, zugrunde liegenden VMs und Lastenausgleichsmodulen mithilfe eines DHCP-Servers zu. Der Kubernetes-Cluster-API-Server und alle Kubernetes-Dienste, die Sie über Ihrem Cluster ausführen, erhalten weiterhin statische IP-Adressen.

Minimale IP-Adressreservierung

Reservieren Sie mindestens die folgende Anzahl von IP-Adressen für Ihre Bereitstellung:

Clustertyp Knoten der Steuerungsebene Workerknoten Für Aktualisierungsvorgänge Lastverteiler
AKS-Host 1 IP-Adresse N/A 2 IP-Adressen N/A
Workloadcluster 1 IP-Adresse pro Knoten 1 IP-Adresse pro Knoten 5 IP-Adressen 1 IP-Adresse

Reservieren Sie außerdem die folgende Anzahl von IP-Adressen für Ihren VIP-Pool:

Ressourcentyp Anzahl von IP-Adressen
Cluster-API-Server 1 pro Cluster
Kubernetes-Dienste 1 pro Dienst

Wie Sie sehen können, variiert die Anzahl der erforderlichen IP-Adressen je nach AKS-Architektur und der Anzahl der Dienste, die Sie auf Ihrem Kubernetes-Cluster ausführen. Reservieren Sie insgesamt 256 IP-Adressen (/24 Subnetz) für Ihre Bereitstellung.

Weitere Informationen zu Netzwerkanforderungen finden Sie unter Knotennetzwerkkonzepte in AKS und Containernetzwerkkonzepten in AKS.

Anforderungen an Netzwerkport und URL

AKS für Windows Server-Anforderungen

Wenn Sie einen Kubernetes-Cluster erstellen, öffnet der Prozess automatisch die folgenden Firewallports auf jedem Server im Cluster.

Wenn sich die physischen Clusterknoten und die Azure Kubernetes-Cluster-VMs auf zwei isolierten VLANs befinden, müssen Sie diese Ports in der Firewall zwischen ihnen öffnen:

Hafen Quelle Beschreibung Hinweise zur Firewall
22 AKS-VMs Erforderlich zum Sammeln von Protokollen bei Verwendung Get-AksHciLogs. Wenn Sie separate VLANs verwenden, müssen die physischen Hyper-V-Hosts auf die AKS-VMs auf diesem Port zugreifen.
6443 AKS-VMs Erforderlich für die Kommunikation mit Kubernetes-APIs. Wenn Sie separate VLANs verwenden, müssen die physischen Hyper-V-Hosts auf die AKS-VMs auf diesem Port zugreifen.
45000 Physische Hyper-V-Hosts wssdAgent gRPC-Server. Es sind keine VLAN-übergreifenden Regeln erforderlich.
45001 Physische Hyper-V-Hosts wssdAgent gRPC-Authentifizierung. Es sind keine VLAN-übergreifenden Regeln erforderlich.
46000 AKS-VMs wssdCloudAgent wird zu lbagent. Wenn Sie separate VLANs verwenden, müssen die physischen Hyper-V-Hosts auf die AKS-VMs auf diesem Port zugreifen.
55000 Clusterressource (-CloudServiceCIDR) Cloud Agent gRPC-Server Wenn Sie separate VLANs verwenden, müssen die AKS-VMs auf die IP-Adresse der Clusterressource auf diesem Port zugreifen.
65000 Clusterressource (-CloudServiceCIDR) Cloud Agent gRPC-Authentifizierung. Wenn Sie separate VLANs verwenden, müssen die AKS-VMs auf die IP-Adresse der Clusterressource auf diesem Port zugreifen.

Wenn Ihr Netzwerk die Verwendung eines Proxyservers für die Verbindung mit dem Internet erfordert, finden Sie weitere Informationen unter Verwenden der Proxyservereinstellungen auf AKS.

Fügen Sie ihrer Zulassungsliste die folgenden URLs hinzu:

URL Hafen Hinweise
msk8s.api.cdp.microsoft.com 443 Wird beim Herunterladen des AKS auf Windows Server-Produktkatalogs, der Produktbits und der Betriebssystembilder von SFS verwendet. Tritt auf, wenn Set-AksHciConfig ausgeführt wird, und jedes Mal, wenn Sie etwas von SFS herunterladen.

msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com
80 Wird beim Herunterladen des AKS auf Windows Server-Produktkatalogs, der Produktbits und der Betriebssystembilder von SFS verwendet. Tritt auf, wenn Set-AksHciConfig ausgeführt wird, und jedes Mal, wenn Sie etwas von SFS herunterladen.

login.microsoftonline.com
login.windows.net
management.azure.com
msft.sts.microsoft.com graph.windows.net
443 Wird für die Anmeldung bei Azure verwendet, wenn ausgeführt Set-AksHciRegistration wird.

ecpacr.azurecr.io mcr.microsoft.com
*.mcr.microsoft.com
*.data.mcr.microsoft.com
*.blob.core.windows.net
US-Endpunkt: wus2replica*.blob.core.windows.net
443 Erforderlich, um Containerbilder zu ziehen, wenn Install-AksHci ausgeführt wird.
<region.dp.kubernetesconfiguration.azure.com> 443 Erforderlich für das Onboarding von AKS auf Windows Server-Clustern in Azure Arc.
gbl.his.arc.azure.com 443 Erforderlich, um den regionalen Endpunkt zum Abrufen von Zertifikaten systemseitig zugewiesener verwalteter Identitäten per Pull zu erhalten.
*.his.arc.azure.com 443 Erforderlich zum Pullen vom System zugewiesener Zertifikate für verwaltete Identitäten.
k8connecthelm.download.prss.microsoft.com 443 Arc-fähige Kubernetes verwendet Helm 3, um Azure Arc-Agenten auf dem AKS auf dem Windows Server-Verwaltungscluster bereitzustellen. Dieser Endpunkt wird für den Helm-Client-Download benötigt, um die Bereitstellung des Agenten-Helm-Diagramms zu erleichtern.
*.arc.azure.net 443 Erforderlich zum Verwalten von AKS Arc-Clustern im Azure-Portal.
dl.k8s.io 443 Erforderlich zum Herunterladen und Aktualisieren von Kubernetes-Binärdateien für Azure Arc.
akshci.azurefd.net 443 Erforderlich für AKS auf Windows Server-Abrechnung, wenn Install-AksHciausgeführt wird.

v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net
443 Wird verwendet, um microsoft erforderliche Diagnosedaten regelmäßig vom Windows Server-Host zu senden.

Hinweis

AKS unter Windows Server speichert und verarbeitet Kundendaten. Standardmäßig verbleiben Kundendaten innerhalb der Region, in der Sie die Dienstinstanz bereitstellen. Diese Daten werden in regionalen von Microsoft betriebenen Rechenzentren gespeichert. Für Regionen mit Datenhaltungsanforderungen werden Kundendaten immer innerhalb derselben Region aufbewahrt.

Zusätzliche URL-Anforderungen für Azure Arc-Features

In der vorherigen URL-Liste werden die mindestens erforderlichen URLs behandelt, die Sie für die Verbindung Ihres AKS-Diensts mit Azure für die Abrechnung herstellen können. Sie müssen zusätzliche URLs zulassen, wenn Sie Clusterverbindungen, benutzerdefinierte Speicherorte, Azure RBAC und andere Azure-Dienste wie Azure Monitor usw. auf Ihrem AKS-Workloadcluster verwenden möchten. Eine vollständige Liste der Arc-URLs finden Sie unter Azure Arc-fähige Kubernetes-Netzwerkanforderungen.

Stretched Cluster in AKS

Wie in der Übersicht über gestreckte Cluster beschrieben, wird die Bereitstellung von AKS auf Windows Server mit gestreckten Windows-Clustern nicht unterstützt. Es wird empfohlen, einen Sicherungs- und Notfallwiederherstellungsansatz für die Betriebskontinuität Ihres Rechenzentrums zu verwenden. Weitere Informationen finden Sie unter Ausführen der Workloadclustersicherung oder -wiederherstellung mithilfe von Velero und Azure Blob Storage unter Windows Server und Bereitstellen von Konfigurationen auf AksHci mithilfe von GitOps mit Flux v2 für die Anwendungskontinuität.

Anforderungen für Windows Admin Center

Windows Admin Center ist die Benutzeroberfläche zum Erstellen und Verwalten von AKS auf Windows Server. Um Windows Admin Center mit AKS unter Windows Server zu verwenden, müssen Sie alle Kriterien in der folgenden Liste erfüllen.

Diese Anforderungen gelten für den Computer, auf dem das Windows Admin Center-Gateway ausgeführt wird:

  • Windows 10 oder Windows Server.
  • Registriert bei Azure.
  • In derselben Domäne wie der Windows Server Datacenter-Cluster.
  • Ein Azure-Abonnement, für das Sie über Besitzerrechte verfügen. Sie können Ihre Zugriffsebene überprüfen, indem Sie zu Ihrem Abonnement navigieren und access control (IAM) auf der linken Seite der Azure-Portal auswählen und dann "Meinen Zugriff anzeigen" auswählen.

Anforderungen für Azure

Sie müssen eine Verbindung mit Ihrem Azure-Konto herstellen.

Azure-Konto und -Abonnement

Wenn Sie noch kein Azure-Konto besitzen, erstellen Sie eins. Sie können ein vorhandenes Abonnement beliebigen Typs verwenden:

  • Kostenloses Konto mit Azure-Gutschriften für Studierende oder Visual Studio-Abonnenten.
  • Abonnement mit nutzungsbasierter Bezahlung per Kreditkarte.
  • Durch einen Konzernvertrag (Enterprise Agreement, EA) erworbenes Abonnement.
  • Durch das CSP-Programm (Cloud Solution Provider, Cloudlösungsanbieter) erworbenes Abonnement.

Microsoft Entra-Berechtigungen, Rollen und Zugriffsebene

Sie müssen über ausreichende Berechtigungen verfügen, um eine Anwendung bei Ihrem Microsoft Entra-Mandanten registrieren zu können.

Um zu überprüfen, ob Sie über ausreichende Berechtigungen verfügen, folgen Sie den Informationen im folgenden Abschnitt:

  • Wechseln Sie zum Azure-Portal, und wählen Sie "Rollen und Administratoren" unter der Microsoft Entra-ID aus, um Ihre Rolle zu überprüfen.
  • Wenn Ihre Rolle "Benutzer" ist, stellen Sie sicher, dass Nichtadministratoren Anwendungen registrieren können.
  • Um zu überprüfen, ob Sie Anwendungen registrieren können, wechseln Sie unter dem Microsoft Entra-Dienst zu "Benutzereinstellungen ", um zu überprüfen, ob Sie über die Berechtigung zum Registrieren einer Anwendung verfügen.

Wenn die Einstellung für die App-Registrierung auf "Nein" festgelegt ist, können nur Benutzer mit einer Administratorrolle diese Arten von Anwendungen registrieren. Informationen zu den verfügbaren Administratorrollen und den spezifischen Berechtigungen in der Microsoft Entra-ID, die jeder Rolle zugewiesen werden, finden Sie in den integrierten Microsoft Entra-Rollen. Falls Ihrem Konto die Rolle Benutzer zugewiesen ist, die App-Registrierungseinstellung jedoch auf Administratorbenutzer beschränkt ist, bitten Sie Ihren Administrator, Ihnen entweder eine Administratorrolle zuzuweisen, mit der App-Registrierungen erstellt und sämtliche Aspekte von App-Registrierungen verwaltet werden können, oder Benutzern das Registrieren von Apps zu ermöglichen.

Wenn Sie nicht über ausreichende Berechtigungen zum Registrieren einer Anwendung verfügen und Ihr Administrator Ihnen diese Berechtigungen nicht erteilen kann, besteht die einfachste Möglichkeit zum Bereitstellen von AKS darin, Ihren Azure-Administrator aufzufordern, einen Dienstprinzipal mit den richtigen Berechtigungen zu erstellen. Im nächsten Abschnitt erfahren Administratoren, wie sie einen Dienstprinzipal erstellen.

Azure-Abonnementrolle und Zugriffsebene

Navigieren Sie zum Überprüfen Ihrer Zugriffsebene zu Ihrem Abonnement, wählen Sie auf der linken Seite des Azure-Portals die Option Zugriffssteuerung (IAM) aus, und wählen Sie anschließend Meinen Zugriff anzeigen aus.

  • Wenn Sie Windows Admin Center zum Bereitstellen eines AKS-Hosts oder eines AKS-Workloadclusters verwenden, müssen Sie über ein Azure-Abonnement verfügen, für das Sie ein Besitzer sind.
  • Wenn Sie PowerShell zum Bereitstellen eines AKS-Hosts oder eines AKS-Workloadclusters verwenden, muss der Benutzer, der den Cluster registriert, mindestens über einen der folgenden Komponenten verfügen:
    • Ein Benutzerkonto mit der integrierten Rolle Besitzer.
    • Ein Dienstprinzipal mit einer der folgenden Zugriffsebenen:

Wenn Ihr Azure-Abonnement über einen EA oder CSP verfügt, besteht die einfachste Möglichkeit zum Bereitstellen von AKS darin, Ihren Azure-Administrator aufzufordern, einen Dienstprinzipal mit den richtigen Berechtigungen zu erstellen. Administratoren können im folgenden Abschnitt nachlesen, wie man einen Dienstprinzipal erstellt.

Optional: Erstellen Sie einen neuen Dienstprinzipal

Führen Sie die folgenden Schritte aus, um einen neuen Dienstprinzipal mit der integrierten Rolle Besitzer zu erstellen. Dienstprinzipale mit der richtigen Rollenzuweisung können nur von Abonnementbesitzern erstellt werden. Sie können Ihre Zugriffsebene überprüfen, indem Sie zu Ihrem Abonnement navigieren, auf der linken Seite der Azure-Portal die Zugriffssteuerung (ACCESS Control, IAM) auswählen und dann auf "Meinen Zugriff anzeigen" auswählen.

Legen Sie die folgenden PowerShell-Variablen in einem PowerShell-Administratorfenster fest. Vergewissern Sie sich, dass das Abonnement und der Mandant mit denen übereinstimmen, die Sie für die Registrierung Ihres AKS-Hosts für die Rechnungsstellung verwenden möchten:

$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"

Installieren und Importieren des AKS PowerShell-Moduls:

Install-Module -Name AksHci

Melden Sie sich bei Azure mithilfe des PowerShell-Befehls Connect-AzAccount an:

Connect-AzAccount -tenant $tenantID

Legen Sie das Abonnement fest, mit dem Sie Ihren AKS-Host für die Abrechnung als Standardabonnement registrieren möchten, indem Sie den Befehl "Set-AzContext " ausführen:

Set-AzContext -Subscription $subscriptionID

Vergewissern Sie sich durch Ausführen des PowerShell-Befehls Get-AzContext, dass Ihr Anmeldekontext korrekt ist. Vergewissern Sie sich, dass das Abonnement, der Mandant und das Konto die gewünschten für die Abrechnung mit Ihrem AKS-Host sind.

Get-AzContext
Name                                     Account                      SubscriptionName             Environment                  TenantId
----                                     -------                      ----------------             -----------                  --------
myAzureSubscription (92391anf-...        user@contoso.com             myAzureSubscription          AzureCloud                   xxxxxx-xxxx-xxxx-xxxxxx

Erstellen Sie einen Dienstprinzipal, indem Sie den PowerShell-Befehl New-AzADServicePrincipal ausführen. Dieser Befehl erstellt einen Dienstprinzipal mit der Rolle Besitzer und setzt den Geltungsbereich auf eine Abonnementebene. Weitere Informationen zum Erstellen von Dienstprinzipalen finden Sie unter Erstellen eines Azure-Dienstprinzipals mit Azure PowerShell.

$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID

Rufen Sie das Kennwort für den Dienstprinzipal ab, indem Sie den folgenden Befehl ausführen. Beachten Sie, dass dieser Befehl nur für Az.Accounts 2.6.0 oder früher funktioniert. Das AksHci PowerShell-Modul lädt das Az.Accounts 2.6.0-Modul automatisch herunter, wenn Sie es installieren:

$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"

Aus der vorherigen Ausgabe haben Sie nun die Anwendungs-ID und den geheimen Schlüssel beim Bereitstellen von AKS zur Verfügung. Notieren Sie sich diese Elemente, und speichern Sie sie sicher. Nachdem das erstellt wurde, sollten im Azure-Portal unter Abonnements, Zugriffssteuerung und dann Rollenzuweisungen Ihr neuer Dienstprinzipal angezeigt werden.

Azure-Ressourcengruppe

Sie müssen vor der Registrierung eine Azure-Ressourcengruppe in der Azure-Region „Australien, Osten“, „USA, Osten“, „Asien, Südosten“ oder „Europa, Westen“ zur Verfügung stellen.

Azure-Regionen

Warnung

AKS Arc unterstützt derzeit die Clustererstellung ausschließlich innerhalb der folgenden angegebenen Azure-Regionen. Wenn Sie versuchen, in einer Region außerhalb dieser Liste bereitzustellen, tritt ein Bereitstellungsfehler auf.

Der AKS Arc-Dienst wird für Registrierung, Abrechnung und Verwaltung verwendet. Es unterstützt derzeit die folgenden Regionen:

  • Ost-USA
  • USA Süd Mitte
  • Europa, Westen

Active Directory-Anforderungen

Damit ein AKS-Failovercluster mit zwei oder mehr physischen Knoten optimal in einer Active Directory-Umgebung funktioniert, stellen Sie sicher, dass die folgenden Anforderungen erfüllt sind:

Hinweis

Active Directory ist für Windows Server-Bereitstellungen mit nur einem Knoten nicht erforderlich.

  • Richten Sie die Zeitsynchronisierung so ein, dass die Divergenz nicht mehr als zwei Minuten über alle Clusterknoten und den Domänencontroller hinweg beträgt. Informationen zum Festlegen der Zeitsynchronisierung finden Sie unter Windows-Zeitdienst.
  • Stellen Sie sicher, dass die Benutzerkonten, die Sie zum Hinzufügen, Aktualisieren und Verwalten von AKS oder Windows Server Datacenter-Clustern verwenden, über die richtigen Berechtigungen in Active Directory verfügen. Wenn Sie Organisationseinheiten (Organisationseinheiten, OUs) zum Verwalten von Gruppenrichtlinien für Server und Dienste verwenden, benötigen die Benutzerkonten Listen-, Lese-, Änderungs- und Löschberechtigungen für alle Objekte in der OE.
  • Verwenden Sie eine separate Organisationseinheit (OU) für die Server und Dienste von Ihren AKS- oder Windows Server Datacenter-Clustern. Durch die Verwendung einer gesonderten Organisationseinheit können Sie den Zugriff und die Berechtigungen differenzierter steuern.
  • Wenn Sie GPO-Vorlagen für Container in Active Directory verwenden, stellen Sie sicher, dass die Bereitstellung von AKS unter Windows Server von der Richtlinie ausgenommen ist.

Nächste Schritte

Nachdem Sie alle diese Voraussetzungen erfüllt haben, können Sie einen AKS-Host einrichten: