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.
Requisiti di calcolo consigliati
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:
- 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 Contratto Enterprise (EA).
- Sottoscrizione ottenuta tramite il programma Cloud Solution Provider (CSP).
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:
- 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 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: