Systemanforderungen für AKS, die von Azure Arc auf Azure Stack HCI 22H2 aktiviert sind
Gilt für: Azure Stack HCI, Version 22H2; Windows Server 2022, Windows Server 2019
In diesem Artikel werden die Anforderungen für das Einrichten von Azure Kubernetes Service (AKS) beschrieben, die von Azure Arc aktiviert sind. Eine Übersicht über die von Arc aktivierten AKS finden Sie in der AKS-Übersicht.
Hardwareanforderungen
Microsoft empfiehlt den Erwerb einer validierten Azure Stack HCI-Hardware-/Softwarelösung von unseren Partnern. Diese Lösungen wurden für die Ausführung unserer Referenzarchitektur entworfen, zusammengestellt und überprüft und ermöglichen die Überprüfung der Kompatibilität und Zuverlässigkeit, sodass Sie sofort loslegen können. Überprüfen Sie, ob die von Ihnen verwendeten Systeme, Komponenten, Geräte und Treiber gemäß Windows Server Catalog für Windows Server zertifiziert sind. Auf der Website der Azure Stack HCI-Lösungen finden Sie überprüfte Lösungen.
Wichtig
Die Hostsysteme für Produktionsbereitstellungen müssen physische Hardware sein. Geschachtelte Virtualisierung, die als Bereitstellung von Azure Stack HCI oder 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-Bereitstellungen in Azure Stack HCI und Windows Server, die die folgenden Spezifikationen überschreiten, werden nicht unterstützt:
| Resource | Maximum |
|---|---|
| Physische Server pro Cluster | 8 (Azure Stack HCI Version 22H2 und Windows Server) |
| Gesamtzahl der virtuellen Computer | 200 |
Computeanforderungen
Mindestens erforderlicher Arbeitsspeicher
Sie können Ihren AKS-Cluster wie folgt einrichten, um AKS auf einem einzelnen Knoten mit eingeschränktem RAM auszuführen:
| Clustertyp | Größe des virtuellen Computers auf Steuerungsebene | Workerknoten | Für Aktualisierungsvorgänge | Load Balancer |
|---|---|---|---|---|
| AKS-Host | Standard_A4_v2-VM-Größe: 8 GB | N/A – AKS-Host verfügt nicht über Arbeitsknoten. | 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 einen einzelnen Workerknoten: 6 GB | Kann diese reservierte 8 GB für das Workloadclusterupgrade 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 möchten, ändert sich die endgültige RAM-Anforderung entsprechend.
Empfohlene Computeanforderungen
| Environment | CPU-Kerne pro Server | RAM |
|---|---|---|
| Azure Stack HCI | 32 | 256 GB |
| 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 anzahl der Workerknoten ab, die Sie für die Bereitstellung auf dem Azure Stack HCI- oder Windows Server-Cluster planen. Wenn Sie AKS auf einem Einzelknoten-Windows Server ausführen möchten, erhalten Sie keine Features wie hohe Verfügbarkeit, die im Lieferumfang von AKS auf einem Azure Stack HCI- oder Windows Server-Cluster oder Windows Server-Failovercluster enthalten sind.
Andere Computeanforderungen für AKS auf Azure Stack HCI und Windows Server entsprechen den Azure Stack HCI-Anforderungen. Weitere Informationen zu Azure Stack HCI-Serveranforderungen finden Sie unter azure Stack HCI-Systemanforderungen .
Auf jedem Server im Cluster muss das gleiche Betriebssystem installiert werden. Wenn Sie Azure Stack HCI verwenden, muss sich dasselbe Betriebssystem und die gleiche Version auf jedem Server im Cluster befinden. Wenn Sie Windows Server Datacenter verwenden, muss dasselbe Betriebssystem und die gleiche Version auf jedem Server im Cluster sein. Jedes Betriebssystem muss die Regions- und Sprachauswahl "en-us " verwenden. Diese Einstellungen können nach der Installation nicht mehr geändert werden.
Speicheranforderungen
AKS auf Azure Stack HCI und Windows Server unterstützt die folgenden Speicherimplementierungen:
| Name | Speichertyp | Erforderliche Kapazität |
|---|---|---|
| Azure Stack HCI-Cluster | Freigegebene Clustervolumes | 1 TB |
| Windows Server Datacenter-Failovercluster | Freigegebene Clustervolumes | 1 TB |
| Windows Server Datacenter mit einzelnem Knoten | Direkt angeschlossener Speicher | 500 GB |
Für einen Azure Stack HCI- oder Windows Server-Cluster gibt es zwei unterstützte Speicherkonfigurationen für die Ausführung virtueller Computerworkloads:
- Hybridspeicher bietet durch Flashspeicher und Festplattenlaufwerke (Hard Disk Drives, HDDs) ein ausgewogenes Verhältnis zwischen Leistung und Kapazität.
- All-Flash-Speicher maximiert die Leistung durch die Verwendung von SSD-Datenträgern (Solid State Drives) oder NVMe.
Systeme, die nur über HDD-basierten Speicher verfügen, werden von Azure Stack HCI nicht unterstützt und werden daher für die Ausführung von AKS in Azure Stack HCI und Windows Server nicht empfohlen. Weitere Informationen zu den empfohlenen Laufwerkkonfigurationen finden Sie in der Azure Stack HCI-Dokumentation. Alle Systeme, die im Azure Stack HCI-Katalog überprüft werden, sind in eine dieser beiden unterstützten Speicherkonfigurationen unterteilt.
Kubernetes verwendet etcd , um den Status der Cluster zu speichern. etcd speichert die Konfiguration, die Spezifikationen und den Status ausgeführter 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 etcd.io.
Bei einem Windows Server Datacenter-basierten Cluster können Sie die Bereitstellung mit lokalem Speicher oder mit SAN-basiertem Speicher durchführen. Für den lokalen Speicher wird empfohlen, die integrierte Speicherplätze Direct oder eine entsprechende zertifizierte virtuelle SAN-Lösung zu verwenden, um eine hyperkonvergierte Infrastruktur zu erstellen, die freigegebene Clustervolumes für die Verwendung durch Workloads darstellt. Für direkte Speicherplätze muss Ihr Speicher entweder Hybridspeicher (Flash und HDD), der Leistung und Kapazität ausgleicht, oder All-Flash-Speicher (SSD, NVMe) sein, der 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.
Für Windows Server-Bereitstellungen mit einem einzelnen Knoten und lokalem Speicher wird dringend die Verwendung von All-Flash-Speicher (SSD, NVMe) empfohlen, um die erforderliche Leistung zum Hosten mehrerer virtueller Computer auf einem einzelnen physischen Host bereitzustellen. Ohne Flashspeicher können die niedrigeren Leistungsstufen auf HDDs zu Bereitstellungsproblemen und Timeouts führen.
Netzwerkanforderungen
Die folgenden Anforderungen gelten für einen Azure Stack HCI 22H2-Cluster und einen Windows Server Datacenter-Cluster. Netzwerkanforderungen für Azure Stack HCI 23H2 finden Sie unter Netzwerkanforderungen.
- Stellen Sie für Azure Stack HCI 22H2 und Windows Server sicher, dass Sie über einen vorhandenen, externen virtuellen Switch verfügen, der bei Verwendung von Windows Admin Center konfiguriert ist. Bei HCI- oder Windows Server-Clustern muss dieser Switch und sein Name für alle Clusterknoten identisch sein. Informationen zu HCI 23H2 finden Sie in den Netzwerksystemanforderungen.
- Vergewissern Sie sich, dass Sie IPv6 auf allen Netzwerkadaptern deaktiviert haben.
- Für eine erfolgreiche Bereitstellung müssen die Azure Stack HCI- oder Windows Server-Clusterknoten und die Kubernetes-Cluster-VMs über externe Internetkonnektivität 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 Netzwerkkonnektivität zwischen Azure Stack HCI-Hosts und den Mandanten-VMs sicher.
- 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, die von Arc aktiviert sind, werden virtuelle Netzwerke verwendet, um IP-Adressen den Kubernetes-Ressourcen zuzuordnen, die sie erfordern, wie zuvor aufgeführt. Je nach gewünschter AKS-Netzwerkarchitektur gibt es zwei Netzwerkmodelle.
Hinweis
Die hier für Ihre AKS-Bereitstellungen definierte virtuelle Netzwerkarchitektur unterscheidet sich von der zugrunde liegenden physischen Netzwerkarchitektur in Ihrem Rechenzentrum.
- Statisches IP-Netzwerk: Das virtuelle Netzwerk weist statische IP-Adressen dem Kubernetes-Cluster-API-Server, Kubernetes-Knoten, zugrunde liegenden VMs, Lastenausgleichsmodulen 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 mit einem DHCP-Server zu. Dem API-Server des Kubernetes-Clusters und allen Kubernetes-Diensten, die Sie auf der Grundlage Ihres Clusters ausführen, werden immer noch statische IP-Adressen zugeordnet.
Mindestens zu reservierende IP-Adressen
Sie sollten mindestens die folgende Anzahl von IP-Adressen für Ihre Bereitstellung reservieren:
| Clustertyp | Knoten der Steuerungsebene | Workerknoten | Für Aktualisierungsvorgänge | Load Balancer |
|---|---|---|---|---|
| AKS-Host | 1 IP-Adresse | Nicht verfügbar | 2 IP-Adressen | Nicht verfügbar |
| Workloadcluster | 1 IP-Adresse pro Knoten | 1 IP-Adresse pro Knoten | 5 IP-Adressen | 1 IP-Adresse |
Zusätzlich sollten Sie die folgende Anzahl von IP-Adressen für Ihren VIP-Pool reservieren:
| Ressourcentyp | Anzahl von IP-Adressen |
|---|---|
| Cluster-API-Server | 1 pro Cluster |
| Kubernetes-Dienste | 1 pro Dienst |
Wie Sie sehen können, ist die Anzahl der erforderlichen IP-Adressen abhängig von der AKS-Architektur und der Anzahl der Dienste, die Sie auf Ihrem Kubernetes-Cluster ausführen, variabel. Es wird empfohlen, für Ihre Bereitstellung insgesamt 256 IP-Adressen (/24-Subnetz) zu reservieren.
Weitere Informationen zu Netzwerkanforderungen finden Sie unter Knotennetzwerkkonzepte in AKS und Containernetzwerkkonzepten in AKS.
Anforderungen an Netzwerkport und URL
Von Arc-Anforderungen aktivierte AKS
Beim Erstellen eines Kubernetes-Clusters auf Azure Stack HCI werden die folgenden Firewallports automatisch auf jedem Server im Cluster geöffnet.
Wenn sich die physischen Azure Stack HCI-Clusterknoten und die Azure Kubernetes-Cluster-VMs auf zwei isolierten Vlans befinden, müssen diese Ports an der Firewall geöffnet werden:
| Port | 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 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 zum Herstellen einer Internetverbindung erfordert, lesen Sie die Verwendung der Proxyservereinstellungen auf AKS.
Die folgenden URLs müssen Ihrer Zulassungsliste hinzugefügt werden:
| URL | Port | Hinweise |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Wird beim Herunterladen der AKS im lokalen Azure-Produktkatalog, Produktbits und Betriebssystemimages von SFS verwendet. Tritt auf, wenn Sie ausgeführt Set-AksHciConfig werden, und jedes Mal, wenn Sie von SFS heruntergeladen werden. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Wird beim Herunterladen der AKS im lokalen Azure-Produktkatalog, Produktbits und Betriebssystemimages von SFS verwendet. Tritt auf, wenn Sie ausgeführt Set-AksHciConfig werden, und jedes Mal, wenn Sie von SFS heruntergeladen werden. |
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 zum Pullen von Containerimages, wenn Install-AksHci ausgeführt wird. |
| <region.dp.kubernetesconfiguration.azure.com> | 443 | Erforderlich für das Onboarding von AKS-Hybridclustern 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.azureedge.net | 443 | Arc-fähige Kubernetes verwendet Helm 3 zum Bereitstellen von Azure Arc-Agents auf dem AKS im lokalen Azure-Verwaltungscluster. Dieser Endpunkt wird für den Helm-Clientdownload benötigt, um die Bereitstellung des Agent-Helmdiagramms zu erleichtern. |
| *.arc.azure.net | 443 | Erforderlich zum Verwalten von AKS-Hybridclustern in 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 bei der lokalen Azure-Abrechnung beim Ausführen Install-AksHci. |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Wird in regelmäßigen Abständen verwendet, um microsoft erforderliche Diagnosedaten vom lokalen Azure- oder Windows Server-Host zu senden. |
Hinweis
Von Arc aktivierte AKS speichert und verarbeitet Kundendaten. Standardmäßig verbleiben Kundendaten innerhalb der Region, in der der Kunde die Dienstinstanz bereitstellt. 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.
Sie sollten auch Azure Stack HCI-URLs überprüfen. Da Arc für Server-Agents jetzt standardmäßig auf Azure Stack HCI-Knoten aus Azure Stack HCI 21H2 und höher installiert ist, sollten Sie auch den Arc für Server-Agents-URLs überprüfen.
Gestreckte Cluster in AKS
Wie in der Übersicht über gestreckte Cluster beschrieben, wird die Bereitstellung von AKS auf Azure Stack HCI und 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 mit Velero und Azure Blob Storage auf Azure Stack HCI und 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, die von Azure Arc aktiviert sind. Um Windows Admin Center mit AKS auf Azure Stack HCI und Windows Server zu verwenden, müssen Sie alle Kriterien in der folgenden Liste erfüllen.
Dies sind die Anforderungen 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 Azure Stack HCI- oder 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.
So überprüfen Sie, ob Sie über ausreichende Berechtigungen verfügen:
- Wechseln Sie zum Azure-Portal, und wählen Sie "Rollen und Administratoren" unter der Microsoft Entra-ID aus, um Ihre Rolle zu überprüfen.
- Lautet Ihre Rolle Benutzer, müssen Sie sich vergewissern, dass zum Registrieren von Anwendungen keine Administratorrechte benötigt werden.
- 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:
- Die integrierte Rolle "Mitwirkender" .
- Die integrierte Besitzerrolle .
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 den folgenden Abschnitt zum Erstellen eines Dienstprinzipals überprüfen.
Optional: Erstellen eines neuen Dienstprinzipals
Führen Sie die folgenden Schritte aus, um einen neuen Dienstprinzipal mit der integrierten Besitzerrolle 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. Stellen Sie sicher, dass das Abonnement und der Mandant ihre AKS-Host für die Abrechnung registrieren 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. Stellen Sie sicher, dass das Abonnement, der Mandant und das Konto das sind, was Sie zum Registrieren Ihres AKS-Hosts für die Abrechnung verwenden möchten:
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. Mit diesem Befehl wird ein Dienstprinzipal mit der Rolle "Besitzer " erstellt und der Bereich auf Abonnementebene festgelegt. 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 darunter funktioniert. Das Az.Accounts 2.6.0-Modul wird automatisch heruntergeladen, wenn Sie das AksHci PowerShell-Modul 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. Sie sollten diese Elemente notieren und sicher speichern. Nachdem sie in der Azure-Portal unter "Abonnements", "Zugriffssteuerung" und dann "Rollenzuweisungen" erstellt wurde, sollte der neue 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. Sie wird derzeit in den folgenden Regionen unterstützt:
- East US
- USA Süd Mitte
- Europa, Westen
Active Directory-Anforderungen
Damit ein AKS-Failovercluster mit 2 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 Azure Stack HCI- oder Windows Server-Bereitstellungen mit nur einem Knoten nicht erforderlich.
- Richten Sie die Zeitsynchronisierung so ein, dass die Abweichung zwischen allen Clusterknoten und dem Domänencontroller nicht mehr als zwei Minuten beträgt. Informationen zum Festlegen der Zeitsynchronisierung finden Sie unter Windows-Zeitdienst.
- Stellen Sie sicher, dass die Zum Hinzufügen von Updates verwendeten Benutzerkonten und die Verwaltung von AKS oder Windows Server Datacenter-Clustern ü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 Eine Liste, 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 in Azure Stack HCI und Windows Server von der Richtlinie ausgenommen ist.
Nächste Schritte
Sind alle oben genannten Voraussetzungen erfüllt, können Sie Folgendes verwenden, um einen AKS-Host in Azure Stack HCI einzurichten: