Systemkrav för AKS som aktiveras av Azure Arc på Azure Stack HCI 22H2
Gäller för: Azure Stack HCI, version 22H2; Windows Server 2022, Windows Server 2019
I den här artikeln beskrivs kraven för att konfigurera Azure Kubernetes Service (AKS) som aktiveras av Azure Arc. En översikt över AKS som aktiverats av Arc finns i AKS-översikten.
Maskinvarukrav
Microsoft rekommenderar att du köper en validerad maskinvaru-/programvarulösning för Azure Stack HCI från våra partner. Dessa lösningar är utformade, monterade och verifierade för att köra vår referensarkitektur och för att kontrollera kompatibilitet och tillförlitlighet så att du kommer igång snabbt. Du bör kontrollera att de system, komponenter, enheter och drivrutiner som du använder är Windows Server-certifierade enligt Windows Server-katalogen. Se webbplatsen för Azure Stack HCI-lösningar för verifierade lösningar.
Viktigt!
Värdsystemen för produktionsdistributioner måste vara fysisk maskinvara. Kapslad virtualisering, som kännetecknas av att distribuera Azure Stack HCI eller Windows Server på en virtuell dator och installera AKS på den virtuella datorn, stöds inte.
Högsta maskinvaruspecifikationer som stöds
AKS på Azure Stack HCI- och Windows Server-distributioner som överskrider följande specifikationer stöds inte:
Resurs | Högsta |
---|---|
Fysiska servrar per kluster | 8 (Azure Stack HCI version 22H2 och Windows Server) |
Totalt antal virtuella datorer | 200 |
Beräkningskrav
Minimikrav för minne
Du kan konfigurera DITT AKS-kluster på följande sätt för att köra AKS på en windows server med en enda nod med begränsat RAM-minne:
Klustertyp | Kontrollplanets VM-storlek | Arbetsnod | För uppdateringsåtgärder | Lastbalanserare |
---|---|---|---|---|
AKS-värd | Standard_A4_v2 VM-storlek = 8 GB | N/A – AKS-värden har inte arbetsnoder. | 8 GB | N/A – AKS-värden använder kubevip för belastningsutjämning. |
Arbetsbelastningskluster | Standard_A4_v2 VM-storlek = 8 GB | Standard_K8S3_v1 för 1 arbetsnod = 6 GB | Kan återanvända den här reserverade 8 GB för uppgradering av arbetsbelastningskluster. | N/A om kubevip används för belastningsutjämning (i stället för haProxy-standardlastbalanseraren). |
Totalt minimikrav: 30 GB RAM-minne.
Det här minimikravet gäller för en AKS-distribution med en arbetsnod för att köra containerbaserade program. Om du väljer att lägga till arbetsnoder eller en HAProxy-lastbalanserare ändras det slutliga RAM-kravet i enlighet med detta.
Rekommenderade beräkningskrav
Environment | CPU-kärnor per server | RAM |
---|---|---|
Azure Stack HCI | 32 | 256 GB |
Windows Server-redundanskluster | 32 | 256 GB |
Windows Server med en nod | 16 | 128 GB |
För en produktionsmiljö beror den slutliga storleken på programmet och antalet arbetsnoder som du planerar att distribuera i Azure Stack HCI- eller Windows Server-klustret. Om du väljer att köra AKS på en Windows Server med en nod får du inte funktioner som hög tillgänglighet som medföljer att köra AKS i ett Azure Stack HCI- eller Windows Server-kluster eller Windows Server-redundanskluster.
Andra beräkningskrav för AKS på Azure Stack HCI och Windows Server är i linje med Kraven för Azure Stack HCI. Mer information om Serverkrav för Azure Stack HCI finns i Systemkrav för Azure Stack HCI.
Du måste installera samma operativsystem på varje server i klustret. Om du använder Azure Stack HCI måste samma operativsystem och version vara samma på varje server i klustret. Om du använder Windows Server Datacenter måste samma operativsystem och version vara samma på varje server i klustret. Varje operativsystem måste använda region- och språkvalen en-us . Du kan inte ändra de här inställningarna efter installationen.
Lagringskrav
AKS på Azure Stack HCI och Windows Server stöder följande lagringsimplementeringar:
Name | Lagringstyp | Nödvändig kapacitet |
---|---|---|
Azure Stack HCI-kluster | Klusterdelade volymer | 1 TB |
Redundanskluster för Windows Server Datacenter | Klusterdelade volymer | 1 TB |
Windows Server Datacenter med en nod | Direktansluten lagring | 500 GB |
För ett Azure Stack HCI- eller Windows Server-kluster finns det två lagringskonfigurationer som stöds för att köra arbetsbelastningar för virtuella datorer:
- Hybridlagring balanserar prestanda och kapacitet med flashlagring och hårddiskar (HDD).
- Lagring med alla flash-enheter maximerar prestandan med hjälp av SSD:er (Solid State Drives) eller NVMe.
System som bara har HDD-baserad lagring stöds inte av Azure Stack HCI och rekommenderas därför inte för att köra AKS på Azure Stack HCI och Windows Server. Mer information om de rekommenderade enhetskonfigurationerna finns i Azure Stack HCI-dokumentationen. Alla system som verifieras i Azure Stack HCI-katalogen ingår i någon av dessa två lagringskonfigurationer som stöds.
Kubernetes använder etcd för att lagra klustrens tillstånd. Etcd lagrar konfiguration, specifikationer och status för poddar som körs. Dessutom använder Kubernetes arkivet för tjänstidentifiering. Som en koordineringskomponent för kubernetes-driften och de arbetsbelastningar som stöds är svarstid och dataflöde till etcd kritiska. Du måste köra AKS på en SSD. Mer information finns i Prestanda på etcd.io.
För ett Windows Server Datacenter-baserat kluster kan du antingen distribuera med lokal lagring eller SAN-baserad lagring. För lokal lagring rekommenderar vi att du använder den inbyggda Lagringsutrymmen Direct eller en motsvarande certifierad virtuell SAN-lösning för att skapa en hyperkonvergerad infrastruktur som presenterar klusterdelade volymer för användning av arbetsbelastningar. För Lagringsutrymmen Direct krävs det att lagringen antingen är hybrid (flash + HDD) som balanserar prestanda och kapacitet, eller helt flash (SSD, NVMe) som maximerar prestanda. Om du väljer att distribuera med SAN-baserad lagring kontrollerar du att SAN-lagringen kan leverera tillräckligt med prestanda för att köra flera arbetsbelastningar för virtuella datorer. Äldre HDD-baserad SAN-lagring kanske inte ger de prestandanivåer som krävs för att köra flera arbetsbelastningar för virtuella datorer, och du kan se prestandaproblem och tidsgränser.
För Windows Server-distributioner med en nod med lokal lagring rekommenderas användningen av all-flash storage (SSD, NVMe) starkt för att leverera den prestanda som krävs för att vara värd för flera virtuella datorer på en enda fysisk värd. Utan flashlagring kan de lägre prestandanivåerna på hårddiskar orsaka distributionsproblem och tidsgränser.
Nätverkskrav
Följande krav gäller för ett Azure Stack HCI 22H2-kluster och ett Windows Server Datacenter-kluster. Nätverkskrav på Azure Stack HCI 23H2 finns i Nätverkskrav.
- För Azure Stack HCI 22H2 och Windows Server kontrollerar du att du har en befintlig, extern virtuell växel konfigurerad om du använder Windows Administrationscenter. För HCI- eller Windows Server-kluster måste den här växeln och dess namn vara samma för alla klusternoder. Information om HCI 23H2 finns i kraven för nätverkssystemet.
- Kontrollera att du har inaktiverat IPv6 på alla nätverkskort.
- För en lyckad distribution måste Azure Stack HCI- eller Windows Server-klusternoderna och de virtuella Kubernetes-klusterdatorerna ha extern internetanslutning.
- Kontrollera att alla undernät som du definierar för klustret kan dirigeras mellan varandra och till Internet.
- Kontrollera att det finns nätverksanslutning mellan Azure Stack HCI-värdar och de virtuella klientdatorerna.
- DNS-namnmatchning krävs för att alla noder ska kunna kommunicera med varandra.
- (Rekommenderas) Aktivera dynamiska DNS-uppdateringar i DNS-miljön så att AKS kan registrera molnagentens allmänna klusternamn i DNS-systemet för identifiering.
IP-adresstilldelning
I AKS som aktiveras av Arc används virtuella nätverk för att allokera IP-adresser till De Kubernetes-resurser som kräver dem, som tidigare angetts. Det finns två nätverksmodeller att välja mellan, beroende på önskad AKS-nätverksarkitektur.
Kommentar
Arkitekturen för virtuella nätverk som definieras här för dina AKS-distributioner skiljer sig från den underliggande fysiska nätverksarkitekturen i ditt datacenter.
- Statiska IP-nätverk: Det virtuella nätverket allokerar statiska IP-adresser till Kubernetes-klustrets API-server, Kubernetes-noder, underliggande virtuella datorer, lastbalanserare och alla Kubernetes-tjänster som du kör ovanpå klustret.
- DHCP-nätverk: Det virtuella nätverket allokerar dynamiska IP-adresser till Kubernetes-noderna, underliggande virtuella datorer och lastbalanserare med hjälp av en DHCP-server. Kubernetes-klustrets API-server och alla Kubernetes-tjänster som du kör ovanpå klustret allokeras fortfarande statiska IP-adresser.
Minsta IP-adressreservation
Du bör minst reservera följande antal IP-adresser för distributionen:
Klustertyp | Kontrollplansnod | Arbetsnod | För uppdateringsåtgärder | Lastbalanserare |
---|---|---|---|---|
AKS-värd | 1 IP-adress | NA | 2 IP-adresser | NA |
Arbetsbelastningskluster | 1 IP-adress per nod | 1 IP-adress per nod | 5 IP-adresser | 1 IP-adress |
Dessutom bör du reservera följande antal IP-adresser för din VIP-pool:
Resurstyp | Antal IP-adresser |
---|---|
Kluster-API-server | 1 per kluster |
Kubernetes-tjänster | 1 per tjänst |
Som du ser varierar antalet nödvändiga IP-adresser beroende på AKS-arkitekturen och antalet tjänster som du kör i kubernetes-klustret. Vi rekommenderar att du reserverar totalt 256 IP-adresser (/24 undernät) för distributionen.
Mer information om nätverkskrav finns i begreppen för nodnätverk i AKS och containernätverksbegrepp i AKS.
Krav för nätverksport och URL
AKS aktiverat av Arc-krav
När du skapar ett Kubernetes-kluster på Azure Stack HCI öppnas följande brandväggsportar automatiskt på varje server i klustret.
Om de fysiska klusternoderna i Azure Stack HCI och de virtuella Azure Kubernetes-klusterdatorerna finns på två isolerade virtuella datorer måste dessa portar öppnas i brandväggen mellan dem:
Port | Source | beskrivning | Brandväggsanteckningar |
---|---|---|---|
22 | Virtuella AKS-datorer | Krävs för att samla in loggar när du använder Get-AksHciLogs . |
Om du använder separata VLAN måste de fysiska Hyper-V-värdarna komma åt de virtuella AKS-datorerna på den här porten. |
6443 | Virtuella AKS-datorer | Krävs för att kommunicera med Kubernetes-API:er. | Om du använder separata VLAN måste de fysiska Hyper-V-värdarna komma åt de virtuella AKS-datorerna på den här porten. |
45000 | Fysiska Hyper-V-värdar | wssdAgent gRPC-server. | Inga regler för kors-VLAN behövs. |
45001 | Fysiska Hyper-V-värdar | wssdAgent gRPC-autentisering. | Inga regler för kors-VLAN behövs. |
46000 | Virtuella AKS-datorer | wssdCloudAgent till lbagent. | Om du använder separata VLAN måste de fysiska Hyper-V-värdarna komma åt de virtuella AKS-datorerna på den här porten. |
55000 | Klusterresurs (-CloudServiceCIDR) | Cloud Agent gRPC-server. | Om du använder separata virtuella lokala nätverk måste de virtuella AKS-datorerna komma åt klusterresursens IP-adress på den här porten. |
65000 | Klusterresurs (-CloudServiceCIDR) | Cloud Agent gRPC-autentisering. | Om du använder separata virtuella lokala nätverk måste de virtuella AKS-datorerna komma åt klusterresursens IP-adress på den här porten. |
Om nätverket kräver att en proxyserver används för att ansluta till Internet kan du läsa Använda proxyserverinställningar i AKS.
Följande URL:er måste läggas till i listan över tillåtna:
webbadress | Port | Kommentar |
---|---|---|
msk8s.api.cdp.microsoft.com | 443 | Används vid nedladdning av AKS i Azure Local-produktkatalog, produktbitar och OS-avbildningar från SFS. Inträffar när du kör Set-AksHciConfig och när du laddar ned från SFS. |
msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com |
80 | Används vid nedladdning av AKS i Azure Local-produktkatalog, produktbitar och OS-avbildningar från SFS. Inträffar när du kör Set-AksHciConfig och när du laddar ned från SFS. |
login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net |
443 | Används för att logga in på Azure när du kör Set-AksHciRegistration . |
ecpacr.azurecr.io mcr.microsoft.com *.mcr.microsoft.com *.data.mcr.microsoft.com *.blob.core.windows.net US-slutpunkt: wus2replica*.blob.core.windows.net |
443 | Krävs för att hämta containeravbildningar när du kör Install-AksHci . |
<region.dp.kubernetesconfiguration.azure.com> | 443 | Krävs för att registrera AKS-hybridkluster till Azure Arc. |
gbl.his.arc.azure.com | 443 | Krävs för att hämta den regionala slutpunkten för att hämta systemtilldelade hanterade identitetscertifikat. |
*.his.arc.azure.com | 443 | Krävs för att hämta systemtilldelade hanterade identitetscertifikat. |
k8connecthelm.azureedge.net | 443 | Arc-aktiverade Kubernetes använder Helm 3 för att distribuera Azure Arc-agenter i AKS i Azure Local Management-kluster. Den här slutpunkten behövs för helm-klientens nedladdning för att underlätta distributionen av agentens helm-diagram. |
*.arc.azure.net | 443 | Krävs för att hantera AKS-hybridkluster i Azure Portal. |
dl.k8s.io | 443 | Krävs för att ladda ned och uppdatera Kubernetes-binärfiler för Azure Arc. |
akshci.azurefd.net | 443 | Krävs för AKS på lokal Azure-fakturering när du kör Install-AksHci . |
v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net |
443 | Används regelbundet för att skicka diagnostikdata som krävs av Microsoft från Azure Local- eller Windows Server-värden. |
Kommentar
AKS som aktiveras av Arc lagrar och bearbetar kunddata. Som standard finns kunddata kvar i den region där kunden distribuerar tjänstinstansen. Dessa data lagras i regionala Microsoft-drivna datacenter. För regioner med krav på datahemvist sparas kunddata alltid inom samma region.
Ytterligare URL-krav för Azure Arc-funktioner
I den föregående URL-listan beskrivs det minsta antal URL:er som krävs för att du ska kunna ansluta AKS-tjänsten till Azure för fakturering. Du måste tillåta ytterligare URL:er om du vill använda klusteranslutning, anpassade platser, Azure RBAC och andra Azure-tjänster som Azure Monitor osv. i ditt AKS-arbetsbelastningskluster. En fullständig lista över Arc-URL:er finns i Azure Arc-aktiverade Kubernetes-nätverkskrav.
Du bör också granska Azure Stack HCI-URL:er. Eftersom Arc för serveragenter nu installeras som standard på Azure Stack HCI-noder från Azure Stack HCI 21H2 och senare bör du också granska URL:erna för Arc for Server-agenter.
Utsträckta kluster i AKS
Som beskrivs i översikten stretchkluster stöds inte distribution av AKS på Azure Stack HCI och Windows Server med hjälp av Windows-stretchkluster. Vi rekommenderar att du använder en metod för säkerhetskopiering och haveriberedskap för datacentrets driftkontinuitet. Mer information finns i Utföra säkerhetskopiering eller återställning av arbetsbelastningskluster med Velero och Azure Blob Storage på Azure Stack HCI och Windows Server och Distribuera konfigurationer på AksHci med GitOps med Flux v2 för programkontinuitet.
Krav för Windows Admin Center
Windows Admin Center är användargränssnittet för att skapa och hantera AKS som aktiveras av Azure Arc. Om du vill använda Windows Admin Center med AKS på Azure Stack HCI och Windows Server måste du uppfylla alla kriterier i följande lista.
Det här är kraven för den dator som kör Windows Admin Center-gatewayen:
- Windows 10 eller Windows Server.
- Registrerad i Azure.
- I samma domän som Azure Stack HCI- eller Windows Server Datacenter-klustret.
- En Azure-prenumeration där du har ägarrättigheter. Du kan kontrollera åtkomstnivån genom att gå till din prenumeration och välja Åtkomstkontroll (IAM) till vänster i Azure Portal och sedan välja Visa min åtkomst.
Krav för Azure
Du måste ansluta till ditt Azure-konto.
Azure-konto och prenumeration
Om du inte redan har ett Azure-konto skapar du ett. Du kan använda en befintlig prenumeration av vilken typ som helst:
- Kostnadsfritt konto med Azure-krediter för studenter eller Visual Studio-prenumeranter.
- Betala per användning-prenumeration med kreditkort.
- Prenumeration som hämtas via en företagsavtal (EA).
- Prenumeration som hämtas via Molnlösningsleverantör-programmet (CSP).
Microsoft Entra-behörigheter, roll- och åtkomstnivå
Du måste ha tillräcklig behörighet för att registrera ett program med din Microsoft Entra-klientorganisation.
Om du vill kontrollera att du har tillräcklig behörighet följer du informationen nedan:
- Gå till Azure Portal och välj Roller och administratörer under Microsoft Entra-ID för att kontrollera din roll.
- Om din roll är Användare måste du se till att icke-administratörer kan registrera program.
- Om du vill kontrollera om du kan registrera program går du till Användarinställningar under Microsoft Entra-tjänsten för att kontrollera om du har behörighet att registrera ett program.
Om inställningen för appregistreringar är inställd på Nej kan endast användare med en administratörsroll registrera dessa typer av program. Mer information om tillgängliga administratörsroller och specifika behörigheter i Microsoft Entra-ID som ges till varje roll finns i Inbyggda Roller i Microsoft Entra. Om ditt konto har tilldelats användarrollen, men inställningen för appregistrering är begränsad till administratörsanvändare, ber du administratören antingen att tilldela dig en av de administratörsroller som kan skapa och hantera alla aspekter av appregistreringar eller att låta användarna registrera appar.
Om du inte har tillräckligt med behörigheter för att registrera ett program och administratören inte kan ge dig dessa behörigheter är det enklaste sättet att distribuera AKS att be Azure-administratören att skapa ett huvudnamn för tjänsten med rätt behörigheter. Administratörer kan kontrollera följande avsnitt för att lära sig hur du skapar ett huvudnamn för tjänsten.
Roll och åtkomstnivå för Azure-prenumeration
Om du vill kontrollera åtkomstnivån går du till din prenumeration, väljer Åtkomstkontroll (IAM) till vänster i Azure Portal och väljer sedan Visa min åtkomst.
- Om du använder Windows Admin Center för att distribuera en AKS-värd eller ett AKS-arbetsbelastningskluster måste du ha en Azure-prenumeration där du är ägare.
- Om du använder PowerShell för att distribuera en AKS-värd eller ett AKS-arbetsbelastningskluster måste användaren som registrerar klustret ha minst något av följande:
- Ett användarkonto med den inbyggda ägarrollen .
- Ett huvudnamn för tjänsten med någon av följande åtkomstnivåer:
- Den inbyggda deltagarrollen .
- Den inbyggda ägarrollen .
Om din Azure-prenumeration sker via en EA- eller CSP är det enklaste sättet att distribuera AKS att be din Azure-administratör att skapa ett huvudnamn för tjänsten med rätt behörigheter. Administratörer kan kontrollera följande avsnitt om hur du skapar ett huvudnamn för tjänsten.
Valfritt: skapa ett nytt huvudnamn för tjänsten
Kör följande steg för att skapa ett nytt huvudnamn för tjänsten med den inbyggda rollen Ägare . Endast prenumerationsägare kan skapa tjänstens huvudnamn med rätt rolltilldelning. Du kan kontrollera åtkomstnivån genom att gå till din prenumeration, välja Åtkomstkontroll (IAM) till vänster i Azure Portal och sedan välja Visa min åtkomst.
Ange följande PowerShell-variabler i ett PowerShell-administratörsfönster. Kontrollera att prenumerationen och klientorganisationen är det du vill använda för att registrera DIN AKS-värd för fakturering:
$subscriptionID = "<Your Azure subscrption ID>"
$tenantID = "<Your Azure tenant ID>"
Installera och importera AKS PowerShell-modulen:
Install-Module -Name AksHci
Logga in på Azure med kommandot Connect-AzAccount PowerShell:
Connect-AzAccount -tenant $tenantID
Ange den prenumeration som du vill använda för att registrera AKS-värden för fakturering som standardprenumeration genom att köra kommandot Set-AzContext :
Set-AzContext -Subscription $subscriptionID
Kontrollera att inloggningskontexten är korrekt genom att köra Kommandot Get-AzContext PowerShell. Kontrollera att prenumerationen, klientorganisationen och kontot är det du vill använda för att registrera DIN AKS-värd för fakturering:
Get-AzContext
Name Account SubscriptionName Environment TenantId
---- ------- ---------------- ----------- --------
myAzureSubscription (92391anf-... user@contoso.com myAzureSubscription AzureCloud xxxxxx-xxxx-xxxx-xxxxxx
Skapa ett huvudnamn för tjänsten genom att köra kommandot New-AzADServicePrincipal PowerShell. Det här kommandot skapar ett huvudnamn för tjänsten med rollen Ägare och anger omfånget på prenumerationsnivå. Mer information om hur du skapar tjänstens huvudnamn finns i skapa ett Huvudnamn för Azure-tjänsten med Azure PowerShell.
$sp = New-AzADServicePrincipal -role "Owner" -scope /subscriptions/$subscriptionID
Hämta lösenordet för tjänstens huvudnamn genom att köra följande kommando. Observera att det här kommandot endast fungerar för Az.Accounts 2.6.0 eller lägre. Vi laddar automatiskt ned Modulen Az.Accounts 2.6.0 när du installerar AksHci PowerShell-modulen:
$secret = $sp.PasswordCredentials[0].SecretText
Write-Host "Application ID: $($sp.ApplicationId)"
Write-Host "App Secret: $secret"
Från föregående utdata har du nu program-ID:t och hemligheten tillgänglig när du distribuerar AKS. Du bör anteckna dessa objekt och lagra dem på ett säkert sätt. Med den skapade i Azure Portal, under Prenumerationer, Åtkomstkontroll och sedan Rolltilldelningar, bör du se ditt nya huvudnamn för tjänsten.
Azure-resursgrupp
Du måste ha en Azure-resursgrupp i Azure-regionen Australien, östra, USA, östra, Asien, sydöstra eller Europa, västra före registreringen.
Azure-regioner
Varning
AKS Arc stöder för närvarande endast klusterskapande inom följande angivna Azure-regioner. Om du försöker distribuera i en region utanför den här listan uppstår ett distributionsfel.
AKS Arc-tjänsten används för registrering, fakturering och hantering. Det stöds för närvarande i följande regioner:
- USA, östra
- USA, södra centrala
- Västeuropa
Active Directory-krav
För att ett AKS-redundanskluster med 2 eller fler fysiska noder ska fungera optimalt i en Active Directory-miljö kontrollerar du att följande krav uppfylls:
Kommentar
Active Directory krävs inte för Azure Stack HCI- eller Windows Server-distributioner med en nod.
- Konfigurera tidssynkronisering så att skillnaden inte är större än 2 minuter mellan alla klusternoder och domänkontrollanten. Information om hur du ställer in tidssynkronisering finns i Windows tidstjänst.
- Kontrollera att de användarkonton som används för att lägga till uppdatering och hantera AKS- eller Windows Server Datacenter-kluster har rätt behörigheter i Active Directory. Om du använder organisationsenheter (OUs) för att hantera grupprinciper för servrar och tjänster kräver användarkontona lista, läsa, ändra och ta bort behörigheter för alla objekt i organisationsenheten.
- Använd en separat organisationsenhet (OU) för servrar och tjänster från dina AKS- eller Windows Server Datacenter-kluster. Med en separat organisationsenhet kan du styra åtkomst och behörigheter med större kornighet.
- Om du använder grupprincipobjektmallar på containrar i Active Directory kontrollerar du att distributionen av AKS på Azure Stack HCI och Windows Server är undantagen från principen.
Nästa steg
När du har uppfyllt alla förutsättningar ovan kan du konfigurera en AKS-värd på Azure Stack HCI med hjälp av: