Risolvere i problemi di App contenitore di Azure in Kubernetes abilitato per Azure Arc

La risoluzione dei problemi delle app container su Azure Arc richiede di controllare sia il provisioning delle risorse Azure sia lo stato runtime di Kubernetes. Inizia dalla dipendenza più vicina al cluster e procedi in quest'ordine:

Stato di salute e capacità del cluster Kubernetes.
Connettività del cluster connesso di Azure Arc.
Provisioning delle estensioni e dei pod di Container Apps.
Provisioning della posizione personalizzata.
Provisioning e ingresso dell'ambiente connesso.
App contenitore o provisioning di processo.
DNS dell'applicazione, percorso di rete e comportamento a runtime.

Non ricreare ripetutamente risorse successive mentre una dipendenza precedente è malsana.

Raccolta di diagnostica

Sostituisci i segnaposto delle risorse con i valori usati durante l'installazione, poi raccogli lo stato delle risorse di Azure. Usa <NAMESPACE> per il namespace release dell'estensione e <APPS_NAMESPACE> per il namespace del carico di lavoro applicativo.

az account show --query "{name:name,id:id}" --output table
az connectedk8s show --resource-group <RESOURCE_GROUP> --name <CLUSTER_NAME> --output yaml
az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --name <EXTENSION_NAME> --output yaml
az customlocation show --resource-group <RESOURCE_GROUP> --name <CUSTOM_LOCATION_NAME> --output yaml
az containerapp connected-env show --resource-group <RESOURCE_GROUP> --name <CONNECTED_ENVIRONMENT_NAME> --output yaml

Raccogli lo stato di Kubernetes dal cluster:

kubectl config current-context
kubectl get nodes -o wide
kubectl get pods,services,deployments,statefulsets,daemonsets -n <NAMESPACE> -o wide
kubectl get events -n <NAMESPACE> --sort-by=.lastTimestamp
kubectl describe pod -n <NAMESPACE> <POD_NAME>
kubectl logs -n <NAMESPACE> <POD_NAME> --all-containers=true --tail=200

Rivedi tutto il risultato prima di condividerlo. Rimuovere token, chiavi condivise, password del registro, segreti, intestazioni di autorizzazione, dati dei certificati e dati dei clienti non correlati. Non condividere i valori delle impostazioni protette dalle estensioni. Se non sei sicuro se un campo contenga dati sensibili, rimuovilo e informa l'assistenza Microsoft quale campo hai omesso.

Il cluster connesso non è pronto

Symptoms

Il cluster connesso non riporta uno stato di provisioning con esito positivo né uno stato di connessione.
Le operazioni di Azure sul cluster non riescono o vanno in timeout.

Cause

Le cause comuni includono agenti Azure Arc non sani, connettività in uscita bloccata, configurazione di proxy o ispezione TLS non supportata, orario di sistema errato o un fornitore di risorse non registrato.

Diagnostica

Esegui il seguente comando e ispeziona i campi di provisioning e connettività:

az connectedk8s show --resource-group <RESOURCE_GROUP> --name <CLUSTER_NAME> --output yaml

Controlla gli agenti Azure Arc e gli eventi recenti:

kubectl get pods -n azure-arc -o wide
kubectl get events -n azure-arc --sort-by=.lastTimestamp

Verificare che il cluster possa raggiungere gli endpoint Kubernetes abilitati per Azure Arc tramite il firewall e il proxy configurati.

Verifica che i nodi del cluster abbiano un tempo accurato e che i fornitori richiesti siano registrati:

az provider show --namespace Microsoft.Kubernetes --query registrationState --output tsv
az provider show --namespace Microsoft.KubernetesConfiguration --query registrationState --output tsv
az provider show --namespace Microsoft.ExtendedLocation --query registrationState --output tsv

Risolvi

Ripristina gli agenti Arc e la connettività in uscita richiesta prima di modificare le risorse delle Container App. Correggere le esclusioni di proxy, l'ispezione TLS, il DNS o la sincronizzazione temporale secondo i requisiti di Azure Arc. Registra qualsiasi fornitore che segnala NotRegistered.

Verify

