Risolvere i problemi e gli errori durante un'installazione di Arc del servizio Azure Kubernetes

Questo messaggio di errore viene visualizzato dopo l'esecuzione di Install-AksHci.

Se non si usa collegamento privato, per risolvere questo problema, seguire questa procedura:

1. Aprire PowerShell ed eseguire Uninstall-AksHci.
2. Aprire il portale di Azure e passare al gruppo di risorse usato durante l'esecuzione di Install-AksHci.
3. Verificare la presenza di tutte le risorse del cluster connesse visualizzate in uno stato Disconnesso e includere un nome visualizzato come GUID generato in modo casuale.
4. Eliminare queste risorse cluster.
5. Chiudere la sessione di PowerShell e aprire una nuova sessione prima di eseguire Install-AksHci di nuovo.

Questo errore può essere causato dal processo di installazione che tenta di violare un criterio di Azure impostato nella sottoscrizione di Azure o nel gruppo di risorse fornito durante il processo di onboarding di Azure Arc. Questo errore può verificarsi per gli utenti che hanno definito Criteri di Azure a livello di sottoscrizione o gruppo di risorse e quindi tentano di installare il servizio Azure Kubernetes in Azure Stack HCI che viola un Criteri di Azure.

Per risolvere questo problema, leggere il messaggio di errore per comprendere quale Criteri di Azure impostato dall'amministratore di Azure è stato violato e quindi modificare i criteri di Azure apportando un'eccezione ai criteri di Azure. Per altre informazioni sulle eccezioni dei criteri, vedere Criteri di Azure struttura di esenzione.

Una funzionalità installata in precedenza rimane in uno stato di errore e non è stata cancellata. Può essere visualizzato l'errore seguente:

Exception [An error occurred while creating resource 'MOC Cloud Agent Service' for the clustered role 'ca-3f72bdeb-xxxx-4ae9-a721-3aa902a998f0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2987
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[The object already exists]

In alternativa, potresti vedere:

Install-Moc failed.
Exception [Unable to save property changes for 'IPv4 Address xxx.168.18.0'.]
Stacktrace [at Add-FailoverClusterGenericRole, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Common.psm1: line 2971
at Install-CloudAgent, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1310
at Install-MocAgents, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1229
at Initialize-Cloud, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1135
at Install-MocInternal, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 1078
at Install-Moc, C:\Program Files\WindowsPowerShell\Modules\Moc\1.0.20\Moc.psm1: line 207
at Install-AksHciInternal, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 3867
at Install-AksHci, C:\Program Files\WindowsPowerShell\Modules\AksHci\1.1.25\AksHci.psm1: line 778
at <ScriptBlock>, <No file>: line 1]
InnerException[A matching cluster network for the specified IP address could not be found]

Per risolvere questo problema, pulire manualmente il ruolo del cluster. È possibile rimuovere la risorsa dalla gestione cluster di failover eseguendo il cmdlet di PowerShell seguente: Remove-ClusterResource -name <resource name>.

Il Install-AksHci cmdlet non riesce con "GetRelease error returned by API call: File download error: File download error: Hash mismatch".

1. Aprire PowerShell ed eseguire Uninstall-AksHci.
2. Riprovare a eseguire un'installazione.
3. Se il problema persiste, usare il -concurrentDownloads parametro con Set-AksHciConfig e impostarlo su un numero inferiore al valore predefinito 10 prima di riprovare a eseguire un'installazione. La riduzione del numero di download simultanei può aiutare le reti sensibili a completare correttamente i download di file di grandi dimensioni. Questo parametro è una funzionalità di anteprima.

Dopo la distribuzione, quando si riavviano i nodi di Azure Stack HCI, il report del servizio Azure Kubernetes ha mostrato uno stato di errore per la fatturazione.

Per risolvere questo problema, seguire le istruzioni per ruotare manualmente il token e riavviare il plug-in del Servizio di gestione delle chiavi.

Dopo l'esecuzione di Install-AksHci, l'installazione è stata arrestata e visualizzato il messaggio di errore seguente:

\kubectl.exe --kubeconfig=C:\AksHci\0.9.7.3\kubeconfig-clustergroup-management 
get akshciclusters -o json returned a non zero exit code 1 
[Unable to connect to the server: dial tcp 192.168.0.150:6443: 
connectex: A connection attempt failed because the connected party 
did not properly respond after a period of time, or established connection 
failed because connected host has failed to respond.]

Esistono diversi motivi per cui un'installazione potrebbe non riuscire con l'errore waiting for API server .

Nella sezione seguente vengono illustrate le possibili cause e soluzioni per questo errore.

Motivo 1: Configurazione non corretta del gateway IP Se si usano indirizzi IP statici e viene visualizzato il messaggio di errore seguente, verificare che la configurazione per l'indirizzo IP e il gateway sia corretta.

Install-AksHci 
C:\AksHci\kvactl.exe create --configfile C:\AksHci\yaml\appliance.yaml  --outfile C:\AksHci\kubeconfig-clustergroup-management returned a non-zero exit code 1 [ ]

Per verificare se è disponibile la configurazione corretta per l'indirizzo IP e il gateway, eseguire il comando seguente:

ipconfig /all

Nelle impostazioni di configurazione visualizzate verificare la configurazione. È anche possibile provare a eseguire il ping del gateway IP e del server DNS.

ping <DNS server>

Se questi metodi non funzionano, usare New-AksHciNetworkSetting per modificare la configurazione.

Motivo 2: Server DNS errato Se si usano indirizzi IP statici, verificare che il server DNS sia configurato correttamente. Per controllare l'indirizzo del server DNS dell'host, usare il comando seguente:

Get-NetIPConfiguration.DNSServer | ?{ $_.AddressFamily -ne 23} ).ServerAddresses

