Condividi tramite


Requisiti di sistema per il servizio Azure Kubernetes abilitati da Azure Arc in Azure Stack HCI 22H2

Si applica a: Azure Stack HCI, versioni 22H2; Windows Server 2022, Windows Server 2019

Questo articolo descrive i requisiti per la configurazione di servizio Azure Kubernetes (servizio Azure Kubernetes) abilitati da Azure Arc. Per una panoramica del servizio Azure Kubernetes abilitato da Arc, vedere panoramica del servizio Azure Kubernetes.

Requisiti hardware

Microsoft consiglia di acquistare una soluzione hardware/software di Azure Stack HCI convalidata dai partner. Queste soluzioni sono progettate, assemblate e convalidate per eseguire l'architettura di riferimento e per verificare la compatibilità e l'affidabilità in modo da essere operativi rapidamente. È consigliabile verificare che i sistemi, i componenti, i dispositivi e i driver in uso siano Certificati Windows Server in base al catalogo di Windows Server. Vedere il sito Web delle soluzioni Azure Stack HCI per le soluzioni convalidate.

Importante

I sistemi host per le distribuzioni di produzione devono essere hardware fisico. La virtualizzazione annidata, caratterizzata dalla distribuzione di Azure Stack HCI o Windows Server in una macchina virtuale e l'installazione del servizio Azure Kubernetes in tale macchina virtuale, non è supportata.

Specifiche hardware massime supportate

Il servizio Azure Kubernetes nelle distribuzioni di Azure Stack HCI e Windows Server che superano le specifiche seguenti non sono supportate:

Conto risorse Massimo
Server fisici per cluster 8 (Azure Stack HCI versione 22H2 e Windows Server)
Numero totale di macchine virtuali 200

Requisiti di calcolo

Requisiti minimi di memoria

È possibile configurare il cluster del servizio Azure Kubernetes nel modo seguente per eseguire il servizio Azure Kubernetes in un singolo nodo Windows Server con RAM limitata:

Tipo di cluster Dimensioni della macchina virtuale del piano di controllo Nodo di lavoro Per le operazioni di aggiornamento Bilanciamento del carico
Host del servizio Azure Kubernetes Standard_A4_v2 dimensioni della macchina virtuale = 8 GB N/A: l'host del servizio Azure Kubernetes non ha nodi di lavoro. 8 GB N/A: l'host del servizio Azure Kubernetes usa kubevip per il bilanciamento del carico.
Cluster del carico di lavoro Standard_A4_v2 dimensioni della macchina virtuale = 8 GB Standard_K8S3_v1 per 1 nodo di lavoro = 6 GB Può riutilizzare questo 8 GB riservato per l'aggiornamento del cluster del carico di lavoro. N/D se kubevip viene usato per il bilanciamento del carico (anziché il servizio di bilanciamento del carico HAProxy predefinito).

Requisito minimo totale: 30 GB di RAM.

Questo requisito minimo è per una distribuzione del servizio Azure Kubernetes con un nodo di lavoro per l'esecuzione di applicazioni in contenitori. Se si sceglie di aggiungere nodi di lavoro o un servizio di bilanciamento del carico HAProxy, il requisito finale della RAM cambia di conseguenza.

Ambiente Core CPU per server RAM
Azure Stack HCI 32 256 GB
Cluster di failover di Windows Server 32 256 GB
Windows Server a nodo singolo 16 128 GB

Per un ambiente di produzione, il ridimensionamento finale dipende dall'applicazione e dal numero di nodi di lavoro che si prevede di distribuire nel cluster Azure Stack HCI o Windows Server. Se si sceglie di eseguire il servizio Azure Kubernetes in un server Windows a nodo singolo, non si ottengono funzionalità come la disponibilità elevata fornita con l'esecuzione del servizio Azure Kubernetes in un cluster Azure Stack HCI o Windows Server o in un cluster di failover di Windows Server.

Altri requisiti di calcolo per il servizio Azure Kubernetes in Azure Stack HCI e Windows Server sono in linea con i requisiti di Azure Stack HCI. Per altre informazioni sui requisiti del server Azure Stack HCI, vedere Requisiti di sistema di Azure Stack HCI.

È necessario installare lo stesso sistema operativo in ogni server del cluster. Se si usa Azure Stack HCI, lo stesso sistema operativo e la stessa versione devono trovarsi nello stesso server del cluster. Se si usa Windows Server Datacenter, lo stesso sistema operativo e la stessa versione devono essere uguali in ogni server del cluster. Ogni sistema operativo deve usare le selezioni di lingua e area en-us . Non è possibile modificare queste impostazioni dopo l'installazione.

Requisiti di archiviazione

Il servizio Azure Kubernetes in Azure Stack HCI e Windows Server supporta le implementazioni di archiviazione seguenti:

Nome Tipo di archiviazione Capacità richiesta
Cluster Azure Stack HCI Volumi condivisi cluster 1 TB
Cluster di failover di Windows Server Datacenter Volumi condivisi cluster 1 TB
Windows Server Datacenter a nodo singolo Archiviazione collegata diretta 500 GB

Per un cluster Azure Stack HCI o Windows Server, sono disponibili due configurazioni di archiviazione supportate per l'esecuzione di carichi di lavoro delle macchine virtuali:

  • L'archiviazione ibrida bilancia le prestazioni e la capacità usando l'archiviazione flash e le unità disco rigido (HDD).
  • L'archiviazione all-flash ottimizza le prestazioni usando unità SSD (Solid State Drive) o NVMe.

I sistemi con archiviazione basata su HDD non sono supportati da Azure Stack HCI e pertanto non sono consigliati per l'esecuzione del servizio Azure Kubernetes in Azure Stack HCI e Windows Server. Per altre informazioni sulle configurazioni di unità consigliate, vedere la documentazione di Azure Stack HCI. Tutti i sistemi convalidati nel catalogo di Azure Stack HCI rientrano in una di queste due configurazioni di archiviazione supportate.

Kubernetes usa etcd per archiviare lo stato dei cluster. Etcd archivia la configurazione, le specifiche e lo stato dei pod in esecuzione. Kubernetes usa anche l'archivio per l'individuazione dei servizi. Come componente di coordinamento per il funzionamento di Kubernetes e dei carichi di lavoro supportati, la latenza e velocità effettiva in etcd sono fondamentali. È necessario eseguire il servizio Azure Kubernetes in un'unità SSD. Per altre informazioni, vedere Prestazioni in etcd.io.

Per un cluster basato su Windows Server Datacenter, è possibile eseguire la distribuzione con l'archiviazione locale o l'archiviazione basata su SAN. Per l'archiviazione locale, è consigliabile usare il Spazi di archiviazione diretta predefinito o una soluzione SAN virtuale certificata equivalente per creare un'infrastruttura iperconvergente che presenta volumi condivisi cluster per l'uso da parte dei carichi di lavoro. Per Spazi di archiviazione diretta, è necessario che l'archiviazione sia ibrida (flash + HDD) che bilancia le prestazioni e la capacità, o all-flash (SSD, NVMe) che ottimizza le prestazioni. Se si sceglie di eseguire la distribuzione con l'archiviazione basata su SAN, assicurarsi che l'archiviazione SAN possa offrire prestazioni sufficienti per eseguire diversi carichi di lavoro di macchine virtuali. L'archiviazione SAN basata su HDD meno recente potrebbe non offrire i livelli di prestazioni necessari per eseguire più carichi di lavoro di macchine virtuali e potrebbero verificarsi problemi di prestazioni e timeout.

Per le distribuzioni a nodo singolo di Windows Server tramite l'archiviazione locale, è consigliabile usare l'archiviazione all-flash (SSD, NVMe) per offrire le prestazioni necessarie per ospitare più macchine virtuali in un singolo host fisico. Senza l'archiviazione flash, i livelli inferiori di prestazioni nei dischi HDD possono causare problemi di distribuzione e timeout.

Requisiti di rete

I requisiti seguenti si applicano a un cluster Azure Stack HCI 22H2 e a un cluster Windows Server Datacenter. Per i requisiti di rete in Azure Stack HCI 23H2, vedere Requisiti di rete.

  • Per Azure Stack HCI 22H2 e Windows Server, verificare di avere un commutatore virtuale esterno esistente configurato se si usa Windows Admin Center. Per i cluster HCI o Windows Server, questa opzione e il relativo nome devono essere uguali in tutti i nodi del cluster. Per HCI 23H2, vedere i requisiti di sistema di rete.
  • Verificare di aver disabilitato IPv6 in tutte le schede di rete.
  • Per una distribuzione corretta, i nodi del cluster Azure Stack HCI o Windows Server e le macchine virtuali del cluster Kubernetes devono avere connettività Internet esterna.
  • Assicurarsi che tutte le subnet definite per il cluster siano instradabili tra loro e verso Internet.
  • Assicurarsi che sia presente la connettività di rete tra gli host di Azure Stack HCI e le macchine virtuali tenant.
  • La risoluzione dei nomi DNS è necessaria per consentire a tutti i nodi di comunicare tra loro.
  • (Scelta consigliata) Abilitare gli aggiornamenti DNS dinamici nell'ambiente DNS per consentire al servizio Azure Kubernetes di registrare il nome del cluster generico dell'agente cloud nel sistema DNS per l'individuazione.

Assegnazione indirizzi IP

Nel servizio Azure Kubernetes abilitato da Arc le reti virtuali vengono usate per allocare indirizzi IP alle risorse Kubernetes che le richiedono, come indicato in precedenza. Esistono due modelli di rete tra cui scegliere, a seconda dell'architettura di rete del servizio Azure Kubernetes desiderata.

Nota

L'architettura di rete virtuale definita qui per le distribuzioni del servizio Azure Kubernetes è diversa dall'architettura di rete fisica sottostante nel data center.

  • Rete IP statica: la rete virtuale alloca gli indirizzi IP statici al server API del cluster Kubernetes, ai nodi Kubernetes, alle macchine virtuali sottostanti, ai servizi di bilanciamento del carico e ai servizi Kubernetes eseguiti nel cluster.
  • Rete DHCP: la rete virtuale alloca gli indirizzi IP dinamici ai nodi Kubernetes, alle macchine virtuali sottostanti e ai servizi di bilanciamento del carico usando un server DHCP. Il server API del cluster Kubernetes e tutti i servizi Kubernetes eseguiti sopra il cluster vengono ancora allocati indirizzi IP statici.

Prenotazione minima degli indirizzi IP

È necessario riservare almeno il numero di indirizzi IP seguenti per la distribuzione:

Tipo di cluster Nodo del piano di controllo Nodo di lavoro Per le operazioni di aggiornamento Bilanciamento del carico
Host del servizio Azure Kubernetes 1 IP ND 2 IP ND
Cluster del carico di lavoro 1 IP per nodo 1 IP per nodo 5 IP 1 IP

È inoltre consigliabile riservare il numero di indirizzi IP seguente per il pool di indirizzi VIP:

Tipo di risorsa Numero di indirizzi IP
Server API del cluster 1 per cluster
Servizi Kubernetes 1 per servizio

Come si può notare, il numero di indirizzi IP necessari è variabile a seconda dell'architettura del servizio Azure Kubernetes e del numero di servizi eseguiti nel cluster Kubernetes. È consigliabile riservare un totale di 256 indirizzi IP (/24 subnet) per la distribuzione.

Per altre informazioni sui requisiti di rete, vedere Concetti relativi alla rete dei nodi nel servizio Azure Kubernetes e concetti di rete dei contenitori nel servizio Azure Kubernetes.

Requisiti di porta di rete e URL

Servizio Azure Kubernetes abilitato dai requisiti di Arc

Quando si crea un cluster Kubernetes in Azure Stack HCI, le porte del firewall seguenti vengono aperte automaticamente in ogni server del cluster.

Se i nodi del cluster fisico Azure Stack HCI e le macchine virtuali del cluster Azure Kubernetes si trovano in due vlan isolate, queste porte devono essere aperte nel firewall tra di esse:

Porta Origine Descrizione Note del firewall
22 Macchine virtuali del servizio Azure Kubernetes Necessario per raccogliere i log quando si usa Get-AksHciLogs. Se si usano VLAN separate, gli host Hyper-V fisici devono accedere alle macchine virtuali del servizio Azure Kubernetes su questa porta.
6443 Macchine virtuali del servizio Azure Kubernetes Necessario per comunicare con le API Kubernetes. Se si usano VLAN separate, gli host Hyper-V fisici devono accedere alle macchine virtuali del servizio Azure Kubernetes su questa porta.
45000 Host Hyper-V fisici server wssdAgent gRPC. Non sono necessarie regole cross-VLAN.
45001 Host Hyper-V fisici autenticazione gRPC wssdAgent. Non sono necessarie regole cross-VLAN.
46000 Macchine virtuali del servizio Azure Kubernetes wssdCloudAgent a lbagent. Se si usano VLAN separate, gli host Hyper-V fisici devono accedere alle macchine virtuali del servizio Azure Kubernetes su questa porta.
55000 Risorsa cluster (-CloudServiceCIDR) Server gRPC dell'agente cloud. Se si usano VLAN separate, le macchine virtuali del servizio Azure Kubernetes devono accedere all'indirizzo IP della risorsa cluster su questa porta.
65000 Risorsa cluster (-CloudServiceCIDR) Autenticazione gRPC dell'agente cloud. Se si usano VLAN separate, le macchine virtuali del servizio Azure Kubernetes devono accedere all'indirizzo IP della risorsa cluster su questa porta.

Se la rete richiede l'uso di un server proxy per connettersi a Internet, vedere Usare le impostazioni del server proxy nel servizio Azure Kubernetes.

Gli URL seguenti devono essere aggiunti all'elenco elementi consentiti:

URL Porta Note
msk8s.api.cdp.microsoft.com 443 Usato quando si scarica il servizio Azure Kubernetes nel catalogo dei prodotti locali di Azure, nei bit di prodotto e nelle immagini del sistema operativo da SFS. Si verifica durante l'esecuzione Set-AksHciConfig e ogni volta che si esegue il download da SFS.

msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com
80 Usato quando si scarica il servizio Azure Kubernetes nel catalogo dei prodotti locali di Azure, nei bit di prodotto e nelle immagini del sistema operativo da SFS. Si verifica durante l'esecuzione Set-AksHciConfig e ogni volta che si esegue il download da SFS.

login.microsoftonline.com login.windows.net management.azure.com
msft.sts.microsoft.com
graph.windows.net
443 Usato per l'accesso ad Azure durante l'esecuzione di Set-AksHciRegistration.

ecpacr.azurecr.io mcr.microsoft.com
*.mcr.microsoft.com
*.data.mcr.microsoft.com
*.blob.core.windows.net
endpoint degli Stati Uniti: wus2replica*.blob.core.windows.net
443 Necessario per eseguire il pull delle immagini del contenitore durante l'esecuzione di Install-AksHci.
<region.dp.kubernetesconfiguration.azure.com> 443 Necessario per eseguire l'onboarding di cluster ibridi del servizio Azure Kubernetes in Azure Arc.
gbl.his.arc.azure.com 443 Obbligatorio per ottenere l'endpoint a livello di area per il pull dei certificati di identità gestita assegnata dal sistema.
*.his.arc.azure.com 443 Obbligatorio per eseguire il pull dei certificati di identità gestita assegnata dal sistema.
k8connecthelm.azureedge.net 443 Kubernetes con abilitazione di Arc usa Helm 3 per distribuire gli agenti di Azure Arc nel servizio Azure Kubernetes nel cluster di gestione locale di Azure. Questo endpoint è necessario per il download del client Helm per facilitare la distribuzione del grafico Helm dell'agente.
*.arc.azure.net 443 Necessario per gestire i cluster ibridi del servizio Azure Kubernetes in portale di Azure.
dl.k8s.io 443 Obbligatorio per scaricare e aggiornare i file binari kubernetes per Azure Arc.
akshci.azurefd.net 443 Obbligatorio per il servizio Azure Kubernetes nella fatturazione locale di Azure durante l'esecuzione di Install-AksHci.

v20.events.data.microsoft.com gcs.prod.monitoring.core.windows.net
443 Usato periodicamente per inviare i dati di diagnostica richiesti da Microsoft dall'host locale di Azure o Windows Server.

Nota

Il servizio Azure Kubernetes abilitato da Arc archivia ed elabora i dati dei clienti. Per impostazione predefinita, i dati dei clienti rimangono all'interno dell'area in cui il cliente distribuisce l'istanza del servizio. Questi dati vengono archiviati all'interno di data center gestiti da Microsoft a livello di area. Per le aree con requisiti di residenza dei dati, i dati dei clienti vengono sempre mantenuti all'interno della stessa area.

Requisiti di URL aggiuntivi per le funzionalità di Azure Arc

L'elenco di URL precedente copre gli URL minimi necessari per la connessione del servizio Azure Kubernetes ad Azure per la fatturazione. È necessario consentire URL aggiuntivi se si vuole usare la connessione del cluster, le posizioni personalizzate, il controllo degli accessi in base al ruolo di Azure e altri servizi di Azure, ad esempio Monitoraggio di Azure e così via, nel cluster del carico di lavoro del servizio Azure Kubernetes. Per un elenco completo degli URL arc, vedere Requisiti di rete Kubernetes abilitati per Azure Arc.

È anche consigliabile esaminare gli URL di Azure Stack HCI. Poiché Arc per gli agenti server è ora installato per impostazione predefinita nei nodi di Azure Stack HCI da Azure Stack HCI 21H2 e versioni successive, è necessario esaminare anche Arc per gli URL degli agenti server.

Cluster estesi nel servizio Azure Kubernetes

Come descritto nella panoramica dei cluster estesi, la distribuzione del servizio Azure Kubernetes in Azure Stack HCI e Windows Server con cluster estesi di Windows non è supportata. È consigliabile usare un approccio di backup e ripristino di emergenza per la continuità operativa del data center. Per altre informazioni, vedere Eseguire il backup o il ripristino del cluster del carico di lavoro usando Velero e Archiviazione BLOB di Azure in Azure Stack HCI e Windows Server e Distribuire configurazioni in AksHci usando GitOps con Flux v2 per la continuità dell'applicazione.

Requisiti di Windows Admin Center

Windows Admin Center è l'interfaccia utente per la creazione e la gestione del servizio Azure Kubernetes abilitato da Azure Arc. Per usare Windows Admin Center con il servizio Azure Kubernetes in Azure Stack HCI e Windows Server, è necessario soddisfare tutti i criteri nell'elenco seguente.

Questi sono i requisiti per il computer che esegue il gateway di Windows Admin Center:

  • Windows 10 o Windows Server.
  • Registrato in Azure.
  • Nello stesso dominio del cluster Azure Stack HCI o Windows Server Datacenter.
  • Una sottoscrizione di Azure in cui si dispone dei diritti di proprietario. È possibile controllare il livello di accesso passando alla sottoscrizione e selezionando Controllo di accesso (IAM) sul lato sinistro del portale di Azure e quindi selezionando Visualizza l'accesso.

Requisiti di Azure

È necessario connettersi all'account Azure.

Account e sottoscrizione di Azure

Se non si ha già un account Azure, crearne uno. È possibile usare una sottoscrizione esistente di qualsiasi tipo:

Autorizzazioni, ruolo e livello di accesso di Microsoft Entra

È necessario disporre di autorizzazioni sufficienti per registrare un'applicazione con il tenant di Microsoft Entra.

Per verificare di disporre di autorizzazioni sufficienti, seguire le informazioni seguenti:

  • Passare al portale di Azure e selezionare Ruoli e amministratori in Microsoft Entra ID per controllare il ruolo.
  • Se il ruolo è Utente, è necessario assicurarsi che gli utenti non amministratori possano registrare le applicazioni.
  • Per verificare se è possibile registrare le applicazioni, passare a Impostazioni utente nel servizio Microsoft Entra per verificare se si dispone dell'autorizzazione per registrare un'applicazione.

Se l'impostazione registrazioni dell'app è impostata su No, solo gli utenti con un ruolo di amministratore possono registrare questi tipi di applicazioni. Per informazioni sui ruoli di amministratore disponibili e sulle autorizzazioni specifiche in Microsoft Entra ID assegnati a ogni ruolo, vedere Ruoli predefiniti di Microsoft Entra. Se all'account è assegnato il ruolo Utente , ma l'impostazione di registrazione dell'app è limitata agli utenti amministratori, chiedere all'amministratore di assegnare uno dei ruoli di amministratore che possono creare e gestire tutti gli aspetti delle registrazioni dell'app o per consentire agli utenti di registrare le app.

Se non si dispone di autorizzazioni sufficienti per registrare un'applicazione e l'amministratore non può concedere queste autorizzazioni, il modo più semplice per distribuire il servizio Azure Kubernetes consiste nel chiedere all'amministratore di Azure di creare un'entità servizio con le autorizzazioni appropriate. Gli amministratori possono controllare la sezione seguente per informazioni su come creare un'entità servizio.

Livello di accesso e ruolo della sottoscrizione di Azure

Per controllare il livello di accesso, passare alla sottoscrizione, selezionare Controllo di accesso (IAM) sul lato sinistro del portale di Azure e quindi selezionare Visualizza l'accesso.

  • Se si usa Windows Admin Center per distribuire un host del servizio Azure Kubernetes o un cluster del carico di lavoro del servizio Azure Kubernetes, è necessario avere una sottoscrizione di Azure in cui si è proprietari.
  • Se si usa PowerShell per distribuire un host del servizio Azure Kubernetes o un cluster del carico di lavoro del servizio Azure Kubernetes, l'utente che registra il cluster deve avere almeno uno dei seguenti elementi:
    • Un account utente con il ruolo proprietario predefinito.
    • Un'entità servizio con uno dei livelli di accesso seguenti:

Se la sottoscrizione di Azure è tramite un contratto Enterprise o CSP, il modo più semplice per distribuire il servizio Azure Kubernetes consiste nel chiedere all'amministratore di Azure di creare un'entità servizio con le autorizzazioni appropriate. Gli amministratori possono controllare la sezione seguente su come creare un'entità servizio.

Facoltativo: creare una nuova entità servizio

Eseguire la procedura seguente per creare una nuova entità servizio con il ruolo Proprietario predefinito. Solo i proprietari delle sottoscrizioni possono creare entità servizio con l'assegnazione di ruolo corretta. È possibile controllare il livello di accesso passando alla sottoscrizione, selezionando Controllo di accesso (IAM) sul lato sinistro del portale di Azure e quindi selezionando Visualizza l'accesso.

Impostare le variabili di PowerShell seguenti in una finestra di amministrazione di PowerShell. Verificare che la sottoscrizione e il tenant siano gli elementi da usare per registrare l'host del servizio Azure Kubernetes per la fatturazione:

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

Installare e importare il modulo PowerShell del servizio Azure Kubernetes:

Install-Module -Name AksHci

Accedere ad Azure usando il comando PowerShell Connect-AzAccount :

Connect-AzAccount -tenant $tenantID