Esegui az connectedk8s show di nuovo e verifica che il provisioning abbia avuto successo e che la connettività sia stata ripristinata. Conferma che tutti i pod nel azure-arc namespace siano pronti.

Escalare

Raccogli l'ID della risorsa del cluster connesso, l'output az connectedk8s show ripulito, lo stato del pod dell'agente Arc, gli eventi e l'intervallo di tempo interessato. Non includere contenuti kubeconfig, token o credenziali proxy.

L'installazione delle estensioni fallisce o si scadono

Symptoms

Lo stato di provisioning dell'estensione resta in sospeso o segnala un errore.
Il comando installazione attesa termina, ma l'estensione non è pronta.

Cause

Le cause comuni includono una versione Kubernetes o un'architettura di nodo non supportata, capacità insufficiente, fallimenti nel pull dell'immagine, negazioni di policy di ammissione, conflitti di namespace, un'installazione KEDA esistente o un bilanciatore di carico non disponibile.

Diagnostica

Ispeziona lo stato completo dell'estensione e del messaggio di stato:

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --name <EXTENSION_NAME> --output yaml

Verifica i nodi, i pod di estensione, gli eventi di pianificazione e il download delle immagini:

kubectl get nodes -o wide
kubectl get pods -n <NAMESPACE> -o wide
kubectl get events -n <NAMESPACE> --sort-by=.lastTimestamp

Verifica se esiste già un'installazione di KEDA:
```
kubectl get deployment -A | grep -i keda
```
Conferma che il namespace di rilascio dell'estensione e quello dell'applicazione configurato corrispondano, e ispeziona LoadBalancer i servizi:
```
kubectl get services -n <NAMESPACE>
```

Risolvi

Correggi il primo problema di dipendenza segnalato. Capacità gratuita del cluster, corretta connettività del registro immagini, indirizzare la policy di ammissione con il proprietario della policy del cluster o risolvere conflitti nello spazio dei nomi. Se KEDA esiste già, fermarsi e confermare la configurazione di coesistenza supportata prima di continuare. Non rimuovere l'installazione KEDA esistente né applicare impostazioni di estensione non documentate perché altri carichi di lavoro potrebbero dipendere da essa. Non cancellare la posizione personalizzata o l'ambiente connesso per riparare un fallimento dell'estensione. Se è necessaria la rimozione dell'estensione dopo aver corretto la causa, rivedi l'impatto e usa il comando supportato az k8s-extension delete prima di reinstallare.

Verify

Esegui az k8s-extension show e conferma che lo stato di provisioning è Succeeded. Verifica che i pod di estensione siano in funzione e pronti prima di creare una posizione personalizzata.

Escalare

Raccogli lo stato ripulito delle estensioni, la release train e la versione, la versione di Kubernetes, il sistema operativo e l'architettura dei nodi, gli eventi del namespace e i log dei pod che presentano errori. Non includere impostazioni protette o credenziali del registro.

I pod di estensione sono in attesa o si stanno riavviando

Symptoms

Uno o più pod di estensione sono ancora Pending, CrashLoopBackOff, ImagePullBackOff o OOMKilled.
Le operazioni supportate dall'estensione non sono disponibili o intermittenti.

Cause

I pod possono guastarsi a causa di insufficiente CPU o memoria, contaminazioni dei nodi o regole di affinità, restrizioni sul pull dell'immagine, fallimenti nei volumi, politiche di ammissione o errori di avvio dei componenti.

Diagnostica

Confronta il componente interessato con i componenti di estensione attesi e le richieste di risorse in Risorse create dall'estensione Container Apps.

Descrivi il pod e ispeziona la programmazione e gli stati del container:

kubectl describe pod -n <NAMESPACE> <POD_NAME>
kubectl get events -n <NAMESPACE> --sort-by=.lastTimestamp

Per un pod di riavvio, raccogli i log attuali e precedenti:

kubectl logs -n <NAMESPACE> <POD_NAME> --all-containers=true --tail=200
kubectl logs -n <NAMESPACE> <POD_NAME> --all-containers=true --previous --tail=200

Risolvi

Risolvere la condizione mostrata negli eventi del pod. Aggiungi capacità allocabile, correggi i taint o i vincoli di posizionamento, ripristina l'accesso al registry, risolvi le dipendenze dei volumi o modifica un'eccezione di policy approvata. Non modificare direttamente le implementazioni gestite dall'estensione perché l'estensione può sovrascrivere tali modifiche.

Verify

Esegui kubectl getpods -n <NAMESPACE> e verifica che tutti i pod attesi siano in funzione e pronti senza aumentare il numero di riavvii.

Escalare

Raccogli descrizioni sanitizzate dei pod, eventi, log attuali e precedenti, risorse allocabili dai nodi e la versione dell'estensione. Non includere i segreti Kubernetes o i valori delle variabili ambientali.

Fallimento nella creazione di località personalizzata

Symptoms

az customlocation create fallisce.
La posizione personalizzata non entra nello stato di provisioning Succeeded.

Cause

Le cause comuni includono una funzionalità delle località personalizzate disabilitata, un ID dell'estensione errato, una mancata corrispondenza dello spazio dei nomi, autorizzazioni dell'account del servizio o di Azure RBAC, la registrazione del provider oppure una risorsa obsoleta con errore.

Diagnostica

Verifica che il cluster connesso e l'estensione siano integri.

Recupera l'ID dell'estensione e confrontalo con l'ID usato per creare la posizione personalizzata:

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --name <EXTENSION_NAME> --query id --output tsv
az customlocation show --resource-group <RESOURCE_GROUP> --name <CUSTOM_LOCATION_NAME> --output yaml

Conferma che il namespace personalizzato corrisponda al namespace di rilascio dell'estensione e allo spazio di applicazione configurato.
Verifica Microsoft.ExtendedLocation la registrazione e, se necessario, abilita le posizioni personalizzate nel cluster.

Risolvi

Correggi l'ID dell'estensione, il namespace, l'abilitazione delle funzionalità, la registrazione del provider o i permessi. Riprovare la creazione solo dopo che l'estensione è integra. Prima di rimuovere una posizione personalizzata fallita, conferma che nessun ambiente connesso dipenda da essa.

Verify

Esegui az customlocation show e conferma che provisioningState sia Succeeded e che siano presenti l'ID dell'estensione del cluster e lo spazio dei nomi previsti.

Escalare

Raccogliere l'output pulito della posizione personalizzata, gli ID risorsa del cluster connesso e dell'estensione, lo spazio dei nomi, gli stati del provider, il testo dell'errore e l'ID di correlazione. Non includere né i token di accesso né il contenuto del file kubeconfig.

Fallimento nella creazione di ambienti connessi

Symptoms

az containerapp connected-env create non riesce o va in timeout.
L'ambiente connesso rimane in uno stato fallito o in attesa.

Cause

Le cause comuni includono una posizione o un'estensione personalizzata non sana, una regione di metadati Azure non supportata, registrazione mancante Microsoft.App o configurazione del nome dell'ambiente o del dominio non valida.

Diagnostica

Confermare che la posizione personalizzata e gli stati di provisioning delle estensioni siano Succeeded.

Ispeziona l'ambiente connesso e lo stato del fornitore.

az containerapp connected-env show --resource-group <RESOURCE_GROUP> --name <CONNECTED_ENVIRONMENT_NAME> --output yaml
az provider show --namespace Microsoft.App --query registrationState --output tsv

Confronta la regione Azure selezionata con le regioni supportate nelle limitazioni di App contenitore di Azure su Azure Arc.

Risolvi

Ripara prima la posizione personalizzata o l'estensione. Eseguire la registrazione Microsoft.App se necessario, quindi riprovare l'operazione relativa all'ambiente connesso con un'area geografica supportata e un nome valido. Non ricreare la posizione personalizzata quando è integra.

Verify

Esegui az containerapp connected-env show e conferma che provisioningState sia Succeeded e che il riferimento del percorso personalizzato sia corretto.

Escalare

Raccogliere l'output dell'ambiente connesso pulito, della posizione personalizzata e dell'estensione; l'area di Azure; gli ID delle risorse; e l'ID di correlazione. Non includere informazioni riservate o header di autorizzazione.

Il servizio di ingresso non ha IP esterno

Symptoms

