Systemanforderungen für AKS, die von Azure Arc in 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 zum Einrichten Azure Kubernetes Service (AKS) beschrieben, die von Azure Arc aktiviert sind. Eine Übersicht über AKS, die von Arc aktiviert werden, 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. Überprüfte Lösungen finden Sie auf der Website für Azure Stack HCI-Lösungen .
Wichtig
Die Hostsysteme für Produktionsbereitstellungen müssen physische Hardware sein. Die geschachtelte Virtualisierung, die als Bereitstellen 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:
| Ressource | Maximum |
|---|---|
| Physische Server pro Cluster | 8 (Azure Stack HCI, Version 22H2 und Windows Server) |
| Gesamtzahl der virtuellen Maschinen | 200 |
Computeanforderungen
Mindestens erforderlicher Arbeitsspeicher
Sie können Ihren AKS-Cluster wie folgt einrichten, um AKS auf einem einzelnen Knoten windows Server mit begrenztem 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: Der AKS-Host verfügt über keine Workerknoten. | 8 GB | N/A: Der 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 reservierten 8 GB für das Workloadclusterupgrade wiederverwenden. | Nicht verfügbar, wenn kubevip für den Lastenausgleich (anstelle des HAProxy-Standardlastenausgleichs) verwendet wird. |
Mindestanforderung insgesamt: 30 GB RAM.
Diese Mindestanforderung gilt für eine AKS-Bereitstellung mit einem Workerknoten zum Ausführen containerisierter Anwendungen. Wenn Sie Workerknoten oder einen HAProxy-Lastenausgleich hinzufügen, ä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 der Anzahl der Workerknoten ab, die Sie im Azure Stack HCI- oder Windows Server-Cluster bereitstellen möchten. Wenn Sie sich für die Ausführung von AKS auf einem Windows Server mit einem Knoten entscheiden, erhalten Sie keine Features wie Hochverfügbarkeit, die mit der Ausführung von AKS in einem Azure Stack HCI- oder Windows Server-Cluster oder Windows Server-Failovercluster ausgestattet sind.
Andere Computeanforderungen für AKS in Azure Stack HCI und Windows Server entsprechen den Anforderungen von Azure Stack HCI. 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, müssen dasselbe Betriebssystem und dieselbe Version auf jedem Server im Cluster identisch sein. Wenn Sie Windows Server Datacenter verwenden, müssen dasselbe Betriebssystem und dieselbe Version auf jedem Server im Cluster identisch sein. Jedes Betriebssystem muss die en-us-Region und die Sprachauswahl verwenden. Diese Einstellungen können nach der Installation nicht mehr geändert werden.
Speicheranforderungen
AKS in 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 angefügter Speicher | 500 GB |
Für einen Azure Stack HCI- oder Windows Server-Cluster gibt es zwei unterstützte Speicherkonfigurationen für die Ausführung von Workloads virtueller Computer:
- 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 Dokumentation zu Azure Stack HCI. Alle Systeme, die im Azure Stack HCI-Katalog überprüft werden, fallen in eine dieser beiden unterstützten Speicherkonfigurationen.
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 Leistung 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 Direkte Speicherplätze oder eine entsprechende zertifizierte virtual SAN-Lösung zu verwenden, um eine hyperkonvergente 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 bieten möglicherweise nicht die erforderlichen Leistungsstufen für die Ausführung mehrerer Workloads virtueller Computer, und möglicherweise treten Leistungsprobleme und Timeouts auf.
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 geringeren Leistungsniveaus 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 in Azure Stack HCI 23H2 finden Sie unter Netzwerkanforderungen.
- Stellen Sie für Azure Stack HCI 22H2 und Windows Server sicher, dass Sie einen vorhandenen, externen virtuellen Switch konfiguriert haben, wenn Sie Windows Admin Center verwenden. Bei HCI- oder Windows Server-Clustern müssen dieser Switch und sein Name für alle Clusterknoten identisch sein. Informationen zu HCI 23H2 finden Sie unter 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 mit dem 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 ist, werden virtuelle Netzwerke verwendet, um ip-Adressen den Kubernetes-Ressourcen zuzuweisen, die diese benötigen, wie zuvor aufgeführt. Je nach gewünschter AKS-Netzwerkarchitektur stehen zwei Netzwerkmodelle zur Auswahl.
Hinweis
Die hier für Ihre AKS-Bereitstellungen definierte Architektur des virtuellen Netzwerks unterscheidet sich von der zugrunde liegenden physischen Netzwerkarchitektur in Ihrem Rechenzentrum.
- Statisches IP-Netzwerk: Das virtuelle Netzwerk ordnet statische IP-Adressen dem Kubernetes-Cluster-API-Server, Kubernetes-Knoten, zugrunde liegenden VMs, Lastenausgleichsmodulen und allen Kubernetes-Diensten zu, die Sie auf Ihrem Cluster ausführen.
- DHCP-Netzwerk: Das virtuelle Netzwerk ordnet dynamische IP-Adressen den Kubernetes-Knoten, zugrunde liegenden VMs und Lastenausgleichsmodulen mithilfe eines DHCP-Servers 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, ist die Anzahl der erforderlichen IP-Adressen abhängig von der AKS-Architektur und der Anzahl der Dienste, die Sie in 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 Containernetzwerkkonzepte in AKS.
Anforderungen an Netzwerkport und URL
AKS aktiviert durch Arc-Anforderungen
Beim Erstellen eines Kubernetes-Clusters in 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 zwischen ihnen geöffnet werden:
| Port | Quelle | BESCHREIBUNG | Hinweise zur Firewall |
|---|---|---|---|
| 22 | AKS-VMs | Erforderlich zum Sammeln von Protokollen bei Verwendung von Get-AksHciLogs. |
Wenn sie separate VLANs verwenden, müssen die physischen Hyper-V-Hosts auf die AKS-VMs an 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 an 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 an diesem Port zugreifen. |
| 55000 | Clusterressource (-CloudServiceCIDR) | Cloud Agent gRPC-Server. | Bei Verwendung separater VLANs müssen die AKS-VMs auf die IP-Adresse der Clusterressource an diesem Port zugreifen. |
| 65000 | Clusterressource (-CloudServiceCIDR) | Cloud Agent gRPC-Authentifizierung. | Bei Verwendung separater VLANs müssen die AKS-VMs auf die IP-Adresse der Clusterressource an diesem Port zugreifen. |
Wenn Ihr Netzwerk die Verwendung eines Proxyservers zum Herstellen einer Verbindung mit dem Internet erfordert, finden Sie weitere Informationen unter Verwenden von Proxyservereinstellungen in AKS.
Die folgenden URLs müssen Ihrer Zulassungsliste hinzugefügt werden:
| URL | Port | Notizen |
|---|---|---|
| msk8s.api.cdp.microsoft.com | 443 | Wird beim Herunterladen des AKS in Azure Stack HCI-Produktkatalogs, von Produktbits und von Betriebssystemimages von SFS verwendet. Tritt bei der Ausführung Set-AksHciConfig und bei jedem Download von SFS auf. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Wird beim Herunterladen des AKS in Azure Stack HCI-Produktkatalogs, von Produktbits und von Betriebssystemimages von SFS verwendet. Tritt bei der Ausführung Set-AksHciConfig und bei jedem Download von SFS auf. |
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 | Kubernetes mit Arc-Unterstützung verwendet Helm 3, um Azure Arc-Agents im AKS-HCI-Verwaltungscluster bereitzustellen. Dieser Endpunkt wird für den Helm-Clientdownload benötigt, um die Bereitstellung des Agent-Helm-Diagramms zu vereinfachen. |
| *.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 die AKS in Azure Stack HCI-Abrechnung, wenn Install-AksHci ausgeführt wird. |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Wird in regelmäßigen Abständen verwendet, um Microsoft erforderliche Diagnosedaten vom Azure Stack HCI- oder Windows Server-Host zu senden. |
Hinweis
AKS, das von Arc aktiviert ist, speichert und verarbeitet Kundendaten. Kundendaten verbleiben standardmäßig in der Region, in der der Kunde den Dienst instance. Diese Daten werden in regionalen, von Microsoft betriebenen Rechenzentren gespeichert. Für Regionen mit Datenresidenzanforderungen werden Kundendaten immer in derselben Region aufbewahrt.
Zusätzliche URL-Anforderungen für Azure Arc-Features
Die vorherige URL-Liste enthält die mindestens erforderlichen URLs, damit Sie Ihren AKS-Dienst zur Abrechnung mit Azure verbinden können. Sie müssen zusätzliche URLs zulassen, wenn Sie eine Clusterverbindung, benutzerdefinierte Standorte, Azure RBAC und andere Azure-Dienste wie Azure Monitor usw. für Ihren 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 die URLs von Arc für Server-Agents überprüfen.
Gestreckte Cluster in AKS
Wie in der Übersicht über stretched Cluster beschrieben, wird die Bereitstellung von AKS in Azure Stack HCI und Windows Server mithilfe von Stretched-Clustern von Windows 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 Sicherung oder Wiederherstellung von Workloadclustern mit Velero und Azure Blob Storage in Azure Stack HCI und Windows Server und Bereitstellen von Konfigurationen auf AksHci mithilfe von GitOps mit Flux v2 für 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 werden. Um Windows Admin Center mit AKS in 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.
- Bei Azure registriert.
- 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 auf der linken Seite des Azure-Portal Zugriffssteuerung (IAM) 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 Studenten 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 zu registrieren.
So überprüfen Sie, ob Sie über ausreichende Berechtigungen verfügen:
- Wechseln Sie zum Azure-Portal, und wählen Sie unter Microsoft Entra IDRollen und Administratoren 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 App-Registrierungen auf Nein festgelegt ist, können nur Benutzer mit administratorrolle diese Arten von Anwendungen registrieren. Informationen zu den verfügbaren Administratorrollen und den spezifischen Berechtigungen in Microsoft Entra ID, die den einzelnen Rollen erteilt werden, finden Sie unter Microsoft Entra integrierten 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 genügend 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 verwenden, um einen AKS-Host oder einen AKS-Workloadcluster bereitzustellen, benötigen Sie ein Azure-Abonnement, für das Sie Besitzer sind.
- Wenn Sie PowerShell zum Bereitstellen eines AKS-Hosts oder eines AKS-Workloadclusters verwenden, muss der Benutzer, der den Cluster registriert, mindestens über eine der folgenden Punkte verfügen:
- Ein Benutzerkonto mit der integrierten Rolle Besitzer.
- Ein Dienstprinzipal mit einer der folgenden Zugriffsebenen:
- Die integrierte Rolle Mitwirkender .
- Die integrierte Rolle "Besitzer ".
Wenn Ihr Azure-Abonnement über einen EA oder CSP erfolgt, 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 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 des Azure-Portal Zugriffssteuerung (IAM) und dann auf Meinen Zugriff anzeigen auswählen.
Legen Sie die folgenden PowerShell-Variablen in einem PowerShell-Verwaltungsfenster fest. Stellen Sie sicher, dass das Abonnement und der Mandant das sind, was Sie verwenden möchten, um Ihren AKS-Host für die Abrechnung zu registrieren:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Installieren und importieren Sie das AKS PowerShell-Modul:
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 verwenden möchten, um Ihren AKS-Host für die Abrechnung zu registrieren:
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 legt den Bereich auf Abonnementebene fest. 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 niedriger funktioniert. Wir laden das Modul Az.Accounts 2.6.0 automatisch herunter, 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 verfügen Sie jetzt über die Anwendungs-ID und das Geheimnis , die beim Bereitstellen von AKS verfügbar sind. Sie sollten sich diese Elemente notieren und sicher speichern. Wenn sie im Azure-Portal unter Abonnements, Access Control und dann Rollenzuweisungen erstellt werden, sollte 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 in den folgenden angegebenen Azure-Regionen. Wenn Sie versuchen, die Bereitstellung in einer Region außerhalb dieser Liste durchzuführen, tritt ein Bereitstellungsfehler auf.
Der AKS Arc-Dienst wird für Registrierung, Abrechnung und Verwaltung verwendet. Es wird derzeit in den folgenden Regionen unterstützt:
- East US
- USA Süd Mitte
- Europa, Westen
Active Directory-Anforderungen
Damit ein AKS-Failovercluster mit zwei oder mehr physischen Knoten in einer Active Directory-Umgebung optimal 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 einem Einzelnen 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 (OUs) zum Verwalten von Gruppenrichtlinien für Server und Dienste verwenden, erfordern die Benutzerkonten Listen-, Lese-, Änderungs- und Löschberechtigungen für alle Objekte in der Organisationseinheit.
- 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:
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für