Problembehandlung für Azure Container Apps in für Azure Arc aktiviertem Kubernetes

Die Fehlerbehebung von Container-Apps in Azure Arc erfordert die Überprüfung sowohl der Azure-Ressourcenbereitstellung als auch des Kubernetes-Laufzeitstatus. Beginnen Sie mit der Abhängigkeit, die dem Cluster am nächsten ist, und fahren Sie in folgender Reihenfolge fort:

Gesundheit und Kapazität von Kubernetes-Clustern.
Konnektivität verbundener Azure Arc-Cluster.
Container Apps-Erweiterungsbereitstellung und -Pods.
Benutzerdefinierte Standortbereitstellung.
Bereitstellung vernetzter Umgebungen und Ingress.
Container-App oder Job-Provisionierung.
Anwendungs-DNS, Netzwerkpfad und Laufzeitverhalten.

Erstelle nicht immer wieder spätere Ressourcen, während eine frühere Abhängigkeit ungesund ist.

Erfassen von Diagnosen

Ersetze die Ressourcen-Platzhalter durch die Werte, die du während der Installation verwendet hast, und sammle dann den Azure-Ressourcenzustand. Verwenden Sie <NAMESPACE> für den Namespace der Erweiterungsversion und <APPS_NAMESPACE> für den Namespace der Anwendungsworkload.

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

Sammeln Sie den Kubernetes-Status aus dem 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

Überprüfen Sie alle Ergebnisse, bevor Sie sie teilen. Entfernen Sie Token, gemeinsame Schlüssel, Registrierungspasswörter, Geheimnisse, Autorisierungsheader, Zertifikatsdaten und nicht zusammenhängende Kundendaten. Teile nicht die Werte der Erweiterungsschutz-Einstellungen. Wenn Sie unsicher sind, ob ein Feld sensible Daten enthält, entfernen Sie es und teilen Sie dem Microsoft-Support mit, welches Feld Sie ausgelassen haben.

Verbundener Cluster ist noch nicht bereit

Symptome

Der verbundene Cluster meldet keinen erfolgreichen Bereitstellungszustand oder einen verbundenen Status.
Azure-Operationen gegen den Cluster schlagen fehl oder werden ausgemustert.

Ursache

Häufige Ursachen sind ungesunde Azure Arc-Agenten, blockierte ausgehende Konnektivität, nicht unterstützte Proxy- oder TLS-Inspektionskonfiguration, falsche Systemzeit oder ein nicht registrierter Ressourcenanbieter.

Diagnose

Führen Sie folgenden Befehl aus und überprüfen Sie die Bereitstellungs- und Konnektivitätsfelder:
```
az connectedk8s show --resource-group <RESOURCE_GROUP> --name <CLUSTER_NAME> --output yaml
```

Sehen Sie sich die Azure Arc-Agenten und aktuelle Ereignisse an:

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

Überprüfen Sie, ob der Cluster die erforderlichen Azure Arc-fähigen Kubernetes-Endpunkte über die konfigurierte Firewall und den Proxy erreichen kann.

Überprüfen Sie, dass die Cluster-Knoten eine genaue Zeit haben und die erforderlichen Anbieter registriert sind:

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

Lösen

Stelle die Arc-Agenten und die erforderliche ausgehende Verbindung wieder her, bevor du die Ressourcen von Container Apps wechselst. Korrekte Proxy-Ausschlüsse, TLS-Inspektion, DNS oder Zeitsynchronisation gemäß den Azure Arc-Anforderungen. Registrieren Sie jeden Anbieter, der NotRegistered meldet.

Überprüfen

Führen Sie erneut aus az connectedk8s show und bestätigen Sie, dass die Bereitstellung erfolgreich ist und die Verbindung wiederhergestellt ist. Bestätigen Sie, dass alle Pods im Namensraum azure-arc bereit sind.

Eskalieren

Sammeln Sie die ID der verbundenen Clusterressource, die bereinigte Ausgabe von az connectedk8s show, den Status des Arc-Agent-Pods, Ereignisse und den betroffenen Zeitraum. Fügen Sie keine kubeconfig-Inhalte, Token oder Proxy-Zugangsdaten hinzu.

Die Installation der Verlängerung fehlschlägt oder läuft aus

Symptome

Der Bereitstellungsstatus der Erweiterung steht weiterhin aus oder meldet einen Fehler.
Der Wartebefehl zur Installation endet, aber die Erweiterung ist noch nicht bereit.

