Risolvere gli errori durante la distribuzione delle estensioni del cluster del servizio Azure Kubernetes
Questo articolo illustra come risolvere gli errori che si verificano quando si distribuiscono le estensioni del cluster per Microsoft servizio Azure Kubernetes (AKS).
Errori di creazione dell'estensione
Errore: impossibile ottenere una risposta dall'agente in tempo
Questo errore si verifica se i servizi di Azure non ricevono una risposta dall'agente di estensione del cluster. Questa situazione potrebbe verificarsi perché il cluster del servizio Azure Kubernetes non è in grado di stabilire una connessione con Azure.
Causa 1: l'agente di estensione del cluster e i pod di gestione non vengono inizializzati
L'agente e il gestore dell'estensione del cluster sono componenti di sistema cruciali responsabili della gestione del ciclo di vita delle applicazioni Kubernetes. L'inizializzazione dell'agente di estensione del cluster e dei pod di gestione potrebbe non riuscire a causa dei problemi seguenti:
- Limitazioni delle risorse
- Restrizioni dei criteri
- Taints dei nodi, ad esempio
NoSchedule
Soluzione 1: assicurarsi che l'agente di estensione del cluster e i pod di gestione funzionino correttamente
Per risolvere questo problema, assicurarsi che l'agente di estensione del cluster e i pod di gestione siano pianificati correttamente e possano essere avviati. Se i pod sono bloccati in uno stato non già pronto, controllare la descrizione del pod eseguendo il comando seguente kubectl describe pod per ottenere maggiori dettagli sui problemi sottostanti (ad esempio, i problemi che impediscono la pianificazione, memoria insufficiente o restrizioni dei criteri):
kubectl describe pod -n kube-system extension-operator-{id}
Ecco un esempio di output dei comandi:
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
Per i cluster connessi ad ARC, eseguire il comando seguente per controllare la descrizione del pod:
kubectl describe pod -n azure-arc extension-manager-{id}
Ecco un esempio di output dei comandi:
NAMESPACE NAME READY STATUS RESTARTS AGE
azure-arc cluster-metadata-operator-744f8bfbd4-7pssr 0/2 ImagePullBackOff 0 6d19h
azure-arc clusterconnect-agent-7557d99d5c-rtgqh 0/3 ImagePullBackOff 0 6d19h
azure-arc clusteridentityoperator-9b8b88f97-nr8hf 0/2 ImagePullBackOff 0 6d19h
azure-arc config-agent-6d5fd59b8b-khw2d 0/2 ImagePullBackOff 0 6d19h
azure-arc controller-manager-5bc97f7db6-rt2zs 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-events-collector-7596688867-sqzv2 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-manager-86bbb949-6s59q 0/3 ImagePullBackOff 0 6d19h
azure-arc flux-logs-agent-5f55888db9-wnr4c 0/1 ImagePullBackOff 0 6d19h
azure-arc kube-aad-proxy-646c475dcc-92b86 0/2 ImagePullBackOff 0 6d19h
azure-arc logcollector-5cbc659bfb-9v96d 0/1 ImagePullBackOff 0 6d19h
azure-arc metrics-agent-5794866b46-j9949 0/2 ImagePullBackOff 0 6d19h
azure-arc resource-sync-agent-6cf4cf7486-flgwc 0/2 ImagePullBackOff 0 6d19h
Quando l'agente di estensione del cluster e i pod di gestione sono operativi e integri, stabiliscono la comunicazione con i servizi di Azure per installare e gestire le applicazioni Kubernetes.
Causa 2: un problema influisce sul blocco o sul firewall in uscita
Se l'agente di estensione del cluster e i pod di gestione sono integri e si verifica ancora l'errore "Impossibile ottenere una risposta dall'agente in tempo", probabilmente esiste un problema di blocco o firewall in uscita. Questo problema potrebbe impedire all'agente di estensione del cluster e ai pod di gestione di comunicare con Azure.
Soluzione 2: assicurarsi che i prerequisiti di rete siano soddisfatti
Per risolvere questo problema, assicurarsi di seguire i prerequisiti di rete descritti nelle regole di rete in uscita e FQDN per i cluster servizio Azure Kubernetes (servizio Azure Kubernetes).
Causa 3: Il traffico non è autorizzato
L'agente di estensione tenta senza successo di chiamare gli <region>.dp.kubernetesconfiguration.azure.com endpoint del servizio del piano dati. Questo errore genera una voce "Codice errore: 403, Messaggio Questo traffico non è autorizzato" nei log del pod dell'agente di estensione.
kubectl logs -n kube-system extension-agent-<pod-guid>
{ "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>, "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
{ "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
Questo errore si verifica se esiste un privatelinkscope preesistente nel piano dati di un'estensione per Kubernetes abilitato per Azure Arc e la rete virtuale (o server DNS privato) viene condivisa tra Kubernetes abilitato per Azure Arc e il cluster gestito dal servizio Azure Kubernetes. Questa configurazione di rete fa sì che il traffico in uscita del servizio Azure Kubernetes dal piano dati dell'estensione instrada anche attraverso lo stesso indirizzo IP privato anziché tramite un indirizzo IP pubblico.
Eseguire il comando nslookup seguente nel cluster del servizio Azure Kubernetes per recuperare l'indirizzo IP privato specifico in cui l'endpoint del piano dati sta risolvendo:
PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name: <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184
Quando si cerca l'indirizzo IP privato nel portale di Azure, i risultati della ricerca puntano alla risorsa esatta: rete virtuale, zona DNS privata, server DNS privato e così via. Questa risorsa ha un endpoint privato configurato per il piano dati dell'estensione per Kubernetes abilitato per Azure Arc.
Soluzione 3.1: (Scelta consigliata) Creare reti virtuali separate
Per risolvere questo problema, è consigliabile creare reti virtuali separate per i calcoli kubernetes e del servizio Azure Kubernetes abilitati per Azure Arc.
Soluzione 3.2: Creare un override di CoreDNS
Se la soluzione consigliata non è possibile in una situazione specifica, creare un override di CoreDNS per consentire all'endpoint del piano dati dell'estensione di passare attraverso la rete pubblica. Per altre informazioni su come personalizzare CoreDNS, vedere la sezione "Hosts plugin" di "Customize CoreDNS with servizio Azure Kubernetes".
Per creare un override di CoreDNS, seguire questa procedura:
Trovare l'indirizzo IP pubblico dell'endpoint del piano dati dell'estensione eseguendo il
nslookupcomando . Assicurarsi di modificare l'area , ad esempio ,eastus2euapin base alla posizione del cluster del servizio Azure Kubernetes:nslookup <region>.dp.kubernetesconfiguration.azure.com Non-authoritative answer: Name: clusterconfig<region>.<region>.cloudapp.azure.com Address: 20.39.12.229 Aliases: <region>.dp.kubernetesconfiguration.azure.com <region>.privatelink.dp.kubernetesconfiguration.azure.com <region>.dp.kubernetesconfiguration.trafficmanager.netCreare un backup della configurazione coreDNS esistente:
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yamlEseguire l'override del mapping per l'endpoint del piano dati a livello di area , ad esempio ,
eastus2euapall'indirizzo IP pubblico. A tale scopo, creare un file YAML denominato corednsms.yaml e quindi copiare la configurazione di esempio seguente nel nuovo file. Assicurarsi di aggiornare l'indirizzo e il nome host usando i valori per l'ambiente.apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom # This is the name of the configuration map that you can overwrite with your changes. namespace: kube-system data: extensionsdp.override: | # You can select any name here, but it must have the .override file name extension. hosts { 20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com fallthrough }Per creare configmap, eseguire il
kubectl applycomando , specificando il nome del file manifesto YAML:kubectl apply -f corednsms.yamlPer ricaricare ConfigMap e abilitare l'utilità di pianificazione Kubernetes per riavviare CoreDNS senza tempi di inattività, eseguire il comando kubectl rollout restart :
kubectl -n kube-system rollout restart deployment corednsEseguire di nuovo il
nslookupcomando per assicurarsi che l'endpoint del piano dati si risolva nell'indirizzo IP pubblico specificato:kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup [region].dp.kubernetesconfiguration.azure.com Name: <region>.dp.kubernetesconfiguration.azure.com Address: 20.39.12.229
I log dei pod dell'agente di estensione non devono più registrare le voci di errore "Codice errore: 403, Messaggio Questo traffico non è autorizzato". I log devono invece contenere codici di risposta "200".
kubectl logs -n kube-system extension-agent-{id}
{ "Message": "GET configurations returned response code {200}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5" }
Errore: i pod di estensione non possono essere pianificati se tutti i pool di nodi nel cluster sono "CriticalAddonsOnly" contaminati
Quando si verifica questo errore, nel log dell'agente di estensione viene registrata la voce seguente:
Errore del pod di estensione: sono disponibili 0/2 nodi: 2 nodi con taint non tollerato {CriticalAddonsOnly: true}. preemption: sono disponibili 0/2 nodi: 2 Preemption non è utile per la pianificazione.
Causa
Questo errore si verifica quando si tenta di abilitare le estensioni, ad esempio Distributed Application Runtime (DAPR) in un cluster del servizio Azure Kubernetes con CriticalAddonsOnly pool di nodi contaminati. In questo caso, i pod di estensione non sono pianificati in alcun nodo perché non esiste alcuna tolleranza per questi taints.
Per visualizzare la situazione di errore, esaminare i pod di estensione per verificare che siano bloccati in uno stato in sospeso:
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
Descrivere i pod per verificare che non possano essere pianificati a causa di un taint non supportabile:
kubectl describe po -n {namespace-name} {podname}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
Nota
È consigliabile non installare le estensioni nei
CriticalAddOnsOnlypool di nodi contaminati, a meno che non sia necessario per i carichi di lavoro dell'applicazione.È consigliabile non usare un
CriticalAddOnsOnlytaint nei cluster del pool a nodo singolo. Se si usa tale taint in un cluster con un solo pool di nodi, non è possibile pianificare i pod dell'applicazione nel cluster. Assicurarsi che almeno un pool di nodi nel cluster non abbia questo taint. Per altre informazioni su quando usare l'annotazioneCriticalAddonsOnly, vedere Gestire i pool di nodi di sistema in servizio Azure Kubernetes (servizio Azure Kubernetes).
Soluzione 1: Aggiungere un pool di nodi al cluster
Per risolvere questo problema, aggiungere un altro pool di nodi che non ha un CriticalAddonsOnly taint. Questa azione determina la pianificazione dei pod di estensione nel nuovo pool di nodi.
Soluzione 2: Rimuovere il taint "CriticalAddonsOnly"
Se è possibile e pratico, è possibile rimuovere il CriticalAddonsOnly taint per installare l'estensione nel cluster.
Errori helm
È possibile che si verifichi uno degli errori correlati a Helm seguenti:
- Timeout in attesa dell'idoneità delle risorse
- Impossibile scaricare il grafico Helm dall'URL del repository
- Il rendering del grafico Helm non è riuscito con i valori specificati
- La risorsa esiste già nel cluster
- L'operazione è già in corso per Helm
Errore: timeout in attesa dell'idoneità delle risorse
L'installazione di un'applicazione Kubernetes ha esito negativo e visualizza i messaggi di errore seguenti:
processo non riuscito: BackoffLimitExceeded
Timeout in attesa che la risorsa arrivi a uno stato pronto/completato.
Causa
Questo problema presenta le cause comuni seguenti:
Vincoli di risorse: la memoria o le risorse CPU insufficienti all'interno del cluster possono impedire la corretta inizializzazione di pod, processi o altre risorse Kubernetes. Alla fine, questa situazione causa il timeout dell'installazione. Anche i vincoli di criteri o i tag dei nodi , ad
NoScheduleesempio , possono bloccare l'inizializzazione delle risorse.Mancata corrispondenza dell'architettura: il tentativo di pianificare un'applicazione basata su Linux in un nodo basato su Windows (o viceversa) può causare errori nell'inizializzazione delle risorse Kubernetes.
Impostazioni di configurazione errate: le impostazioni di configurazione non corrette possono impedire l'avvio dei pod.
Soluzione
Per risolvere il problema, attenersi alla procedura seguente:
Controllare le risorse: assicurarsi che il cluster Kubernetes disponga di risorse sufficienti e che la pianificazione dei pod sia consentita nei nodi (è consigliabile prendere in considerazione i taints). Verificare che le risorse di memoria e CPU soddisfino i requisiti.
Esaminare gli eventi: controllare gli eventi all'interno dello spazio dei nomi Kubernetes per identificare potenziali problemi che potrebbero impedire a pod, processi o altre risorse Kubernetes di raggiungere uno stato pronto.
Controllare le configurazioni e i grafici Helm: molte applicazioni Kubernetes usano i grafici Helm per distribuire le risorse nel cluster. Alcune applicazioni potrebbero richiedere l'input dell'utente tramite le impostazioni di configurazione. Assicurarsi che tutti i valori di configurazione forniti siano accurati e soddisfino i requisiti di installazione.
Errore: impossibile scaricare il grafico Helm dall'URL del repository
Questo errore è causato da problemi di connettività che si verificano tra il cluster e il firewall oltre ai problemi di blocco in uscita. Per risolvere questo problema, vedere Regole di rete in uscita e FQDN per i cluster servizio Azure Kubernetes (servizio Azure Kubernetes).
Errore: il rendering del grafico Helm non è riuscito con i valori specificati
Questo errore si verifica se le applicazioni Kubernetes si basano sui grafici Helm per distribuire le risorse all'interno del cluster Kubernetes. Queste applicazioni potrebbero richiedere l'input dell'utente fornito tramite le impostazioni di configurazione passate come valori Helm durante l'installazione. Se una di queste impostazioni di configurazione cruciali non è presente o non è corretta, il rendering del grafico Helm potrebbe non essere eseguito.
Per risolvere il problema, controllare la documentazione dell'estensione o dell'applicazione per determinare se sono stati omessi valori obbligatori o se sono stati specificati valori non corretti durante l'installazione dell'applicazione. Queste linee guida consentono di risolvere i problemi di rendering del grafico Helm causati da valori di configurazione mancanti o non accurati.
Errore: la risorsa esiste già nel cluster
Questo errore si verifica se esiste un conflitto tra le risorse Kubernetes all'interno del cluster e le risorse Kubernetes che l'applicazione sta tentando di installare. Il messaggio di errore in genere specifica il nome della risorsa in conflitto.
Se la risorsa in conflitto è essenziale e non può essere sostituita, potrebbe non essere possibile installare l'applicazione. Se la risorsa non è critica e può essere rimossa, eliminare la risorsa in conflitto e quindi ritentare l'installazione.
Errore: l'operazione è già in corso per Helm
Questo errore si verifica se è già in corso un'operazione per una determinata versione. Per risolvere il problema, attendere 10 minuti e quindi ripetere l'operazione.
Contattaci per ricevere assistenza
In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.