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 Install-AksHcidi .
3. Controllare 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 del 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 tentare 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 eseguendo 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, potrebbe essere visualizzato:

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 ha esito negativo con "Errore GetRelease restituito dalla chiamata API: Errore di download file: Errore di mancata corrispondenza dell'hash".

1. Aprire PowerShell ed eseguire Uninstall-AksHci.
2. Riprovare a 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 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 HCI di Azure Stack, il report del servizio Azure Kubernetes ha mostrato uno stato non riuscito 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 aver eseguito Install-AksHci, l'installazione è stata arrestata e ha 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 più motivi per cui un'installazione potrebbe non riuscire con l'errore waiting for API server .

La sezione seguente illustra possibili cause e soluzioni per questo errore.

Motivo 1: Configurazione del gateway IP non corretta Se si usano indirizzi IP statici e si è ricevuto 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 tentare di 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 non corretto 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 sia uguale all'indirizzo usato durante l'esecuzione New-AksHciNetworkSetting eseguendo il comando seguente:

Get-MocConfig

Se il server DNS è stato configurato correttamente, 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 errore non riuscito 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 riprovare a Install-AksHci.

Install-AksHci errore non riuscito perché gli intervalli di pool IP forniti nel servizio Azure Kubernetes in Azure Stack HCI sono stati disattivati da 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 VIP e il pool di nodi Kubernetes. Assicurarsi che i valori usati non siano disattivati da 1 all'inizio o alla fine dell'intervallo di indirizzi.

Quando si esegue Install-AksHci in una configurazione a nodo singolo, l'installazione ha funzionato, ma quando si configura il cluster di failover, l'installazione ha esito negativo con 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 il 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 vengono 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

La registrazione richiede circa 10 minuti per completare. 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 in Azure Stack HCI Registration (Set-AksHciRegistration).
• Az.Accounts PowerShell modules version(2.7.x) installato.

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

Per riprodurre:

1. Installare Az.Accounts la 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 passano al ciclo di arresto anomalo.
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 con 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 ha la 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, è necessario contattare il Sync-AzureStackHCI supporto Microsoft.

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

Se l'installazione ha esito negativo usando Install-AksHci, è necessario eseguire Disinstalla-AksHci prima di eseguire Install-AksHci di nuovo.

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

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 del servizio Azure Kubernetes-HCI con PowerShell.

Il Set-AksHciConfig cmdlet di PowerShell non riesce con 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, potrebbe essere 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 siano necessari per condividere lo stesso URL con prefisso HTTP.

Se questo potrebbe essere il caso nell'ambiente, provare i passaggi di mitigazione seguenti:

1. Chiudere la finestra di PowerShell e aprire 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 procedere.

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

Nell'errore seguente, ad esempio, il punto in cui si è verificato l'errore di configurazione è 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 HCI fisico di Azure Stack può risolvere il nome dell'URL di download, , msk8s.api.cdp.microsoft.comma 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 il nome DNS di destinazione: ping msk8s.api.cdp.microsoft.com.
2. Se viene restituita una risposta e non viene eseguito alcun timeout, il percorso di rete di base funziona.
3. Se la connessione viene interrotta, potrebbe verificarsi un'interruzione nel percorso dei 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, potrebbe verificarsi 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 non riesce, è possibile segnalare un problema in GitHub AKS HCI problemi.

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 usare spazio su disco accumulato.

Per riprodurre: Install AksHci e avere un cluster in esecuzione fino a quando il numero di log dell'agente supera 100. Al momento della creazione nth log, gli agenti devono eliminare il log n-100th, se presenti.

Per risolvere il problema:

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

2. Modificare il valore limite a 100 e slot su 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 sono già presenti n log agente al momento del riavvio, la rotazione del log verrà avviata solo dopo la generazione di n+100 log.

Quando si usa Set-AksHciConfig per specificare -imageDir, , -workingDir-cloudConfigLocationo -nodeConfigLocation parametri 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, ad esempio C:\CloudShare\AKS-HCI.

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

Seguire questa procedura per risolvere l'errore:

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

   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 controllare se il servizio cluster è in esecuzione per un cluster di failover, è anche possibile eseguire il comando seguente:

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

Questo indica in genere che l'oggetto Nome cluster (CNO) che rappresenta il cluster di failover sottostante in Active Directory Domain 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-pre-assegnare un 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 provare a reinstallare.

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 Controllo delegato per aprire la Delega guidata controllo.
4. Fare clic su Avanti> 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 e Elimina oggetti selezionati in questa cartella> Fare clic su Avanti per passare alla pagina Autorizzazioni.
8. Selezionare Crea tutti gli oggetti figlio ed eliminare tutti gli oggetti figlio dall'elenco delle autorizzazioni > Fare clic su Fine successiva>

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

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

È possibile che venga visualizzato questo errore durante l'esecuzione di Install-AksHci.

È possibile ottenere altre informazioni eseguendo $error = Install-AksHci e quindi $error[0].Exception.InnerException.

I comandi Aks-Hci PowerShell 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 è bloccata in Waiting for pod 'Cloud Operator' to be ready...e quindi ha avuto esito negativo e si è verificato il 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 per il pull dell'immagine del contenitore che sudo docker pull ecpacr.azurecr.io/kube-vip:0.3.4 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 ha esito negativo. 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. In uno dei nodi del cluster selezionare quindi il nome, l'indirizzo e la maschera di indirizzo per verificare che l'indirizzo IP specificato per il -cloudServiceIP parametro New-AksHciNetworkSetting corrisponda a una delle reti visualizzate.

Passaggi successivi

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

Se si continuano a verificarsi problemi quando si usa AKS Arc, è possibile segnalare bug tramite GitHub.