Il servizio ingress dell'estensione LoadBalancer mostra un IP esterno di <pending>.
L'ambiente connesso viene creato, ma non è disponibile alcun indirizzo di ingresso raggiungibile.

Cause

Il cluster Kubernetes potrebbe non avere un'implementazione funzionante LoadBalancer , il suo pool di indirizzi potrebbe essere esaurito, l'indirizzo richiesto potrebbe non essere disponibile, oppure il traffico firewall e delle sonde di salute potrebbe essere bloccato.

Diagnostica

Elenca i servizi e identifica il servizio di ingresso delle estensioni:
```
kubectl get services -n <NAMESPACE> -o wide
```

Descrivi quel servizio e rivedi i suoi eventi:

kubectl describe service -n <NAMESPACE> <INGRESS_SERVICE_NAME>
kubectl get events -n <NAMESPACE> --sort-by=.lastTimestamp

Conferma che il bilanciatore di carico del cluster abbia un indirizzo disponibile e consenta le sonde di salute e il traffico necessari.
Per AKS su Azure Locale, verifica la configurazione del bilanciatore di carico e il prerequisito personalizzato di CoreDNS.

Risolvi

Configurare o riparare il load balancer Kubernetes supportato, fornire un indirizzo disponibile e consentire il percorso del probe di integrità. Se l'installazione utilizza l'impostazione di estensione loadBalancerIp , confermare che l'indirizzo sia riservato e assegnato al bilanciatore di carico prima di cambiare la configurazione dell'estensione.

Verify

Esegui kubectl get services -n <NAMESPACE> e conferma che il servizio di ingresso abbia l'IP esterno atteso. Testa la raggiungibilità a quell'indirizzo dalla rete client prevista.

Escalare

Raccogli la descrizione del servizio sanitizzato, gli eventi, l'implementazione del bilanciatore di carico e la configurazione del pool di indirizzi, lo stato della sonda di salute e il percorso firewall. Non includere certificati o credenziali.

L'ingresso delle applicazioni non è raggiungibile

Symptoms

Il nome di dominio completamente qualificato dell'applicazione (FQDN) non si risolve, scade o restituisce una risposta HTTP o TLS inaspettata.
L'accesso diretto all'indirizzo di ingresso funziona, ma il nome host dell'applicazione no.

Cause

Le cause comuni includono un record DNS wildcard mancante, differenze nel DNS del client, routing bloccato, problemi relativi ai certificati o a TLS, un componente ingress non funzionante correttamente, una porta di destinazione errata, probe dell'applicazione non riuscite o un ingress interno.

Diagnostica

Recupera le impostazioni configurate di FQDN e ingresso.

az containerapp show --resource-group <RESOURCE_GROUP> --name <CONTAINER_APP_NAME> --query "{fqdn:properties.configuration.ingress.fqdn,external:properties.configuration.ingress.external,targetPort:properties.configuration.ingress.targetPort}" --output yaml

Risolvi e richiedi il FQDN dalla rete del client interessato.

nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>

Confermare che il risultato si risolva all'IP di ingresso dell'estensione. Controlla i pod di ingresso, i servizi, i pod applicazioni e gli eventi delle sonde.

Risolvi

Crea o correggi il record DNS wildcard per il dominio dell'ambiente connesso, ripristina il percorso di rete del client, correggi la configurazione dei certificati o correggi la porta e le sonde di destinazione dell'applicazione. Se l'ingresso è interno, testa da una rete che può raggiungere il bilanciatore di carico interno invece di esporlo come una scorciatoia per la risoluzione dei problemi.

Verify

Risolvi il FQDN dell'applicazione da ciascuna rete client prevista e conferma che una richiesta HTTP o HTTPS restituisca la risposta applicativa attesa.

Escalare

Raccogli il FQDN, il risultato DNS, l'IP dell'ingress, l'output dettagliato e sanificato della richiesta, lo stato dell'ingress e del pod dell'applicazione, gli eventi delle probe e la posizione del client interessato. Rimuovere gli header di autorizzazione, i cookie e i dati privati del certificato.

La revisione non è pronta

Symptoms