Ursache

Häufige Ursachen sind eine nicht unterstützte Kubernetes-Version oder Node-Architektur, unzureichende Kapazität, Fehler bei Image-Pulls, Ablehnungen von Zulassungsrichtlinien, Namensraumkonflikte, eine bestehende KEDA-Installation oder ein nicht verfügbarer Load Balancer.

Diagnose

Überprüfen Sie den vollständigen Status und die Statusmeldung der Erweiterung:

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

Überprüfen Sie Knoten, Erweiterungs-Pods, Scheduling-Ereignisse und Image-Pulls:

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

Prüfen Sie auf eine bestehende KEDA-Installation:
```
kubectl get deployment -A | grep -i keda
```
Bestätigen Sie, dass der Release-Namespace der Erweiterung und der konfigurierte Anwendungs-Namespace übereinstimmen, und überprüfen Sie die LoadBalancer Dienste:
```
kubectl get services -n <NAMESPACE>
```

Lösen

Korrigiere das erste gemeldete Abhängigkeitsproblem. Clusterkapazität freigeben, die Konnektivität zur Image-Registry korrigieren, die Admission-Richtlinie mit dem Verantwortlichen für die Cluster-Richtlinie abstimmen oder Namespace-Konflikte beheben. Wenn KEDA bereits existiert, stoppen Sie und bestätigen Sie die unterstützte Koexistenzkonfiguration, bevor Sie fortfahren. Entferne nicht die bestehende KEDA-Installation und wende keine undokumentierten Erweiterungseinstellungen an, da andere Arbeitslasten davon abhängen könnten. Lösche nicht den benutzerdefinierten Standort oder die verbundene Umgebung, um einen Fehler in der Erweiterung zu beheben. Wenn nach Behebung der Ursache eine Erweiterungsentfernung erforderlich ist, überprüfen Sie die Auswirkungen und verwenden Sie vor der Neuinstallation den unterstützten az k8s-extension delete Befehl.

Überprüfen

Führen Sie az k8s-extension show aus und bestätigen Sie, dass der Bereitstellungszustand Succeeded ist. Stelle sicher, dass die Verlängerungspods laufen und einsatzbereit sind, bevor du einen benutzerdefinierten Standort erstellst.

Eskalieren

Sammle bereinigte Erweiterungsstatus, Release-Train und -Version, Kubernetes-Version, Node-Betriebssystem und -Architektur, Namespace-Events und fehlerhafte Pod-Logs. Fügen Sie keine geschützten Einstellungen oder Registrierungsdaten hinzu.

Erweiterungspods sind ausstehend oder werden neu gestartet

Symptome

Ein oder mehrere Erweiterungs-Pods sind noch Pending, CrashLoopBackOff, ImagePullBackOff oder OOMKilled.
Durch Erweiterungen unterstützte Vorgänge sind nicht verfügbar oder nur zeitweise verfügbar.

Ursache

Pods können aufgrund unzureichender CPU oder Speicher, Knotenverunreinigungen oder Affinitätsregeln, Image-Pull-Einschränkungen, Volumenausfällen, Zulassungsrichtlinien oder Startfehlern bei Komponenten ausfallen.

Diagnose

Vergleichen Sie die betroffene Komponente mit den erwarteten Erweiterungskomponenten und Ressourcenanfragen in Resources, die von der Container Apps-Erweiterung erstellt werden.

Beschreiben Sie den Pod und inspizieren Sie die Planungs- und Containerzustände:

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

Für einen neu startenden Pod erfassen Sie aktuelle und frühere Protokolle:

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

Lösen

Beheben Sie den in den Pod-Events angezeigten Zustand. Hinzufüge zuweisende Kapazität, korrigiere Verunreinigungen oder Platzierungsbeschränkungen, stell den Registrierungszugriff wieder her, repariere Volumenabhängigkeiten oder passe eine genehmigte Policy-Ausnahme an. Bearbeiten Sie nicht direkt von Erweiterungen verwaltete Deployments, da die Erweiterung diese Änderungen überschreiben kann.

Überprüfen

Führe kubectl getpods -n <NAMESPACE> aus und bestätige, dass alle erwarteten Pods laufen und einsatzbereit sind, ohne dass sich die Anzahl der Neustarts erhöht.

Eskalieren