Verificare che l'indirizzo del server DNS corrisponda all'indirizzo usato durante l'esecuzione New-AksHciNetworkSetting eseguendo il comando seguente:

Get-MocConfig

Se il server DNS è stato configurato in modo non corretto, reinstallare il servizio Azure Kubernetes in Azure Stack HCI con il server DNS corretto. Per altre informazioni, vedere Riavviare, rimuovere o reinstallare servizio Azure Kubernetes in Azure Stack HCI .

Il problema è stato risolto dopo l'eliminazione della configurazione e il riavvio della macchina virtuale con una nuova configurazione.

Install-AksHci non riuscito con questo errore perché un altro processo accede a mocstack.cab.

Per risolvere questo problema, chiudere tutte le finestre di PowerShell aperte e quindi riaprire una nuova finestra di PowerShell.

Non è possibile accedere al file perché è in uso da un altro processo.

È possibile risolvere questo problema riavviando la sessione di PowerShell. Chiudere la finestra di PowerShell e provare di nuovo Install-AksHci.

Install-AksHci non riuscito con questo errore perché gli intervalli di pool IP forniti nel servizio Azure Kubernetes in Azure Stack HCI sono stati disattivati di 1 nel CIDR e possono causare l'arresto anomalo di CloudAgent. Se, ad esempio, si ha la subnet 10.0.0.0/21 con un intervallo di indirizzi 10.0.0.0 - 10.0.7.255 e si usa l'indirizzo iniziale 10.0.0.1 o l'indirizzo finale 10.0.7.254, si verifica un arresto anomalo di CloudAgent.

Per risolvere questo problema, eseguire New-AksHciNetworkSetting e usare qualsiasi altro intervallo di indirizzi IP valido per il pool di indirizzi VIP e il pool di nodi Kubernetes. Assicurarsi che i valori usati non siano disattivati di 1 all'inizio o alla fine dell'intervallo di indirizzi.

Quando si esegue Install-AksHci in un'installazione a nodo singolo, l'installazione ha funzionato, ma quando si configura il cluster di failover, l'installazione ha esito negativo e viene visualizzato il messaggio di errore. Tuttavia, il ping dell'agente cloud ha mostrato che CloudAgent è stato raggiungibile.

