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 configurare servizio Azure Kubernetes (Servizio Azure Kubernetes) abilitato 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 verificare la compatibilità e l'affidabilità in modo da poter essere aggiornati e in esecuzione rapidamente. È consigliabile verificare che i sistemi, i componenti, i dispositivi e i driver usati siano Windows Server Certified per Windows Server Catalog. Per le soluzioni convalidate, vedere il sito Web delle soluzioni HCI di Azure Stack .

Specifiche hardware supportate massime

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

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:

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 della RAM finale cambia di conseguenza.

Requisiti di calcolo consigliati

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 il 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 HCI di 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 nel 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:

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

• L'archiviazione ibrida bilancia le prestazioni e la capacità usando l'archiviazione flash e i dischi rigidi (HDD).
• L'archiviazione all-flash ottimizza le prestazioni usando unità a stato solido (SSD) 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 inoltre l'archivio per l'individuazione dei servizi. Come componente di coordinamento per l'operazione di Kubernetes e i carichi di lavoro supportati, la latenza e velocità effettiva in etcd sono critici. È necessario eseguire il servizio Azure Kubernetes in un SSD. Per altre informazioni, vedere Prestazioni in etcd.io.

Per un cluster basato su Windows Server Datacenter, è possibile distribuire con l'archiviazione locale o l'archiviazione basata su SAN. Per l'archiviazione locale, è consigliabile usare l'Spazi di archiviazione diretta predefinita o una soluzione SAN virtuale certificata equivalente per creare un'infrastruttura iperconvergente che presenta volumi condivisi cluster da usare dai 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 distribuire 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 delle macchine virtuali e potrebbe verificarsi problemi di prestazioni e timeout.

Per le distribuzioni di Windows Server a nodo singolo usando 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 archiviazione flash, i livelli inferiori di prestazioni nei dischi RIGIDI potrebbero causare problemi di distribuzione e timeout.

Requisiti di rete

I requisiti seguenti si applicano a un cluster HCI 22H2 di Azure Stack 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 corretta distribuzione, 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 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.

• Rete IP statica: la rete virtuale alloca 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 sul cluster.
• Rete DHCP: la rete virtuale alloca 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

Come minimo, è necessario riservare il numero di indirizzi IP seguente per la distribuzione:

Inoltre, è necessario riservare il numero di indirizzi IP seguente per il pool VIP:

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 per la porta di rete e l'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:

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.

[{
    "URL": "msk8s.api.cdp.microsoft.com",
    "Port": "443 ",
    "Notes": "Used when downloading the AKS on Azure Stack HCI product catalog, product bits, and OS images from SFS.Occurs when running `Set-AksHciConfig` and at any time you download from SFS."
}, {
    "URL": "msk8s.b.tlu.dl.delivery.mp.microsoft.com",
    "Port": "80",
    "Notes": "Used when downloading the AKS on Azure Stack HCI product catalog, product bits, and OS images from SFS. Occurs when running `Set-AksHciConfig` and at any time you download from SFS."
}, {
    "URL": "msk8s.f.tlu.dl.delivery.mp.microsoft.com",
    "Port": "80",
    "Notes": "Used when downloading the AKS on Azure Stack HCI product catalog, product bits, and OS images from SFS. Occurs when running `Set-AksHciConfig` and at any time you download from SFS."
}, {
    "URL": "login.microsoftonline.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "login.windows.net",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "management.azure.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "www.microsoft.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "msft.sts.microsoft.com",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "graph.windows.net",
    "Port": "443",
    "Notes": "Used for logging into Azure when running `Set-AksHciRegistration`."
}, {
    "URL": "ecpacr.azurecr.io",
    "Port": "443",
    "Notes": "Required to pull container images when running `Install-AksHci`."
}, {
    "URL": "*.blob.core.windows.net  US endpoint: wus2replica*.blob.core.windows.net",
    "Port": "443",
    "Notes": "Required to pull container images when running `Install-AksHci`."
}, {
    "URL": "mcr.microsoft.com, *.mcr.microsoft.com",
    "Port": "443",
    "Notes": "Required to pull container images when running `Install-AksHci`."
}, {
    "URL": "akshci.azurefd.net",
    "Port": "443",
    "Notes": "Required for AKS on Azure Stack HCI billing when running `Install-AksHci`."
}, {
    "URL": "v20.events.data.microsoft.com",
    "Port": "443",
    "Notes": "Used periodically to send Microsoft required diagnostic data from the Azure Stack HCI or Windows Server host."
}, {
    "URL": "gcs.prod.monitoring.core.windows.net",
    "Port": "443",
    "Notes": "Used periodically to send Microsoft required diagnostic data from control plane nodes."
}]

Requisiti url aggiuntivi per le funzionalità di Azure Arc

L'elenco di URL precedente illustra gli URL minimi necessari per connettere il servizio Azure Kubernetes ad Azure per la fatturazione. È necessario consentire URL aggiuntivi se si vuole usare la connessione al 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 abilitata 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 Windows Admin Center:

• Windows 10 o Windows Server.
• Registrato con 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:

• Account gratuito con crediti Azure per studenti o sottoscrittori di Visual Studio.
• Sottoscrizione con pagamento in base al consumo con carta di credito.
• Sottoscrizione ottenuta tramite un Enterprise Agreement (EA).
• Sottoscrizione ottenuta tramite il programma Cloud Solution Provider (CSP).

Microsoft Entra autorizzazioni, ruolo e livello di accesso

È necessario disporre di autorizzazioni sufficienti per registrare un'applicazione con il tenant 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 Microsoft Entra ruoli predefiniti. 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 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:
  • Un account utente con il ruolo Proprietario predefinito.
  • Un'entità servizio con uno dei livelli di accesso seguenti:
    • Ruolo Collaboratore predefinito.
    • Ruolo proprietario predefinito.

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 di 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 personale.

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 PowerShell New-AzADServicePrincipal . 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"

Dall'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 Australia orientale, Stati Uniti orientali, Asia sud-orientale o Europa occidentale di Azure prima della registrazione.

Aree di Azure

Il servizio Arc del servizio Azure Kubernetes 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

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

• Configurare la sincronizzazione dell'ora in modo che la divergenza non sia superiore a 2 minuti in tutti i nodi del cluster e nel 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:

• Windows Admin Center
• PowerShell