Una nuova revisione non è pronta.
L'applicazione non dispone di repliche pronte o rimane in uno stato di provisioning.

Cause

Le cause comuni includono un'immagine o un'architettura incompatibile, credenziali di registro non valide, un comando o una porta di avvio errata, sonde guastate, risorse insufficienti, fallimenti nel montaggio del volume o riferimenti segreti mancanti.

Diagnostica

Ispezionare lo stato della domanda e della revisione:

az containerapp show --resource-group <RESOURCE_GROUP> --name <CONTAINER_APP_NAME> --output yaml
az containerapp revision list --resource-group <RESOURCE_GROUP> --name <CONTAINER_APP_NAME> --output table

Ispeziona i pod, gli eventi e i log interessati:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp
kubectl describe pod -n <APPS_NAMESPACE> <POD_NAME>
kubectl logs -n <APPS_NAMESPACE> <POD_NAME> --all-containers=true --tail=200

Risolvi

Correggi le credenziali di immagine e registro, il comando di avvio, la porta target, le sonde, le risorse richieste, la configurazione del volume o il riferimento segreto identificato dagli eventi. Distribuisci la configurazione corretta dell'applicazione come nuova versione. Non modificare direttamente i pod di revisione.

Verify

Esegui az containerapp revision list e verifica che la nuova revisione sia attiva e in salute con repliche pronte. Invia una richiesta all'applicazione se l'ingresso è abilitato.

Escalare

Raccogli la configurazione ripulita dell'applicazione e della revisione, le descrizioni dei pod, gli eventi, i log, il nome dell'immagine e l'architettura, e la versione dell'estensione. Non includere password del registro o valori segreti.

L'applicazione non è scalabile

Symptoms

Il conteggio delle repliche non risponde al caricamento o a un'origine eventi.
L'applicazione non si avvia a partire da zero repliche.
Le repliche richieste sono ancora in sospeso.

Cause

Le cause comuni includono componenti KEDA non sani, autenticazione scaler non valida, sorgente di trigger irraggiungibile, repliche minime o massime errate, capacità del cluster insufficiente o un percorso di attivazione scalabile da zero non disponibile.

Diagnostica

Ispezionare la configurazione in scala e lo stato delle revisioni dell'applicazione.

az containerapp show --resource-group <RESOURCE_GROUP> --name <CONTAINER_APP_NAME> --query properties.template.scale --output yaml
az containerapp revision list --resource-group <RESOURCE_GROUP> --name <CONTAINER_APP_NAME> --output table

Verifica KEDA, i componenti di scaling, i pod dell'applicazione e gli eventi.

kubectl get deployments,pods -n <NAMESPACE> | grep -i keda
kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp

Verificare la connettività della sorgente di attivazione dal cluster senza stampare i valori di autenticazione.

Risolvi

Ripristinare lo stato di integrità di KEDA, correggere la regola di scalabilità e i relativi riferimenti ai segreti, consentire l'accesso all'origine del trigger oppure aggiungere capacità del cluster per la pianificazione. Conferma che l'impostazione massima della replica sia superiore al minimo e che non superi la capacità disponibile del cluster.

Verify

Generare un carico controllato di trigger o richiesta e confermare che le repliche pronte aumentino e successivamente tornino al minimo configurato. Per la scalabilità a zero, conferma che un nuovo trigger attivi una replica e che l'operazione venga completata correttamente.

Escalare

Raccogli la configurazione sanitizzata della scala, lo stato della revisione, lo stato e i log del pod KEDA, gli eventi dell'applicazione, il tipo di trigger e i timestamp del test. Non includere le credenziali dello scaler o i payload dei messaggi.

Il lavoro non inizia né si completa

Symptoms

Un lavoro manuale, programmato o basato su eventi non inizia.
Un'esecuzione rimane in corso, si ritenta ripetutamente o si conclude con un fallimento.

Cause

Le cause comuni includono una configurazione errata dei trigger, della pianificazione o dell'autenticazione, impostazioni di parallelismo e completamento, il comportamento dei tentativi di ripetizione o del timeout, un errore nel recupero dell'immagine, capacità insufficiente o un errore dell'applicazione.

Diagnostica

Ispeziona il lavoro e le esecuzioni recenti:

az containerapp job show --resource-group <RESOURCE_GROUP> --name <JOB_NAME> --output yaml
az containerapp job execution list --resource-group <RESOURCE_GROUP> --name <JOB_NAME> --output table

Controlla i pod di esecuzione, gli eventi e i log nel namespace dell'applicazione:

kubectl get pods -n <APPS_NAMESPACE> -o wide
kubectl get events -n <APPS_NAMESPACE> --sort-by=.lastTimestamp
kubectl logs -n <APPS_NAMESPACE> <JOB_POD_NAME> --all-containers=true --tail=200

Risolvi

Correggi il trigger, la pianificazione, il riferimento di autenticazione, il numero di completamenti delle repliche, il parallelismo, il limite di tentativi, il timeout, l'immagine o la richiesta di risorse indicati dagli eventi di esecuzione e di Kubernetes. Aggiungi capacità al cluster quando i pod di esecuzione rimangono in stato Pending. Conserva i dati di esecuzione fallita finché non vengono raccolti i log richiesti.

Verify

Avvia o attendi un'esecuzione controllata e conferma che abbia raggiunto lo stato di completamento previsto. Conferma che l'output e gli effetti secondari siano corretti. Progettare l'elaborazione dei processi in modo che sia idempotente, perché i nuovi tentativi e la distribuzione degli eventi possono far eseguire il processo più di una volta.

Escalare

Raccogli configurazioni di lavoro sanitate, cronologia delle esecuzioni, descrizione del pod, eventi, log, tipo di trigger e timestamp. Non inserire credenziali del trigger, dati del payload o segreti.

I tronchi mancano

Symptoms

I log delle applicazioni non compaiono nello spazio di lavoro configurato di Log Analytics.
kubectl logs Funziona, ma la query dello spazio di lavoro non restituisce alcun record.

Cause

Log Analytics potrebbe non essere configurato durante l'installazione delle estensioni, il processore di log potrebbe essere disabilitato o non sano, potrebbe essere interrogato lo spazio di lavoro sbagliato, l'ingestione potrebbe essere ritardata o la query potrebbe utilizzare una tabella o un campo errato.

Diagnostica

Ispeziona la configurazione dell'estensione senza richiedere impostazioni protette e verifica la destinazione del log prevista:

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --name <EXTENSION_NAME> --output yaml

Controlla i pod del processore dei log e i log recenti:

kubectl get pods -n <NAMESPACE> | grep -i log-processor
kubectl logs -n <NAMESPACE> <LOG_PROCESSOR_POD_NAME> --all-containers=true --tail=200

Conferma che l'output dell'applicazione esista al livello Kubernetes:

kubectl logs -n <APPS_NAMESPACE> <APPLICATION_POD_NAME> --all-containers=true --tail=200

Nello spazio di lavoro configurato, esegui una query generica prima di filtrare in base ai campi dell'applicazione:
```
ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(1h)
| take 100
```

Risolvi

Interroga lo spazio di lavoro configurato al momento dell'installazione dell'estensione, ripristina i pod di processore di log non sani correggendo la loro dipendenza segnalata e correggi la tabella o i campi di interrogazione. Non puoi aggiungere Log Analytics a un'estensione esistente dopo l'installazione. Se l'estensione non era configurata per Log Analytics, usa Kubernetes per il logging o pianifica una reinstallazione dell'estensione supportata dopo averne esaminato l'impatto. L'impostazione logProcessor.enabled=false disabilita l'elaborazione dei log e l'inoltro dell'area di lavoro.

Verify

Scrivi un messaggio di test unico all'output standard dell'applicazione. Verifica che kubectl logs lo visualizzi e, quando Log Analytics è configurato, che venga visualizzato nell'area di lavoro dopo la normale latenza di acquisizione.

Escalare

Raccogli l'ID della risorsa dello spazio di lavoro, la configurazione sanificata delle estensioni, lo stato e i log del pod del log-processore, i timestamp dell'applicazione e dei messaggi di test, e il testo della query. Non includere la chiave condivisa dello spazio di lavoro o i dati del log delle applicazioni non correlati al problema.

Errore di registrazione del fornitore

Symptoms

Un'operazione restituisce No registered resource provider found.
Un fornitore obbligatorio rimane NotRegistered o Registering.

Cause

L'abbonamento attivo non ha completato la registrazione per un provider richiesto dal cluster connesso, dall'estensione, dalla posizione personalizzata, dall'ambiente connesso o dalla configurazione di Log Analytics.

Diagnostica

Confermare la sottoscrizione attiva

az account show --query "{name:name,id:id}" --output table

Controlla tutti i provider utilizzati dal percorso di configurazione:

az provider show --namespace Microsoft.Kubernetes --query registrationState --output tsv
az provider show --namespace Microsoft.KubernetesConfiguration --query registrationState --output tsv
az provider show --namespace Microsoft.ExtendedLocation --query registrationState --output tsv
az provider show --namespace Microsoft.App --query registrationState --output tsv
az provider show --namespace Microsoft.Web --query registrationState --output tsv
az provider show --namespace Microsoft.OperationalInsights --query registrationState --output tsv

Risolvi

Registra qualsiasi fornitore non registrato. Ad esempio:

az provider register --namespace Microsoft.App --wait

La registrazione del provider può richiedere alcuni minuti. Non ricreare ripetutamente le risorse mentre la registrazione è in corso. Se la creazione di ambiente connesso restituisce No registered resource provider found mentre Microsoft.App già riporta Registered, registra Microsoft.App nuovamente con il comando precedente e poi riprova l'operazione. Ri-registrare il provider non influisce sulle applicazioni o API esistenti.

Verify

Esegui az provider show--namespace <PROVIDER_NAMESPACE> --query registrationState --output tsv e conferma che restituisca Registered. Riprova l'operazione originale nello stesso abbonamento.

Escalare

Raccogli l'ID abbonamento, lo spazio del provider e lo stato, il timestamp di registrazione, l'errore originale, l'ID di correlazione e l'ID della risorsa interessata. Non includere i token di accesso.

L'aggiornamento non riesce

Symptoms

Un aggiornamento automatico o richiesto di un'estensione rimane in sospeso o fallisce.
I pod di estensione diventano malsani durante o dopo un upgrade.

Cause

Le cause comuni includono problemi di compatibilità con Kubernetes, capacità di aggiornamento insufficiente, download delle immagini bloccato, criteri di ammissione, vincoli di interruzione dei pod o un'estensione pre-aggiornamento non integra.

Diagnostica

Registra la versione di estensione, il release train, l'impostazione automatica della versione minore, lo stato di provisioning e il messaggio di stato.

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --name <EXTENSION_NAME> --output yaml

Confronta le versioni attuali e target con le note di rilascio dell'estensione Container Apps.
Controlla la capacità dei nodi, i pod di estensione, gli eventi, i pull di immagini e i messaggi relativi alle interruzioni.
```
kubectl get nodes
kubectl get pods -n <NAMESPACE> -o wide
kubectl get events -n <NAMESPACE> --sort-by=.lastTimestamp
```

Risolvi

Ripristinare il corretto stato delle estensioni e una capacità di aggiornamento adeguata, quindi correggere i problemi di connettività del Registro di sistema o i blocchi dovuti ai criteri riportati negli eventi. Non modificare manualmente i carichi di lavoro Kubernetes gestiti dalle estensioni né tentare un rollback non documentato. Prima di modificare il canale di rilascio, l'impostazione di aggiornamento automatico o la versione dell'estensione, verifica con il supporto Microsoft il percorso di aggiornamento supportato.

Verify

Esegui az k8s-extension show e conferma che il provisioning abbia successo nella versione supportata prevista. Confermare che tutti i pod di estensione si stabilizzino e che le operazioni di ambiente connesso e applicazione abbiano successo.

Escalare

Raccogli l'output delle estensioni sanitate, le versioni attuali e target, il release train, la versione Kubernetes, la capacità dei nodi, gli eventi, i pod log guasti, l'ora di inizio dell'aggiornamento e gli ID di correlazione. Non includere impostazioni protette o credenziali del registro.

Commenti e suggerimenti

Questa pagina è stata utile?

Ultimo aggiornamento: 2026-09-22