Per assicurarsi che tutti i nodi possano risolvere il DNS di CloudAgent, eseguire il comando seguente in ogni nodo:

Resolve-DnsName <FQDN of cloudagent>

Quando il passaggio precedente ha esito positivo sui nodi, assicurarsi che i nodi possano raggiungere la porta CloudAgent per verificare che un proxy non stia tentando di bloccare questa connessione e che la porta sia aperta. A tale scopo, eseguire il comando seguente in ogni nodo:

Test-NetConnection  <FQDN of cloudagent> -Port <Cloudagent port - default 65000>

L'errore deriva da un errore con download.

Se viene visualizzato questo errore, è consigliabile usare la versione più recente di Microsoft Edge o Google Chrome e riprovare.

Questo errore viene visualizzato dopo l'esecuzione di Set-AksHciRegistration in un servizio Azure Kubernetes nell'installazione di Azure Stack HCI. L'errore indica che i provider di risorse Kubernetes non sono registrati per il tenant attualmente connesso.

Per risolvere questo problema, eseguire l'interfaccia della riga di comando di Azure o i passaggi di PowerShell seguenti:

az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration

Register-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Register-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Il completamento della registrazione richiede circa 10 minuti. Per monitorare il processo di registrazione, usare i comandi seguenti.

az provider show -n Microsoft.Kubernetes -o table
az provider show -n Microsoft.KubernetesConfiguration -o table

Get-AzResourceProvider -ProviderNamespace Microsoft.Kubernetes
Get-AzResourceProvider -ProviderNamespace Microsoft.KubernetesConfiguration

Install-AksHci si blocca prima Waiting for azure-arc-onboarding to complete del timeout quando:

• Un'entità servizio viene usata nel servizio Azure Kubernetes nella registrazione di Azure Stack HCI (Set-AksHciRegistration).
• Az.Accounts PowerShell modules version(2.7.x) installed.Az.Accounts PowerShell modules version(2.7.x) installed.

Az.Accounts 2.7.xLe versioni rimuovono e CertificatePassword in PSAzureRmAccount, che viene usato dal servizio Azure Kubernetes in Azure Stack HCI per l'onboarding ServicePrincipalSecret di Azure Arc.

Per riprodurre:

1. Installare la Az.Accounts versione dei moduli di PowerShell (>= 2.7.0).
2. Set-AksHciRegistration uso di un'entità servizio.
3. Install-AksHci.

Comportamento previsto:

1. L'installazione del servizio Azure Kubernetes in Azure Stack HCI si blocca in Waiting for azure-arc-onboarding to complete.
2. Azure-arc-onboarding i pod entrano nel ciclo di arresto anomalo del sistema.
3. Errore Azure-arc-onboarding dei pod con l'errore seguente:
   Starting onboarding process ERROR: variable CLIENT_SECRET is required

Per risolvere il problema:

Disinstallare i moduli Az.Accounts con le versioni 2.7.x. eseguire il cmdlet seguente:

Uninstall-Module -Name Az.Accounts -RequiredVersion 2.7.0 -Force

Questo errore si verifica quando Azure Stack HCI non è conforme ai criteri. Lo stato della connessione nel cluster può mostrare che è connesso, ma il registro eventi mostra il messaggio di avviso che Azure Stack HCI's subscription is expired, run Sync-AzureStackHCI to renew the subscription.

Per risolvere questo errore, verificare che il cluster sia registrato in Azure usando il Get-AzureStackHCI cmdlet di PowerShell disponibile nel computer. Il dashboard di Windows Admin Center mostra anche le informazioni sullo stato relative alla registrazione di Azure del cluster.

Se il cluster è già registrato, è necessario visualizzare il campo LastConnected nell'output di Get-AzureStackHCI. Se il campo indica che cono passati più di 30 giorni, è consigliabile provare a risolvere la situazione usando il cmdlet Sync-AzureStackHCI.

È anche possibile verificare se ogni nodo del cluster dispone della licenza necessaria usando il cmdlet seguente:

