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

Quando si esegue il comando Remove-ClusterNode , il nodo viene rimosso dal cluster di failover, ma se Remove-AksHciNode non viene eseguito in seguito, il nodo esiste ancora 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 registrare il nodo da CloudAgent.
2. Eseguire la manutenzione di routine, ad esempio ri-imaging della macchina.
3. Aggiungere nuovamente il nodo nel 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 non genererà 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 pari a 2 GB.

Dopo aver aggiornato o ridimensionato il cluster del carico di lavoro, il pod di rinnovo del certificato è ora in stato di arresto anomalo perché il pod prevede il file YAML del 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 nel 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 radice, 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 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 iniziano.

Questo errore non è attualmente gestito correttamente e la distribuzione smetterà di rispondere senza messaggi di errore chiari. 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 non è presente memoria sufficiente per avviare la macchina virtuale.

Quando si esegue Get-AksHciCluster per verificare lo stato di un'installazione di AKS Arc in Windows Admin Center, l'output mostra un errore: "Una versione con la versione 1.0.3.10818 non è stata TROVATA". Tuttavia, quando si esegue Get-AksHciVersion, è stata installata la stessa versione. Questo errore indica che la compilazione è scaduta.

Per risolvere questo problema, eseguire e quindi eseguire Uninstall-AksHciuna 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 Azure Stack HCI, la macchina virtuale potrebbe non riuscire ad avviare nel nuovo nodo. Dopo aver spostato nuovamente la macchina virtuale nel nodo originale, non verrà avviata anche lì.

Questo problema si verifica perché la logica per pulire la prima migrazione viene eseguita in modo asincrono. Di conseguenza, servizio Azure Kubernetes la logica "aggiorna percorso macchina virtuale" trova la macchina virtuale nel nodo Hyper-V originale e la elimina, anziché annullare 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 tentare 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, ha mostrato che i nodi del piano di controllo sono stati creati e sottoposti a provisioning e sono stati in uno stato Pronto . Tuttavia, quando kubectl get nodes è stata eseguita, è stato 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 Hyper-V Manager o PowerShell:

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

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

I comandi, Update-AksHciad esempio , Update-AksHciCertificates, Update-AksHciClusterCertificatese 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 HCI:

• 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 al 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 gestione 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 della memoria o delle dimensioni 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. Creare 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 determina che il sistema non riconosce che il nodo non è mancante e quindi un nuovo nodo non verrà generato.

Se non si usa un cluster di gestione o carico di lavoro per più di 60 giorni, i certificati scadono e è necessario rinnovarli prima di poter aggiornare AKS Arc. Quando un cluster del servizio Azure Kubernetes non viene aggiornato entro 60 giorni, il token plug-in del Servizio di gestione delle chiavi e i certificati scadono entro 60 giorni. Il cluster è ancora funzionale. Tuttavia, poiché è oltre 60 giorni, è necessario chiamare il supporto Tecnico Microsoft per 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 HCI di Azure Stack sono uguali o sovrapposti. Se si distribuiscono due host del servizio Azure Kubernetes e si usa la stessa configurazione per entrambi, PowerShell e Windows Admin Center potrebbero non riuscire a trovare il cluster del carico di lavoro come server API verrà assegnato lo stesso AksHciNetworkSetting indirizzo IP in entrambi i cluster che causano un conflitto.

Il messaggio di errore visualizzato sarà simile all'esempio riportato 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ò richiedere un timeout 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 HCI di Azure Stack dopo alcuni giorni, Kubectl non è stato eseguito alcun comando. Il log del plug-in Key Management Service (KMS) ha visualizzato 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 Azure Stack HCI 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'installazione del servizio Azure Kubernetes in Azure Stack HCI 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. Il tentativo di distribuire il 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 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 usando Windows Admin Center perché ha già installato i moduli di PowerShell più recenti.

Quando si distribuisce il servizio Azure Kubernetes in Azure Stack HCI 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 richiesta 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 i nodi non vengano sottoposto a provisioning eccessivo. I nodi Di Windows non supportano l'eliminazione in base ai limiti delle risorse, quindi è necessario stimare la quantità di contenitori da usare e quindi assicurarsi che i nodi dispongano di 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 di luglio di Azure Stack HCI (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 in Azure Stack HCI.

Se si effettua il provisioning di un cluster del servizio Azure Kubernetes in Azure Stack HCI 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, a volte si perde la possibilità di configurare le macchine virtuali a disponibilità elevata. La soluzione alternativa corrente consiste nel riavviare wssdagent ognuno dei nodi Azure Stack HCI. 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 di wssdagent nei nodi. Sarà tuttavia necessario aggiungere manualmente le macchine virtuali esistenti al cluster di failover.

Quando si ridimensiona un cluster, le risorse del cluster a disponibilità elevata si trovano 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 correttamente, ma dopo che l'host del servizio Azure Kubernetes è stato disattivato per diversi giorni, il Kubectl comando non funzionava. Dopo l'esecuzione del comando oKubectl get services, viene visualizzato questo Kubectl get nodes 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 ha esito negativo e viene visualizzato 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 le immagini del contenitore inutilizzate, che possono includere immagini di sospensione e, in questo caso, 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 e errori
• problemi noti dell'archiviazione