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 (servizio Azure Kubernetes).
Errori di creazione dell'estensione
Errore: Non è possibile 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 può verificarsi perché il cluster del servizio Azure Kubernetes non riesce a stabilire una connessione con Azure.
Causa 1: l'agente di estensione del cluster e i pod di gestione non vengono inizializzati
L'agente di estensione del cluster e la gestione sono componenti di sistema cruciali responsabili della gestione del ciclo di vita delle applicazioni Kubernetes. L'inizializzazione dei pod dell'agente di estensione del cluster e dei pod di gestione potrebbe non riuscire a causa dei problemi seguenti:
- Limiti delle risorse
- Restrizioni dei criteri
- 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 letto, controllare la descrizione del pod eseguendo il comando seguente kubectl describe pod per ottenere altri dettagli sui problemi sottostanti( ad esempio, i taints che impediscono la pianificazione, la memoria insufficiente o le 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 in uscita o sul firewall
Se l'agente di estensione del cluster e i pod di gestione sono integri e si verifica comunque l'errore "Impossibile ottenere una risposta dall'agente in tempo", è probabile che esista un problema di blocco o firewall in uscita. Questo problema potrebbe impedire agli agenti di estensione del cluster e ai pod di gestione di comunicare con Azure.
Soluzione 2: Assicurarsi che siano soddisfatti i prerequisiti di rete
Per risolvere questo problema, assicurarsi di seguire i prerequisiti di rete descritti in 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 in modo non riuscito di chiamare gli <region>.dp.kubernetesconfiguration.azure.com endpoint di servizio del piano dati. Questo errore genera una voce "Errorcode: 403, Message This traffic is not authorized" nei log dei pod extension-agent.
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 un PrivateLinkScope preesistente esiste nel piano dati di un'estensione per Kubernetes abilitato per Azure Arc e la rete virtuale (o il 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 sta risolvendo l'endpoint del piano dati:
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 nella 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 abilitati per Azure Arc e servizio Azure Kubernetes.
Soluzione 3.2: Creare un override CoreDNS
Se la soluzione consigliata non è possibile nella situazione, creare un override CoreDNS per l'endpoint del piano dati di estensione per passare alla rete pubblica. Per altre informazioni su come personalizzare CoreDNS, vedere la sezione "Plug-in Hosts" di "Customize CoreDNS with servizio Azure Kubernetes".
Per creare un override 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 venga risolto 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 "Errorcode: 403, Message This traffic is not authorized". 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" tainted
Quando si verifica questo errore, la voce seguente viene registrata nel log dell'agente di estensione:
Errore del pod di estensione: sono disponibili 0/2 nodi: 2 nodi con taint {CriticalAddonsOnly: true}. preemption: sono disponibili 0/2 nodi: 2 La precedenza non è utile per la pianificazione.
Causa
Questo errore si verifica quando si tenta di abilitare le estensioni, ad esempio il runtime di applicazione distribuita (DAPR) in un cluster del servizio Azure Kubernetes con CriticalAddonsOnly pool di nodi tainted. In questa situazione, 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 vedere che non possono 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.
Note
È consigliabile non installare le estensioni nei
CriticalAddOnsOnlypool di nodi tainted, a meno che questa operazione non sia necessaria 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 sull'uso dell'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à della risorsa
- Impossibile scaricare il grafico Helm dall'URL del repository
- Rendering del grafico Helm non riuscito con 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 non riesce 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: risorse di memoria o CPU inadeguate all'interno del cluster possono impedire l'inizializzazione corretta di pod, processi o altre risorse Kubernetes. Alla fine, questa situazione causa il timeout dell'installazione. I vincoli di criteri o i vincoli dei nodi (ad esempio
NoSchedule) possono anche bloccare l'inizializzazione delle risorse.Mancate corrispondenze 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 non corrette: le impostazioni di configurazione non corrette possono impedire l'avvio dei pod.
Soluzione
Per risolvere il problema, seguire questa procedura:
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 grafici e configurazioni Helm: molte applicazioni Kubernetes usano 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 a 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 utente fornito tramite le impostazioni di configurazione passate come valori Helm durante l'installazione. Se una di queste impostazioni di configurazione cruciali manca o non è corretta, il grafico Helm potrebbe non eseguire il rendering.
Per risolvere il problema, controllare l'estensione o la documentazione 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 dei grafici 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 specifica in genere 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 versione specifica. 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.