Get-ClusterNode | % { Get-AzureStackHCISubscriptionStatus -ComputerName $_ }

Computer Name Subscription Name           Status   Valid To
------------- -----------------           ------   --------
MS-HCIv2-01   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-01   Windows Server Subscription Inactive

MS-HCIv2-02   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-02   Windows Server Subscription Inactive

MS-HCIv2-03   Azure Stack HCI             Active   12/23/2021 12:00:14 AM
MS-HCIv2-03   Windows Server Subscription Inactive

Se il problema non viene risolto dopo l'esecuzione del cmdlet, contattare il Sync-AzureStackHCI supporto tecnico Microsoft.

Questo problema si verifica perché un'installazione non riuscita potrebbe causare perdite di risorse che devono essere pulite prima di poter eseguire di nuovo l'installazione.

Se l'installazione non riesce usando Install-AksHci, è necessario eseguire Uninstall-AksHci prima di eseguire Install-AksHci di nuovo.

È possibile attivare questi errori quando si esegue Install-AksHci senza prima eseguire Set-AksHciConfig .

Per risolvere l'errore, eseguire uninstall-akshci e chiudere tutte le finestre di PowerShell. Aprire una nuova sessione di PowerShell e riavviare il processo di installazione del servizio Azure Kubernetes-HCI seguendo l'installazione di AKS-HCI con PowerShell.

Il Set-AksHciConfig cmdlet di PowerShell ha esito negativo e viene visualizzato l'errore:

GetCatalog error returned by API call: ... proxyconnect tcp: tls: first record does not look like a TLS Handshake

Se si usa il servizio Azure Kubernetes con un server proxy, è possibile che sia stato usato l'URL errato quando si imposta il valore dell'URL proxy HTTPS richiesto. I valori url proxy HTTP e URL proxy HTTPS sono entrambi necessari durante la configurazione del servizio Azure Kubernetes con un server proxy, ma è comune che entrambi i valori debbano condividere lo stesso URL con prefisso HTTP.

Se questo può essere il caso nell'ambiente in uso, provare a seguire questa procedura di mitigazione:

1. Chiudere la finestra di PowerShell e aprirne una nuova.
2. Eseguire di nuovo i New-AksHciNetworkSetting cmdlet e New-AksHciProxySetting . Quando si esegue New-AksHciProxySetting, impostare il -https parametro con lo stesso valore URL con prefisso HTTP impostato per -http.
3. Eseguire Set-AksHciConfig e continuare.

Quando si distribuisce il servizio Azure Kubernetes in Azure Stack HCI, la distribuzione può verificarsi in momenti diversi del processo a seconda della posizione in cui si è verificata la configurazione errata. È consigliabile esaminare il messaggio di errore per determinare la causa e dove si è verificato.

Ad esempio, nell'errore seguente, il punto in cui si è verificata la configurazione errata è in Get-DownloadSdkRelease -Name "mocstack-stable":

$vnet = New-AksHciNetworkSettingSet-AksHciConfig -vnet $vnetInstall-AksHciVERBOSE: 
Initializing environmentVERBOSE: [AksHci] Importing ConfigurationVERBOSE: 
[AksHci] Importing Configuration Completedpowershell : 
GetRelease - error returned by API call: 
Post "https://msk8s.api.cdp.microsoft.com/api/v1.1/contents/default/namespaces/default/names/mocstack-stable/versions/0.9.7.0/files?action=generateDownloadInfo&ForegroundPriority=True": 
dial tcp 52.184.220.11:443: connectex: 
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.At line:1 char:1+ powershell -command
{ Get-DownloadSdkRelease -Name "mocstack-stable"}

Ciò indica che il nodo fisico di Azure Stack HCI può risolvere il nome dell'URL di download, msk8s.api.cdp.microsoft.com, ma il nodo non può connettersi al server di destinazione.

Per risolvere questo problema, è necessario determinare dove si è verificata la suddivisione nel flusso di connessione. Ecco alcuni passaggi per provare a risolvere il problema dal nodo del cluster fisico:

1. Ping del nome DNS di destinazione: ping msk8s.api.cdp.microsoft.com.
2. Se si riceve una risposta e non si verifica alcun timeout, il percorso di rete di base funziona.
3. Se si verifica il timeout della connessione, potrebbe verificarsi un'interruzione nel percorso dati. Per altre informazioni, vedere Controllare le impostazioni proxy. In alternativa, potrebbe verificarsi un'interruzione nel percorso restituito, quindi è consigliabile controllare le regole del firewall.

Quando si esegue Set-AksHciConfig, è possibile che venga visualizzato l'errore seguente:

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Powershell remoting to TK5-3WP08R0733 was not successful.
At C:\Program Files\WindowsPowerShell\Modules\Moc\0.2.23\Moc.psm1:2957 char:17
+ ...             throw "Powershell remoting to "+$env:computername+" was n ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Powershell remo...not successful.:String) [], RuntimeException
    + FullyQualifiedErrorId : Powershell remoting to TK5-3WP08R0733 was not successful.

Questo errore si verifica in genere come conseguenza di una modifica nel token di sicurezza dell'utente (a causa di una modifica nell'appartenenza al gruppo), una modifica della password o una password scaduta. Nella maggior parte dei casi, è possibile risolvere il problema disconnettendosi dal computer ed eseguendo di nuovo l'accesso. Se l'errore persiste, è possibile segnalare un problema in Problemi di HCI del servizio Azure Kubernetes di GitHub.

Gli agenti Moc devono mantenere solo gli ultimi 100 log dell'agente. Dovrebbero eliminare i log meno recenti. Tuttavia, la rotazione del log non avviene e i log continuano a consumare spazio su disco accumulato.

Per riprodurre: Install AksHci e avere un cluster operativo fino a quando il numero di log dell'agente non supera 100. Al momento della creazione del n° log, gli agenti devono eliminare il log n-100th, se esistenti.

Per risolvere il problema:

1. Modificare i file logconf dell'agente cloud e degli agenti del nodo. L'agente cloud logconfig si trova in:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".
   Node Agent logconfig si trova in:
   (Get-MocConfig).cloudConfigLocation+"\log\logconf".

2. Modificare il valore di Limit su 100 e Slot in 100 e salvare i file di configurazione.

3. Riavviare l'agente cloud e gli agenti del nodo per registrare queste modifiche.

Questi passaggi avviano la rotazione del log solo dopo 100 nuovi log generati dal riavvio dell'agente. Se al riavvio sono già presenti n log agente, la rotazione dei log verrà avviata solo dopo la generazione di n+100 log.

Quando si usa Set-AksHciConfig per specificare -imageDirparametri , -workingDir, -cloudConfigLocationo -nodeConfigLocation con un nome di percorso contenente un carattere di spazio, ad esempio D:\Cloud Share\AKS HCI, il servizio cluster dell'agente cloud non inizierà con il messaggio di errore seguente (o simile):

Failed to start the cloud agent generic cluster service in failover cluster. The cluster resource group os in the 'failed' state. Resources in 'failed' or 'pending' states: 'MOC Cloud Agent Service'

Per risolvere questo problema, usare un percorso che non include spazi, C:\CloudShare\AKS-HCIad esempio .

Questo errore può verificarsi quando è presente un errore di configurazione dell'infrastruttura.

Seguire questa procedura per risolvere l'errore:

1. Controllare le impostazioni del server DNS host e del gateway:

   1. Verificare che il server DNS sia configurato correttamente. Per controllare l'indirizzo del server DNS dell'host, eseguire il comando seguente:

      ((Get-NetIPConfiguration).DNSServer | ?{ $_.AddressFamily -ne 23}).ServerAddresses
      

   2. Per verificare se l'indirizzo IP e la configurazione del gateway sono corretti, eseguire il comando ipconfig/all.
   3. Provare a effettuare il ping del gateway IP e del server DNS.

2. Controllare il servizio CloudAgent per assicurarsi che sia in esecuzione:

   1. Effettuare il ping del servizio CloudAgent per verificare che sia raggiungibile.
   2. Assicurarsi che tutti i nodi possano risolvere il DNS di CloudAgent eseguendo il comando seguente in ogni nodo:

      Resolve-DnsName <FQDN of cloudagent>
      

   3. Se il passaggio precedente ha esito positivo nei nodi, assicurarsi che i nodi possano raggiungere la porta di CloudAgent per verificare che un proxy non stia cercando di bloccare la connessione e che la porta sia aperta. A tale scopo, eseguire il comando seguente in ogni nodo:

      Test-NetConnection <FQDN of cloudagent> -Port <Cloudagent port - default 65000>
      

   4. Per verificare se il servizio cluster è in esecuzione per un cluster di failover, è anche possibile eseguire il comando seguente:

      Get-ClusterGroup -Name (Get-AksHciConfig).Moc['clusterRoleName']
      

Ciò indica in genere che l'oggetto CNO (Cluster Name Object) che rappresenta il cluster di failover sottostante in Dominio di Active Directory Services (AD DS) non dispone delle autorizzazioni per creare un oggetto computer virtuale (VCO) nell'unità organizzativa o nel contenitore in cui risiede il cluster.

Se non si è un amministratore di dominio, è possibile chiedere a uno di concedere le autorizzazioni CNO all'unità organizzativa o pre-installare un oggetto VCO per il servizio cluster generico dell'agente cloud.

Se si è un amministratore di dominio, è comunque possibile che l'unità organizzativa o il contenitore non disponga delle autorizzazioni necessarie. Ad esempio, la modalità di imposizione, introdotta in KB5008383, può essere abilitata in Active Directory. Provare quanto segue prima di tentare una reinstallazione.

1. Passare a Utenti e computer di Active Directory.
2. Fare clic con il pulsante destro del mouse sull'unità organizzativa o sul contenitore in cui risiede il cluster.
3. Selezionare Delega controllo per aprire la Delega guidata controllo.
4. Fare clic su Avanti> Fare clic su Aggiungi per aprire la finestra Seleziona utenti, computer o gruppi.
5. Selezionare la scelta di gruppi o utenti a cui si vuole delegare il controllo > Fare clic su OK.
6. Selezionare Crea un'attività personalizzata per delegare> Fare clic su Avanti per passare alla pagina Tipo di oggetto Active Directory.
7. Selezionare Solo gli oggetti seguenti nella cartella Seleziona oggetti> computer Selezionare Crea oggetti selezionati in questa cartella> ed Elimina oggetti selezionati in questa cartella> Fare clic su Avanti per passare alla pagina Autorizzazioni.
8. Selezionare Crea tutti gli oggetti figlio ed Elimina tutti gli oggetti figlio dall'elenco delle autorizzazioni > Fare clic su Fine successiva>

Se una reinstallazione ha esito negativo, riprovare con le modifiche seguenti in Passaggi 7 e 8:

• Passaggio 7: selezionare Questa cartella, gli oggetti esistenti in questa cartella e la creazione di nuovi oggetti in questa cartella> Fare clic su Avanti.
• Passaggio 8: Selezionare Lettura, Scrittura, Crea tutti gli oggetti figlio ed Elimina tutti gli oggetti figlio dall'elenco delle autorizzazioni > Fare clic su Fine>.

Questo errore può essere visualizzato durante l'esecuzione di Install-AksHci.

Per ottenere altre informazioni, eseguire $error = Install-AksHci e quindi $error[0].Exception.InnerException.

I comandi di PowerShell Aks-Hci non convalidano la memoria disponibile nel server host prima di creare nodi Kubernetes. Questo problema può causare l'esaurimento della memoria e le macchine virtuali che non vengono avviate. Questo errore non viene attualmente gestito correttamente e la distribuzione smetterà di rispondere senza un messaggio di errore chiaro.

Se si dispone di una distribuzione che smette di rispondere, aprire Visualizzatore eventi e verificare la presenza di un messaggio di errore correlato a Hyper-V che indica che la memoria non è sufficiente per avviare la macchina virtuale.