Sammle bereinigte Pod-Beschreibungen, Ereignisse, aktuelle und vorherige Protokolle, zuweisbare Ressourcen des Knotens und die Erweiterungsversion. Fügen Sie keine Kubernetes-Geheimnisse oder Umgebungsvariablen hinzu.

Die Erstellung benutzerdefinierter Standorte schlägt fehl

Symptome

az customlocation create schlägt fehl.
Der benutzerdefinierte Standort gelangt nicht in einen Succeeded Bereitstellungszustand.

Ursache

Häufige Ursachen sind eine deaktivierte Funktion für benutzerdefinierte Standorte, falsche Erweiterungs-ID, eine Namensraum-Fehlanpassung, Berechtigungen zwischen Dienstkonto und Azure RBAC, Anbieterregistrierung oder eine veraltete fehlgeschlagene Ressource.

Diagnose

Bestätigen Sie, dass der verbundene Cluster und die Erweiterung fehlerfrei sind.

Holen Sie die Erweiterungs-ID ab und vergleichen Sie sie mit der ID, die zur Erstellung des benutzerdefinierten Standorts verwendet wurde:

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

Bestätigen Sie, dass der benutzerdefinierte Standortnamensraum mit dem Erweiterungs-Release-Namensraum und dem konfigurierten Anwendungsnamensraum übereinstimmt.
Überprüfen Sie Microsoft.ExtendedLocation die Registrierung und aktivieren Sie gegebenenfalls benutzerdefinierte Standorte im Cluster.

Lösen

Korrigieren Sie die Erweiterungs-ID, den Namensraum, die Funktionsaktivierung, die Anbieterregistrierung oder die Berechtigungen. Versuchen Sie die Erstellung erst erneut, nachdem die Erweiterung fehlerfrei ist. Bevor Sie einen fehlgeschlagenen benutzerdefinierten Standort entfernen, überprüfen Sie, dass keine angeschlossene Umgebung davon abhängt.

Überprüfen

Führen Sie az customlocation show aus und bestätigen Sie, dass provisioningStateSucceeded ist und die erwartete Cluster-Erweiterungs-ID sowie der Namespace vorhanden sind.

Eskalieren

Erfassen Sie die Ausgabe des bereinigten benutzerdefinierten Standorts, die Ressourcen-IDs des verbundenen Clusters und der Erweiterung, den Namespace, die Providerzustände, den Fehlertext und die Korrelations-ID. Fügen Sie keine Zugriffstoken oder KubeConfig-Inhalte hinzu.

Die Erstellung von verbundenen Umgebungen scheitert

Symptome

az containerapp connected-env create Scheitert oder läuft ab.
Die verbundene Umgebung befindet sich weiterhin in einem fehlgeschlagenen oder ausstehenden Zustand.

Ursache

Häufige Ursachen sind ein ungesunder benutzerdefinierter Standort oder eine Erweiterung, eine nicht unterstützte Azure-Metadatenregion, fehlende Microsoft.App Registrierung oder eine ungültige Konfiguration des Umgebungsnamens oder der Domain.

Diagnose

Vergewissern Sie sich, dass der Bereitstellungsstatus des benutzerdefinierten Standorts und der Erweiterung Succeeded lautet.

Überprüfen Sie die verbundene Umgebung und den Anbieterzustand.

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

Vergleichen Sie die ausgewählte Azure-Region mit den unterstützten Regionen in Azure Container Apps unter den Azure Arc-Einschränkungen.

Lösen

Reparieren Sie zuerst den benutzerdefinierten Standort oder die Verlängerung. Registrieren Sie sich bei Bedarf unter Microsoft.App und versuchen Sie dann den Vorgang in der verbundenen Umgebung mit einer unterstützten Region und einem gültigen Namen erneut. Erstellen Sie den benutzerdefinierten Standort nicht neu, wenn er funktionsfähig ist.

Überprüfen

Führe az containerapp connected-env show aus und bestätige, dass provisioningStateSucceeded ist und die benutzerdefinierte Standortreferenz korrekt ist.

Eskalieren

Erfassen Sie die bereinigte Ausgabe der verbundenen Umgebung, des benutzerdefinierten Standorts und der Erweiterung sowie die Azure-Region, die Ressourcen-IDs und die Korrelations-ID. Fügen Sie keine Geheimnisse oder Autorisierungsheader hinzu.

Der Ingress-Dienst hat keine externe IP

Symptome

Der Ingress-Dienst der Erweiterung LoadBalancer zeigt eine externe IP-Adresse von <pending>.
Die verbundene Umgebung wird erstellt, aber keine erreichbare Ingress-Adresse ist verfügbar.

Ursache

Der Kubernetes-Cluster könnte keine funktionierende LoadBalancer Implementierung haben, sein Adresspool könnte erschöpft sein, die angeforderte Adresse könnte nicht verfügbar sein oder Firewall- sowie Health-Probe-Datenverkehr könnten blockiert sein.

Diagnose

Listen Sie die Dienste auf und identifizieren Sie den Erweiterungseingangsdienst:
```
kubectl get services -n <NAMESPACE> -o wide
```

Beschreiben Sie diesen Service und überprüfen Sie seine Veranstaltungen:

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

Stellen Sie sicher, dass der Load Balancer des Clusters eine verfügbare Adresse hat und die erforderlichen Integritätstests und Datenverkehr zulässt.
Für AKS auf Azure Local überprüfen Sie die Load Balancer-Konfiguration und die benutzerdefinierte CoreDNS-Voraussetzung.

Lösen

Konfigurieren oder reparieren Sie den unterstützten Load Balancer von Kubernetes, stellen Sie eine verfügbare Adresse bereit, und lassen Sie den entsprechenden Integritätstestpfad zu. Wenn die Installation die Erweiterungseinstellung loadBalancerIp verwendet hat, bestätigen Sie, dass die Adresse reserviert und dem Load Balancer zugewiesen ist, bevor Sie die Erweiterungskonfiguration ändern.

Überprüfen

Führen Sie kubectl get services -n <NAMESPACE> aus und bestätigen Sie, dass der Ingress-Dienst die erwartete externe IP aufweist. Teste die Erreichbarkeit dieser Adresse vom vorgesehenen Client-Netzwerk aus.

Eskalieren

Erfassen Sie die bereinigte Servicebeschreibung, Ereignisse, die Implementierung des Load Balancers und die Konfiguration des Adresspools, den Status der Integritätsprüfung und den Firewallpfad. Füge keine Zertifikate oder Qualifikationen bei.

Der Anwendungseingang ist nicht erreichbar

Symptome

Der vollständig qualifizierte Domänenname (FQDN) der Anwendung wird nicht aufgelöst, es kommt zu einer Zeitüberschreitung, oder es wird eine unerwartete HTTP- oder TLS-Antwort zurückgegeben.
Direkter Zugriff auf die Ingress-Adresse funktioniert, aber der Hostname der Anwendung nicht.

Ursache

Häufige Ursachen sind ein fehlender Wildcard-DNS-Eintrag, Unterschiede im Client-DNS, blockiertes Routing, Zertifikats- oder TLS-Probleme, eine ungesunde Ingress-Komponente, falscher Zielport, fehlgeschlagene Anwendungsproben oder interner Eingang.

Diagnose

Rufen Sie die konfigurierten FQDN- und Ingress-Einstellungen ab.

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

Lösen Sie den FQDN aus dem betroffenen Clientnetzwerk auf, und fragen Sie ihn von dort ab.
```
nslookup <APPLICATION_FQDN>
curl --verbose https://<APPLICATION_FQDN>
```
Überprüfen Sie, ob das Ergebnis auf die eingehende IP der Erweiterung aufgelöst wird. Überprüfen Sie Ingress-Pods, Dienste, Anwendungs-Pods und Probe-Events.

Lösen

Erstellen oder korrigieren Sie den Wildcard-DNS-Eintrag für die Connected-Environment-Domäne, stellen Sie den Client-Netzwerkpfad wieder her, korrigieren Sie die Zertifikatskonfiguration oder korrigieren Sie den Zielport und die Sonden der Anwendung. Wenn der Ingress intern ist, testen Sie von einem Netzwerk aus, das den internen Load Balancer erreichen kann, anstatt ihn als Fehlerbehebungsabkürzung bereitzustellen.

Überprüfen

Lösen Sie das Anwendungs-FQDN aus jedem beabsichtigten Client-Netzwerk auf und bestätigen, dass eine HTTP- oder HTTPS-Anfrage die erwartete Anwendungsantwort zurückgibt.

Eskalieren

Sammeln Sie FQDN, DNS-Ergebnis, Ingress-IP, bereinigte Verbose-Anfrage-Ausgabe, Ingress- und Anwendungspod-Status, Probe-Ereignisse und den betroffenen Client-Standort. Entferne Autorisierungsheader, Cookies und zerfiziere private Daten.

Die Überarbeitung ist noch nicht fertig

Symptome

Eine neue Überarbeitung ist noch nicht fertig.
Die Anwendung hat keine bereiten Repliken oder befindet sich weiterhin im Bereitstellungszustand.

Ursache

Häufige Ursachen sind ein inkompatibles Image oder eine inkompatible Architektur, ungültige Registrierungsdatendaten, ein falscher Startbefehl oder -port, fehlgeschlagene Proben, unzureichende Ressourcen, Volume-Mounting-Fehler oder fehlende geheime Referenzen.

Diagnose

Inspizieren Sie den Antrag und den Überprüfungsstatus:

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

Untersuchen Sie die betroffenen Kapseln, Ereignisse und Protokolle:

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

Lösen

Korrigiere das Image und die Registrierungsdaten, den Startbefehl, den Zielport, die Sonden, die angeforderten Ressourcen, die Volume-Konfiguration oder die durch die Ereignisse identifizierte geheime Referenz. Bereite die korrigierte Anwendungskonfiguration als neue Version aus. Bearbeiten Sie Revisions-Pods nicht direkt.

Überprüfen

Führen Sie az containerapp revision list aus und bestätigen Sie, dass die neue Revision aktiv und fehlerfrei ist und über bereite Replikate verfügt. Senden Sie eine Anfrage an die Anwendung, wenn Ingress aktiviert ist.

Eskalieren

Erfassen Sie bereinigte Anwendungs- und Revisionskonfiguration, Pod-Beschreibungen, Ereignisse, Protokolle, Image-Name und -Architektur sowie die Erweiterungsversion. Fügen Sie keine Registrierungspasswörter oder geheime Werte hinzu.

Die Anwendung skaliert nicht

Symptome

Die Anzahl der Replikate reagiert weder auf Last noch auf eine Ereignisquelle.
Die Anwendung startet nicht ausgehend von null Replikaten.
Die gewünschten Replikate stehen weiterhin aus.

Ursache

Häufige Ursachen sind fehlerhafte KEDA-Komponenten, eine ungültige Authentifizierung des Scalers, eine nicht erreichbare Triggerquelle, eine falsche Mindest- oder Höchstanzahl von Replikaten, unzureichende Clusterkapazität oder ein nicht verfügbarer Aktivierungspfad für die Skalierung von null.

Diagnose

Überprüfen Sie die Skalierungskonfiguration und den Revisionszustand der Anwendung.

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

Schau dir KEDA und Skalierungskomponenten, Anwendungspods und Events an.

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

Teste die Trigger-Quell-Konnektivität vom Cluster, ohne Authentifizierungswerte auszudrucken.

Lösen

KEDA-Gesundheit wiederherstellen, die Skalierungsregel und ihre geheimen Referenzen korrigieren, Zugriff auf die Triggerquelle erlauben oder planierbare Clusterkapazität hinzufügen. Bestätigen Sie, dass die maximale Replik-Einstellung höher als die Mindestgröße ist und die verfügbare Clusterkapazität nicht überschreitet.

Überprüfen

Erzeugen Sie einen kontrollierten Auslöser oder eine kontrollierte Anfragelast und bestätigen Sie, dass die Anzahl der einsatzbereiten Replikate zunimmt und später wieder auf das konfigurierte Minimum zurückgeht. Vergewissern Sie sich bei einer Skalierung auf null, dass ein neuer Trigger ein Replikat aktiviert und erfolgreich ausgeführt wird.

Eskalieren

Erfassen Sie die bereinigte Skalierungskonfiguration, den Revisionsstatus, den Status und die Protokolle des KEDA-Pods, Anwendungsereignisse, den Triggertyp und Testzeitstempel. Fügen Sie keine Scaler-Anmeldeinformationen oder Nachrichtennutzlasten hinzu.

Job startet nicht oder wird nicht abgeschlossen

Symptome

Eine manuelle, geplante oder ereignisgesteuerte Aufgabe startet nicht.
Eine Ausführung wird weiterhin ausgeführt, wird wiederholt neu versucht oder endet mit einem Fehler.

Ursache

Häufige Ursachen sind falsche Trigger-Konfiguration, Zeitplan oder Authentifizierung, Parallelitäts- und Abschlusseinstellungen, Retry- oder Timeout-Verhalten, Image-Pull-Fehler, unzureichende Kapazität oder Anwendungsfehler.

Diagnose

Überprüfen Sie den Auftrag und die letzten Ausführungen:

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

Überprüfen Sie die Ausführungspods, Ereignisse und Protokolle im Anwendungsnamespace:

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

Lösen

Korrigieren Sie folgende Komponenten: Trigger, Zeitplan, Authentifizierungsreferenz, Replikatabschlussanzahl, Parallelität, Wiederholungslimit, Zeitüberschreitung, Image oder Ressourcenanforderung, die durch die Ausführung und Kubernetes-Ereignisse angezeigt werden. Fügen Sie Clusterkapazität hinzu, wenn die Ausführungspods weiterhin ausstehen. Speichern Sie Daten zur fehlgeschlagenen Ausführung, bis die erforderlichen Protokolle gesammelt sind.

Überprüfen

Starte oder warte auf eine kontrollierte Ausführung und vergewissere dich, dass der erwartete Fertigstellungszustand erreicht ist. Überprüfen Sie, ob die Ausgabe und die entsprechenden Nebenwirkungen korrekt sind. Konzipieren Sie die Jobverarbeitung so, dass sie idempotent ist, da Wiederholungsversuche und Ereigniszustellung dazu führen können, dass Vorgänge mehr als einmal ausgeführt werden.

Eskalieren

Erfassen Sie die bereinigte Jobkonfiguration, den Ausführungsverlauf, die Pod-Beschreibung, Ereignisse, Protokolle, den Triggertyp und Zeitstempel. Fügen Sie keine Trigger-Zugangsdaten, Payload-Daten oder Geheimnisse hinzu.

Logs fehlen

Symptome

Anwendungsprotokolle erscheinen nicht im konfigurierten Log Analytics-Arbeitsbereich.
kubectl logs Funktioniert, aber die Workspace-Abfrage liefert keine Datensätze.

Ursache

Log Analytics ist möglicherweise während der Installation der Erweiterung nicht konfiguriert, der Log-Prozessor ist deaktiviert oder ungesund, der falsche Arbeitsbereich wird abgefragt, die Eingabe verzögert oder die Abfrage verwendet eine falsche Tabelle oder ein falsches Feld.

Diagnose

Inspizieren Sie die Erweiterungskonfiguration, ohne geschützte Einstellungen anzufordern, und überprüfen Sie das beabsichtigte Log-Ziel:

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

Überprüfen Sie die Log-Prozessor-Pods und die aktuellen Protokolle:

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

Bestätigen Sie, dass die Anwendungsausgabe auf der Kubernetes-Ebene existiert:

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

Im konfigurierten Arbeitsbereich führe eine breite Abfrage aus, bevor du nach Anwendungsfeldern filterst:
```
ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(1h)
| take 100
```

Lösen

Fragen Sie den Arbeitsbereich ab, der bei der Installation der Erweiterung konfiguriert wurde, stellen Sie fehlerhafte Log-Processor-Pods wieder her, indem Sie ihre gemeldete Abhängigkeit korrigieren, und korrigieren Sie die Abfragetabelle oder die Felder. Du kannst Log Analytics nach der Installation nicht mehr zu einer bestehenden Erweiterung hinzufügen. Wenn die Erweiterung nicht für Log Analytics konfiguriert war, verwenden Sie Kubernetes-Logging oder planen Sie eine unterstützte Neuinstallation der Erweiterung nach Überprüfung der Auswirkungen. Die Einstellung logProcessor.enabled=false deaktiviert die Protokollverarbeitung und die Workspace-Weiterleitung.

Überprüfen

Schreibe eine eindeutige Testnachricht zur Standardausgabe der Anwendung. Bestätigen Sie, dass es in kubectl logs angezeigt wird und, wenn Log Analytics konfiguriert ist, dass es nach der normalen Aufnahmeverzögerung im Arbeitsbereich erscheint.

Eskalieren

Sammeln Sie die Ressourcen-ID des Workspace, die bereinigte Erweiterungskonfiguration, den Status und die Protokolle des Log-Processor-Pods, die Zeitstempel der Anwendungs- und Testnachrichten sowie den Abfragetext. Füge nicht den Workspace-Shared-Schlüssel oder die Anwendungsprotokolldaten ein, die nicht mit dem Problem zusammenhängen.

Fehler bei der Anbieterregistrierung

Symptome

Eine Operation gibt No registered resource provider found zurück.
Ein erforderlicher Anbieter bleibt NotRegistered oder Registering.

Ursache

Das aktive Abonnement hat die Registrierung für einen Anbieter nicht abgeschlossen, der für den verbundenen Cluster, die Erweiterung, den benutzerdefinierten Standort, die verbundene Umgebung oder die Log Analytics-Konfiguration erforderlich ist.

Diagnose

Bestätigen Sie das aktive Abonnement:

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

Überprüfen Sie alle Anbieter, die vom Einrichtungspfad genutzt werden:

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

Lösen

Registrieren Sie jeden Anbieter, der nicht registriert ist. Beispiel:

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

Die Anbieterregistrierung kann mehrere Minuten dauern. Erstellen Sie Ressourcen nicht wiederholt neu, solange die Registrierung noch läuft. Wenn die Erstellung der verbundenen Umgebung No registered resource provider found zurückgibt, während Microsoft.App bereits Registered meldet, registrieren Sie Microsoft.App mit dem vorherigen Befehl erneut und versuchen Sie den Vorgang dann erneut. Die Neuregistrierung des Anbieters beeinflusst keine bestehenden Anwendungen oder APIs.

Überprüfen

Führe az provider show--namespace <PROVIDER_NAMESPACE> --query registrationState --output tsv aus und bestätige, dass Registered zurückgegeben wird. Versuchen Sie die ursprüngliche Operation im selben Abonnement erneut.

Eskalieren

Sammeln Sie die Abonnement-ID, den Anbieter-Namensraum und -staat, den Registrierungszeitstempel, den ursprünglichen Fehler, die Korrelations-ID und die betroffene Ressourcen-ID. Fügen Sie keine Zugangstoken hinzu.

Upgrade schlägt fehl

Symptome

Ein automatisches oder angefordertes Verlängerungsupgrade bleibt ausstehend oder schlägt fehl.
Erweiterungskapseln werden während oder nach einem Upgrade ungesund.

Ursache

Häufige Ursachen sind Kubernetes-Kompatibilität, unzureichende Upgrade-Kapazität, blockierte Bildabrufe, Zulassungsrichtlinien, Pod-Störungsbeschränkungen oder eine ungesunde Pre-Upgrade-Erweiterung.

Diagnose

Erfassen Sie die Erweiterungsversion, den Releasekanal, die Einstellung für automatische Nebenversionen, den Bereitstellungszustand und die Statusmeldung.

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

Vergleichen Sie die aktuellen und Zielversionen mit den Release Notes der Container Apps Erweiterung.

Überprüfen Sie die Knotenkapazität, Erweiterungskapseln, Ereignisse, Bildabrufe und störungsbezogene Nachrichten.

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

Lösen

Stellen Sie die Integrität der Erweiterung und eine ausreichende Upgradekapazität wieder her, und beheben Sie dann Probleme mit der Registrierungsverbindung oder Richtlinienverweigerungen, die in Ereignissen gemeldet werden. Ändern Sie nicht manuell die von Erweiterungen verwalteten Kubernetes-Workloads und versuchen Sie keinen undokumentierten Rollback. Bevor Sie den Release-Zug, die automatische Upgrade-Einstellung oder die Erweiterungsversion ändern, überprüfen Sie den unterstützten Pfad mit Microsoft-Unterstützung.

Überprüfen

Führen Sie aus az k8s-extension show und bestätigen Sie, dass die Bereitstellung in der beabsichtigten unterstützten Version erfolgreich ist. Vergewissern Sie sich, dass alle Erweiterungspods einen stabilen Zustand erreichen und dass die Umgebungsverbindungs- und Anwendungsvorgänge erfolgreich ausgeführt werden.

Eskalieren

Erfassen Sie die bereinigte Erweiterungsausgabe, die aktuellen und Zielversionen, den Release Train, die Kubernetes-Version, die Knotenkapazität, Ereignisse, Logs fehlschlagender Pods, die Startzeit des Upgrades und die Korrelations-IDs. Fügen Sie keine geschützten Einstellungen oder Registrierungsdaten hinzu.

Feedback

War diese Seite hilfreich?

Zuletzt aktualisiert um 2026-09-22