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 .
Importante
I sistemi host per le distribuzioni di produzione devono essere hardware fisici. 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 supportate massime
Il servizio Azure Kubernetes nelle distribuzioni di Azure Stack HCI e Windows Server che superano le specifiche seguenti non sono supportate:
| Risorsa | Massimo |
|---|---|
| Server fisici per cluster | 8 (Azure Stack HCI versione 22H2 e Windows Server) |
| Totale 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 del ruolo 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 dispone di 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/A 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 della RAM finale 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 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:
| 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 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.
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 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:
| Tipo di cluster | Nodo del piano di controllo | Nodo del ruolo 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, è necessario riservare il numero di indirizzi IP seguente per il pool 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 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:
| Porta | Origine | Descrizione | Note sul firewall |
|---|---|---|---|
| 22 | Macchine virtuali del servizio Azure Kubernetes | Obbligatorio 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 | Obbligatorio 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 durante il download del servizio Azure Kubernetes nel catalogo dei prodotti Azure Stack HCI, nei bit del prodotto e nelle immagini del sistema operativo da SFS. Si verifica quando si esegue Set-AksHciConfig e in qualsiasi momento si scarica da SFS. |
| msk8s.b.tlu.dl.delivery.mp.microsoft.com msk8s.f.tlu.dl.delivery.mp.microsoft.com | 80 | Usato durante il download del servizio Azure Kubernetes nel catalogo dei prodotti Azure Stack HCI, nei bit del prodotto e nelle immagini del sistema operativo da SFS. Si verifica quando si esegue Set-AksHciConfig e in qualsiasi momento si scarica da SFS. |
| login.microsoftonline.com login.windows.net management.azure.com msft.sts.microsoft.com graph.windows.net | 443 | Usato per accedere 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 | Obbligatorio 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 assegnati dal sistema. |
| *.his.arc.azure.com | 443 | Obbligatorio per eseguire il pull dei certificati di identità gestita assegnati dal sistema. |
| k8connecthelm.azureedge.net | 443 | Kubernetes abilitato per Arc usa Helm 3 per distribuire gli agenti Di Azure Arc nel cluster di gestione del servizio Azure Kubernetes-HCI. 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 la fatturazione del servizio Azure Kubernetes in Azure Stack HCI 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 Azure Stack HCI 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 dei data center gestiti da Microsoft a livello di area. Per le aree con requisiti di residenza dei dati, i dati dei clienti vengono sempre conservati all'interno della stessa area.
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
Avviso
Azure Kubernetes Arc supporta attualmente la creazione di cluster esclusivamente all'interno delle aree di Azure specificate seguenti. Se si tenta di eseguire la distribuzione in un'area all'esterno di questo elenco, si verifica un errore di distribuzione.
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:
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 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:
Commenti e suggerimenti
Presto disponibile: nel corso del 2024 verranno dismessi i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedere: https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per