Questo errore può verificarsi quando sono presenti più tenant nell'account Azure.

Usare $tenantId = (Get-AzContext).Tenant.Id per impostare il tenant corretto. Includere quindi questo tenant come parametro durante l'esecuzione di Set-AksHciRegistration.

Quando si tenta di distribuire un cluster del servizio Azure Kubernetes in una macchina virtuale di Azure, l'installazione è stata bloccata in Waiting for pod 'Cloud Operator' to be ready...e quindi non è riuscita e si è verificato un timeout dopo due ore. I tentativi di risoluzione dei problemi controllando il gateway e il server DNS hanno mostrato che funzionavano in modo appropriato. Non sono stati rilevati conflitti di indirizzi IP o MAC. I log non visualizzano il pool VIP. Esiste una restrizione sul pull dell'immagine del contenitore usando sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 che ha restituito un timeout tls (Transport Layer Security) anziché non autorizzato.

Per risolvere questo problema, seguire questa procedura:

1. Iniziare a distribuire il cluster.
2. Quando il cluster viene distribuito, connettersi alla macchina virtuale del cluster di gestione tramite SSH, come illustrato di seguito:

ssh -i (Get-MocConfig)['sshPrivateKey'] clouduser@<IP Address>

3. Modificare l'impostazione massima dell'unità di trasmissione (MTU). Non esitare a apportare la modifica; se si apporta la modifica troppo tardi, la distribuzione non riesce. La modifica dell'impostazione MTU consente di sbloccare il pull dell'immagine del contenitore.

sudo ifconfig eth0 mtu 1300

4. Per visualizzare lo stato dei contenitori, eseguire il comando seguente:

sudo docker ps -a

Dopo aver eseguito questi passaggi, il pull dell'immagine del contenitore deve essere sbloccato.

Questo errore indica che l'indirizzo IP del servizio cloud non fa parte della rete del cluster e non corrisponde ad alcuna delle reti del cluster con il client and cluster communication ruolo abilitato.

Per risolvere questo problema, eseguire Get-ClusterNetwork dove Role è uguale a ClusterAndClient. Quindi, in uno dei nodi del cluster selezionare il nome, l'indirizzo e la maschera di indirizzo per verificare che l'indirizzo IP fornito per il -cloudServiceIP parametro New-AksHciNetworkSetting corrisponda a una delle reti visualizzate.

Enable-AksHciArcConnection può connettere un cluster del servizio Azure Kubernetes ad Azure, ma mostra l'avviso seguente quando il cliente usa un'entità servizio per l'autenticazione:

WARNING: Error occurred while executing GetServicePrincipals
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
RequestId: <removed>
DateTimeStamp: <removed>
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
WARNING: Custom locations has not been enabled on the AKS-HCI cluster. To enable custom locations manually, visit aka.ms/enable-custom-location

Il comportamento corrente dell'onboarding di Arc consiste nell'abilitare le posizioni personalizzate per impostazione predefinita. Per abilitare percorsi personalizzati, l'azione GetServicePrincipals viene eseguita nel contesto dell'utente di Azure connesso. Se l'utente (o SPN) non dispone di autorizzazioni sufficienti per eseguire questa operazione, il comando genera un avviso che indica che queste autorizzazioni non esistono e pertanto la funzionalità Percorsi personalizzati non verrà abilitata.

Se non si vuole abilitare percorsi personalizzati, è possibile ignorare questo avviso in modo sicuro, perché questo non influisce sull'onboarding del cluster in Arc. D'altra parte, se è necessario abilitare percorsi personalizzati, è necessario concedere le autorizzazioni necessarie all'utente (o al nome SPN).

Passaggi successivi

• Panoramica della risoluzione dei problemi
• Problemi noti di Windows Admin Center
• Risoluzione dei problemi relativi ai cluster Kubernetes

Se si continuano a verificarsi problemi quando si usa Il servizio Azure Kubernetes Arc, è possibile segnalare bug tramite GitHub.