Impostare la sottoscrizione da usare per registrare l'host del servizio Azure Kubernetes per la fatturazione come sottoscrizione predefinita eseguendo il comando Set-AzContext :

Set-AzContext -Subscription $subscriptionID

Verificare che il contesto di accesso sia corretto eseguendo il comando Get-AzContext di PowerShell. Verificare che la sottoscrizione, il tenant e l'account siano gli elementi da usare per registrare l'host del servizio Azure Kubernetes per la fatturazione:

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

Creare un'entità servizio eseguendo il comando New-AzADServicePrincipal di PowerShell. Questo comando crea un'entità servizio con il ruolo Proprietario e imposta l'ambito a livello di sottoscrizione. Per altre informazioni sulla creazione di entità servizio, vedere Creare un'entità servizio di Azure con Azure PowerShell.

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

Recuperare la password per l'entità servizio eseguendo il comando seguente. Si noti che questo comando funziona solo per Az.Accounts 2.6.0 o versione successiva. Il modulo Az.Accounts 2.6.0 viene scaricato automaticamente quando si installa il modulo AksHci PowerShell:

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

Nell'output precedente sono ora disponibili l'ID applicazione e il segreto durante la distribuzione del servizio Azure Kubernetes. È consigliabile prendere nota di questi elementi e archiviarli in modo sicuro. Dopo aver creato, nella portale di Azure, in Sottoscrizioni, Controllo di accesso e quindi Assegnazioni di ruolo, verrà visualizzata la nuova entità servizio.

Gruppo di risorse di Azure

È necessario disporre di un gruppo di risorse di Azure nell'area di Azure Australia orientale, Stati Uniti orientali, Asia sud-orientale o Europa occidentale prima della registrazione.

Aree di Azure

Avviso

Azure Kubernetes Arc supporta attualmente la creazione di cluster esclusivamente nelle aree di Azure specificate seguenti. Se si tenta di eseguire la distribuzione in un'area esterna a questo elenco, si verifica un errore di distribuzione.

Il servizio Azure Kubernetes Arc viene usato per la registrazione, la fatturazione e la gestione. Attualmente è supportato nelle aree seguenti:

  • Stati Uniti orientali
  • Stati Uniti centro-meridionali
  • Europa occidentale

Requisiti di Active Directory

Affinché un cluster di failover del servizio Azure Kubernetes con 2 o più nodi fisici funzioni in modo ottimale in un ambiente Active Directory, verificare che siano soddisfatti i requisiti seguenti:

Nota

Active Directory non è necessario per le distribuzioni di Azure Stack HCI o Windows Server a nodo singolo.

  • Configurare la sincronizzazione dell'ora in modo che la divergenza non sia superiore a 2 minuti tra tutti i nodi del cluster e il controller di dominio. Per informazioni sull'impostazione della sincronizzazione dell'ora, vedere Servizio ora di Windows.
  • Assicurarsi che gli account utente usati per aggiungere l'aggiornamento e gestire i cluster del servizio Azure Kubernetes o Windows Server Datacenter dispongano delle autorizzazioni corrette in Active Directory. Se si usano unità organizzative per gestire i criteri di gruppo per server e servizi, gli account utente richiedono l'elenco, la lettura, la modifica e l'eliminazione delle autorizzazioni per tutti gli oggetti nell'unità organizzativa.
  • Usare un'unità organizzativa separata per i server e i servizi dal servizio Azure Kubernetes o dai cluster Windows Server Datacenter. L'uso di un'unità organizzativa separata consente di controllare l'accesso e le autorizzazioni con maggiore granularità.
  • Se si usano modelli di oggetto Criteri di gruppo nei contenitori in Active Directory, assicurarsi che la distribuzione del servizio Azure Kubernetes in Azure Stack HCI e Windows Server sia esente dai criteri.

Passaggi successivi

Dopo aver soddisfatto tutti i prerequisiti precedenti, è possibile configurare un host del servizio Azure Kubernetes in Azure Stack HCI usando: