Risolvere i problemi di gestione e cluster del carico di lavoro di Kubernetes in Azure Kubernetes Arc

Quando si esegue il comando Remove-ClusterNode , il nodo viene rimosso dal cluster di failover, ma se Remove-AksHciNode non viene eseguito successivamente, il nodo continuerà a esistere in CloudAgent.

Poiché il nodo è stato rimosso dal cluster, ma non da CloudAgent, se si usa il disco rigido virtuale per creare un nuovo nodo, viene visualizzato un errore "File non trovato". Questo problema si verifica perché il disco rigido virtuale si trova nell'archiviazione condivisa e il nodo rimosso non ha accesso.

Per risolvere questo problema, rimuovere un nodo fisico dal cluster e quindi seguire questa procedura:

1. Eseguire Remove-AksHciNode per annullare la registrazione del nodo da CloudAgent.
2. Eseguire la manutenzione di routine, ad esempio la ricreazione dell'immagine della macchina.
3. Aggiungere di nuovo il nodo al cluster.
4. Eseguire Add-AksHciNode per registrare il nodo con CloudAgent.

Con cluster di grandi dimensioni, il Get-AksHciLogs comando può generare un'eccezione, non enumerare i nodi o generare il file di output c:\wssd\wssdlogs.zip.

Questo perché il comando di PowerShell per comprimere un file, "Compress-Archive", ha un limite di dimensioni del file di output di 2 GB.

Dopo l'aggiornamento o la scalabilità verticale del cluster del carico di lavoro, il pod di rinnovo del certificato si trova ora in uno stato di ciclo di arresto anomalo perché il pod prevede il file YAML tatuaggio del certificato dal percorso /etc/Kubernetes/pkidel file .

Questo problema può essere dovuto a un file di configurazione presente nelle macchine virtuali del piano di controllo, ma non nelle macchine virtuali del nodo di lavoro.

Per risolvere questo problema, copiare manualmente il file YAML del tatuaggio del certificato dal nodo del piano di controllo a tutti i nodi di lavoro.

1. Copiare il file YAML dalla macchina virtuale del piano di controllo nel cluster del carico di lavoro nella directory corrente del computer host:

ssh clouduser@<comtrol-plane-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp /etc/kubernetes/pki/cert-tattoo-kubelet.yaml ~/
sudo chown clouduser cert-tattoo-kubelet.yaml
sudo chgrp clouduser cert-tattoo-kubelet.yaml
(Change file permissions here, so that `scp` will work)
scp -i (get-mocconfig).sshprivatekey clouduser@<comtrol-plane-vm-ip>:~/cert*.yaml .\

1. Copiare il file YAML dal computer host alla macchina virtuale del nodo di lavoro. Prima di copiare il file, è necessario modificare il nome del computer nel file YAML con il nome del nodo in cui si sta copiando (si tratta del nome del nodo per il piano di controllo del cluster del carico di lavoro).

scp -i (get-mocconfig).sshprivatekey .\cert-tattoo-kubelet.yaml clouduser@<workernode-vm-ip>:~/cert-tattoo-kubelet.yaml

3. Se le informazioni sul proprietario e sul gruppo nel file YAML non sono già impostate su root, impostare le informazioni sulla radice:

ssh clouduser@<workernode-vm-ip> -i (get-mocconfig).sshprivatekey
sudo cp ~/cert-tattoo-kubelet.yaml /etc/kubernetes/pki/cert-tattoo-kubelet.yaml (copies the certificate file to the correct location)
sudo chown root cert-tattoo-kubelet.yaml
sudo chgrp root cert-tattoo-kubelet.yaml

4. Ripetere i passaggi 2 e 3 per tutti i nodi di lavoro.

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.

Quando si esegue Get-AksHciCluster per verificare lo stato di un'installazione di Arc del servizio Azure Kubernetes in Windows Admin Center, l'output visualizza un errore: "Non è stata trovata una versione con la versione 1.0.3.10818". Tuttavia, quando si esegue Get-AksHciVersion, è stata installata la stessa versione. Questo errore indica che la compilazione è scaduta.

Per risolvere questo problema, eseguire Uninstall-AksHcie quindi eseguire una nuova build di Arc del servizio Azure Kubernetes.

Quando si usa lo strumento di amministrazione del cluster per spostare una macchina virtuale da un nodo (nodo A) a un altro nodo (nodo B) nel cluster locale di Azure, è possibile che la macchina virtuale non venga avviata nel nuovo nodo. Dopo aver spostato nuovamente la macchina virtuale nel nodo originale, l'avvio avrà esito negativo.

Questo problema si verifica perché la logica per pulire la prima migrazione viene eseguita in modo asincrono. Di conseguenza, la logica di "aggiornamento della posizione della macchina virtuale" di servizio Azure Kubernetes trova la macchina virtuale nel nodo A originale e la elimina, anziché annullarla la registrazione.

Per risolvere questo problema, assicurarsi che la macchina virtuale sia stata avviata correttamente nel nuovo nodo prima di tornare al nodo originale.

Quando si usa PowerShell per creare un cluster con indirizzi IP statici e quindi si tenta di aumentare il numero di nodi di lavoro nel cluster del carico di lavoro, l'installazione viene bloccata al "conteggio del piano di controllo a 2, ancora in attesa dello stato desiderato: 3". Dopo un periodo di tempo, viene visualizzato un altro messaggio di errore: "Errore: timeout in attesa della condizione".

Quando Get-AksHciCluster è stato eseguito, è stato mostrato che i nodi del piano di controllo sono stati creati e di cui è stato effettuato il provisioning ed erano in uno stato Ready . Tuttavia, quando kubectl get nodes è stata eseguita, ha mostrato che i nodi del piano di controllo erano stati creati ma non sottoposti a provisioning e non erano in uno stato Pronto .

Se viene visualizzato questo errore, verificare che gli indirizzi IP siano stati assegnati ai nodi creati usando la console di gestione di Hyper-V o PowerShell:

(Get-VM |Get-VMNetworkAdapter).IPAddresses |fl

Verificare quindi le impostazioni di rete per assicurarsi che nel pool siano rimasti sufficienti indirizzi IP per creare altre macchine virtuali.

I comandi, Update-AksHciad esempio , Update-AksHciClusterCertificatesUpdate-AksHciCertificates, e tutte le interazioni con il cluster di gestione, possono restituire "Errore: è necessario eseguire l'accesso al server (Non autorizzato)."

Questo errore può verificarsi quando il file kubeconfig è scaduto. Per verificare se è scaduto, eseguire lo script seguente:

$kubeconfig= $(get-kvaconfig).kubeconfig
$certDataRegex = '(?ms).*client-certificate-data:\s*(?<CertData>[^\n\r]+)'
$certDataMatch = Select-String -Path $kubeconfig -Pattern $certDataRegex
$certData = $certDataMatch.Matches[0].Groups['CertData'].Value
$certObject = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$certObject.Import([System.Convert]::FromBase64String($certData))
$expiryDate = $certObject.GetExpirationDateString()
$expiryDate

Se questo script visualizza una data precedente alla data corrente, il file kubeconfig è scaduto.

Per attenuare il problema, copiare il file admin.conf , che si trova all'interno della macchina virtuale del piano di controllo di gestione, nell'host locale di Azure:

• Connettersi tramite SSH alla macchina virtuale del piano di controllo di gestione:

  • Ottenere l'indirizzo IP della macchina virtuale del piano di controllo di gestione:

    get-clusternode | % {Get-vm -computerName $_ } | get-vmnetworkadapter | select Name, IPAddresses
    

  • Ssh in esso:

    ssh -o StrictHostKeyChecking=no -i (Get-MocConfig).sshPrivateKey clouduser@<mgmt-control-plane-ip>
    

• Copiare il file nel percorso clouduser :

  cp /etc/kubernetes/admin.conf /home/clouduser/admin.conf
  

• Concedere l'accesso a clouduser:

  sudo chown clouduser:clouduser admin.conf
  

• [Facoltativo] Creare un backup del file kubeconfig :

  mv $(Get-KvaConfig).kubeconfig "$((Get-KvaConfig).kubeconfig).backup"
  

• Copiare il file:

  scp -i (get-mocconfig).sshPrivateKey clouduser@10.64.92.14:~/admin.conf $(Get-KvaConfig).kubeconfig
  

Quando si controlla la gestione di Hyper-V, è possibile ignorare in modo sicuro le richieste di CPU e memoria elevate per il cluster di gestione. Sono correlati ai picchi di utilizzo delle risorse di calcolo durante il provisioning dei cluster del carico di lavoro.

L'aumento delle dimensioni della memoria o della CPU per il cluster di gestione non ha mostrato un miglioramento significativo e può essere ignorato in modo sicuro.

Questo problema verrà visualizzato se si seguono questi passaggi:

1. Crea un cluster Kubernetes.
2. Ridimensionare il cluster in più di due nodi.
3. Eliminare un nodo eseguendo il comando seguente:

kubectl delete node <node-name>

4. Restituire un elenco dei nodi eseguendo il comando seguente:

kubectl get nodes

Il nodo rimosso non è elencato nell'output. 5. Aprire una finestra di PowerShell con privilegi amministrativi ed eseguire il comando seguente:

get-vm

Il nodo rimosso è ancora elencato.

Questo errore fa sì che il sistema non riconosca che il nodo è mancante e pertanto un nuovo nodo non verrà attivato.

Se non si usa un cluster di gestione o carico di lavoro per più di 60 giorni, i certificati scadono ed è necessario rinnovarli prima di poter aggiornare Il servizio Azure Kubernetes Arc. Quando un cluster del servizio Azure Kubernetes non viene aggiornato entro 60 giorni, il token del plug-in del Servizio di gestione delle chiavi e i certificati scadono entro 60 giorni. Il cluster è ancora funzionante. Tuttavia, poiché supera i 60 giorni, è necessario chiamare il supporto tecnico Microsoft per eseguire l'aggiornamento. Se il cluster viene riavviato dopo questo periodo, rimarrà in uno stato non funzionale.

Per risolvere questo problema, eseguire la procedura seguente:

1. Ripristinare il certificato del cluster di gestione ruotando manualmente il token e quindi riavviare il plug-in e il contenitore del Servizio di gestione delle chiavi.
2. Ripristinare i mocctl certificati eseguendo Repair-MocLogin.
3. Ripristinare i certificati del cluster del carico di lavoro ruotando manualmente il token e quindi riavviare il plug-in e il contenitore del Servizio di gestione delle chiavi.

Il cluster del carico di lavoro potrebbe non essere trovato se i pool di indirizzi IP di due servizio Azure Kubernetes nelle distribuzioni locali di Azure sono uguali o sovrapposti. Se si distribuiscono due host del servizio Azure Kubernetes e si usa la stessa AksHciNetworkSetting configurazione per entrambi, PowerShell e Windows Admin Center potrebbero non riuscire a trovare il cluster del carico di lavoro perché al server API verrà assegnato lo stesso indirizzo IP in entrambi i cluster, causando un conflitto.

Il messaggio di errore visualizzato sarà simile all'esempio illustrato di seguito.

A workload cluster with the name 'clustergroup-management' was not found.
At C:\Program Files\WindowsPowerShell\Modules\Kva\0.2.23\Common.psm1:3083 char:9
+         throw $("A workload cluster with the name '$Name' was not fou ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (A workload clus... was not found.:String) [], RuntimeException
    + FullyQualifiedErrorId : A workload cluster with the name 'clustergroup-management' was not found.

La distribuzione di un cluster di grandi dimensioni può scadere dopo due ore. Tuttavia, si tratta di un timeout statico.

È possibile ignorare questa occorrenza di timeout perché l'operazione è in esecuzione in background. Usare il kubectl get nodes comando per accedere al cluster e monitorare lo stato di avanzamento.

Quando si tenta di visualizzare un servizio Azure Kubernetes nella distribuzione locale di Azure dopo alcuni giorni, Kubectl non è stato eseguito alcun comando. Il log del plug-in Servizio di gestione delle chiavi (KMS) visualizza il messaggio rpc error:code = Unauthenticated desc = Valid Token Required_. After running [Repair-AksHciCerts](./reference/ps/repair-akshcicerts.md) to try to fix the issue, a different error appeared: _failed to repair cluster certificatesdi errore .

Il cmdlet Repair-AksHciClusterCerts ha esito negativo se il server API è inattivo. Se il servizio Azure Kubernetes in Locale di Azure non è stato aggiornato per 60 o più giorni, quando si tenta di riavviare il plug-in del Servizio di gestione delle chiavi, non verrà avviato. Questo errore causa anche l'esito negativo del server API.

Per risolvere questo problema, è necessario ruotare manualmente il token e quindi riavviare il plug-in e il contenitore del Servizio di gestione delle chiavi per ottenere il backup del server API. A tale scopo, procedere come segue:

1. Ruotare il token eseguendo il comando seguente:

   $ mocctl.exe security identity rotate --name "KMSPlugin-<cluster-name>-moc-kms-plugin" --encode=false --cloudFqdn (Get-AksHciConfig).Moc.cloudfqdn > cloudlogin.yaml
   

2. Copiare il token nella macchina virtuale usando il comando seguente. L'impostazione ip nel comando seguente fa riferimento all'indirizzo IP del piano di controllo dell'host del servizio Azure Kubernetes.

   $ scp -i (Get-AksHciConfig).Moc.sshPrivateKey .\cloudlogin.yaml clouduser@<ip>:~/cloudlogin.yaml $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> sudo mv cloudlogin.yaml /opt/wssd/k8s/cloudlogin.yaml
   

3. Riavviare il plug-in del Servizio di gestione delle chiavi e il contenitore.

   Per ottenere l'ID contenitore, eseguire il comando seguente:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container ls | grep 'kms'"
   

   L'output dovrebbe essere visualizzato con i campi seguenti:

   CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
   

   L'output dovrebbe essere simile all'esempio seguente:

   4169c10c9712 f111078dbbe1 "/kms-plugin" 22 minutes ago Up 22 minutes k8s_kms-plugin_kms-plugin-moc-lll6bm1plaa_kube-system_d4544572743e024431874e6ba7a9203b_1
   

4. Infine, riavviare il contenitore eseguendo il comando seguente:

   $ ssh -i (Get-AksHciConfig).Moc.sshPrivateKey clouduser@<ip> "sudo docker container kill <Container ID>"
   

In un servizio Azure Kubernetes nell'installazione locale di Azure con l'estensione Windows Admin Center versione 1.82.0, il cluster di gestione è stato configurato con PowerShell e si è tentato di distribuire un cluster del carico di lavoro usando Windows Admin Center. Uno dei computer aveva installato il modulo PowerShell versione 1.0.2 e altri computer avevano installato il modulo PowerShell 1.1.3. Tentativo di distribuzione del cluster del carico di lavoro non riuscito con l'errore "Impossibile trovare un parametro che corrisponde al nome del parametro 'nodePoolName'". Questo errore potrebbe essersi verificato a causa di una mancata corrispondenza della versione. A partire da PowerShell versione 1.1.0, il -nodePoolName <String> parametro è stato aggiunto al cmdlet New-AksHciCluster e, per impostazione predefinita, questo parametro è ora obbligatorio quando si usa l'estensione di Windows Admin Center versione 1.82.0.

Per risolvere il problema, eseguire una delle operazioni seguenti:

• Usare PowerShell per aggiornare manualmente il cluster del carico di lavoro alla versione 1.1.0 o successiva.
• Usare Windows Admin Center per aggiornare il cluster alla versione 1.1.0 o alla versione più recente di PowerShell.

Questo problema non si verifica se il cluster di gestione viene distribuito tramite Windows Admin Center perché ha già installato i moduli di PowerShell più recenti.

Quando si distribuisce il servizio Azure Kubernetes in Locale di Azure e quindi si esegue kubectl get pods, i pod nello stesso nodo sono bloccati nello stato terminazione . Il computer rifiuta le connessioni SSH perché è probabile che il nodo stia riscontrando una domanda di memoria elevata. Questo problema si verifica perché viene eseguito il provisioning eccessivo dei nodi Windows e non è disponibile alcuna riserva per i componenti principali.

Per evitare questa situazione, aggiungere i limiti delle risorse e le richieste di risorse per CPU e memoria alla specifica del pod per assicurarsi che non venga eseguito il provisioning eccessivo dei nodi. I nodi Windows non supportano la rimozione in base ai limiti delle risorse, quindi è consigliabile stimare la quantità di contenitori usata e quindi assicurarsi che i nodi abbiano quantità di CPU e memoria sufficienti. Altre informazioni sono disponibili nei requisiti di sistema.

Il ridimensionamento automatico del cluster può non riuscire quando si usano i criteri di Azure seguenti nel cluster di gestione host del servizio Azure Kubernetes: "I cluster Kubernetes non devono usare lo spazio dei nomi predefinito". Ciò si verifica perché i criteri, se implementati nel cluster di gestione host del servizio Azure Kubernetes, bloccano la creazione di profili di scalabilità automatica nello spazio dei nomi predefinito. Per risolvere il problema, scegliere una delle opzioni seguenti:

• Disinstallare l'estensione Criteri di Azure nel cluster di gestione host del servizio Azure Kubernetes. Altre informazioni sulla disinstallazione delle estensioni Criteri di Azure sono disponibili qui.
• Modificare l'ambito dei criteri di Azure per escludere i cluster di gestione host del servizio Azure Kubernetes. Altre informazioni sugli ambiti di Criteri di Azure sono disponibili qui.
• Impostare la modalità di imposizione dei criteri su "Disabilitato" per il cluster di gestione host del servizio Azure Kubernetes. Altre informazioni sulla modalità di imposizione sono disponibili qui.

Si tratta di un problema noto con il servizio Azure Kubernetes nell'aggiornamento locale di luglio di Azure (versione 1.0.2.10723). L'errore si verifica perché il servizio CloudAgent scade durante la distribuzione di macchine virtuali tra più volumi condivisi del cluster nel sistema.

Per risolvere questo problema, è necessario eseguire l'aggiornamento alla versione più recente del servizio Azure Kubernetes nella versione locale di Azure.

Se si effettua il provisioning di un cluster del servizio Azure Kubernetes in Locale di Azure con zero nodi Linux o Windows, quando si esegue Get-AksHciCluster, l'output sarà una stringa vuota o un valore Null.

Null è un risultato previsto per zero nodi.

Quando si arresta un cluster di gestione o carico di lavoro per più di quattro giorni, i certificati scadono e il cluster non è raggiungibile. I certificati scadono perché vengono ruotati ogni 3-4 giorni per motivi di sicurezza.

Per riavviare il cluster, è necessario ripristinare manualmente i certificati prima di poter eseguire qualsiasi operazione del cluster. Per ripristinare i certificati, eseguire il comando Repair-AksHciClusterCerts seguente:

Repair-AksHciClusterCerts -Name <cluster-name> -fixKubeletCredentials

Quando si aumenta il numero di istanze di un cluster del carico di lavoro, le macchine virtuali Linux e Windows corrispondenti sono state aggiunte come nodi di lavoro, ma non sono state configurate come macchine virtuali a disponibilità elevata. Quando si esegue il comando Get-ClusterGroup , la macchina virtuale Linux appena creata non è stata configurata come gruppo di cluster.

Questo è un problema noto. Dopo un riavvio, la possibilità di configurare le macchine virtuali a disponibilità elevata a volte viene persa. La soluzione alternativa corrente consiste nel riavviare wssdagent in ognuno dei nodi locali di Azure. Questa operazione funziona solo per le nuove macchine virtuali generate creando pool di nodi quando si esegue un'operazione di scalabilità orizzontale o quando si creano nuovi cluster Kubernetes dopo il riavvio wssdagent di nei nodi. Tuttavia, sarà necessario aggiungere manualmente le macchine virtuali esistenti al cluster di failover.

Quando si aumenta il numero di istanze di un cluster, le risorse del cluster a disponibilità elevata sono in uno stato di errore mentre le macchine virtuali vengono rimosse. La soluzione alternativa per questo problema consiste nel rimuovere manualmente le risorse non riuscite.

Un cluster del servizio Azure Kubernetes distribuito in una macchina virtuale di Azure funzionava in precedenza, ma dopo che l'host del servizio Azure Kubernetes è stato disattivato per diversi giorni, il Kubectl comando non funzionava. Dopo l'esecuzione del Kubectl get nodes comando o Kubectl get services , viene visualizzato questo messaggio di errore: Error from server (InternalError): an error on the server ("") has prevented the request from succeeding.

Questo problema si è verificato perché l'host del servizio Azure Kubernetes è stato disattivato per più di quattro giorni, causando la scadenza dei certificati. I certificati vengono spesso ruotati in un ciclo di quattro giorni. Eseguire Repair-AksHciClusterCerts per risolvere il problema di scadenza del certificato.

In un cluster del carico di lavoro con indirizzi IP statici e nodi Windows, tutti i pod in un nodo (inclusi i daemonset pod) sono bloccati in uno stato ContainerCreating . Quando si tenta di connettersi a tale nodo tramite SSH, la connessione non riesce con un Connection timed out errore.

Per risolvere questo problema, usare La console di gestione di Hyper-V o Gestione cluster di failover per disattivare la macchina virtuale di tale nodo. Dopo 5-10 minuti, il nodo dovrebbe essere stato ricreato, con tutti i pod in esecuzione.

Quando kubelet è sotto pressione su disco, raccoglie immagini del contenitore inutilizzate, che possono includere immagini in pausa e, quando ciò accade, ContainerD non può eseguire il pull dell'immagine.

Per risolvere questo problema, eseguire la procedura seguente:

1. Connettersi al nodo interessato usando SSH ed eseguire il comando seguente:

sudo su

2. Per eseguire il pull dell'immagine, eseguire il comando seguente:

crictl pull ecpacr.azurecr.io/kube-proxy:<Kubernetes version>

Passaggi successivi

• Panoramica della risoluzione dei problemi
• Problemi di rete ed errori
• problemi noti relativi all'archiviazione