Rozwiązywanie problemów z Azure Container Apps w usłudze Kubernetes z obsługą usługi Azure Arc

Rozwiązywanie problemów z aplikacjami kontenerowymi na Azure Arc wymaga sprawdzenia zarówno Azure resource provisioning, jak i stanu uruchomienia Kubernetes. Zacznij od zależności najbliższej klastru i kontynuuj w następującej kolejności:

Zdrowie i pojemność klastra Kubernetes.
Łączność połączonego klastra usługi Azure Arc.
Aprowizowanie rozszerzenia Container Apps i pody.
Niestandardowe przydzielanie lokalizacji.
Aprowidzjonowanie środowiska połączonego i ruch przychodzący.
Aplikacja kontenerowa lub zlecenie pracy.
DNS aplikacji, ścieżka sieciowa i zachowanie w czasie uruchomienia.

Nie odtwarzaj wielokrotnie późniejszych zasobów, gdy wcześniejsza zależność jest niezdrowa.

Zbieranie danych diagnostycznych

Zastąp symbole zastępcze zasobów wartościami użytymi podczas instalacji, a następnie pobierz stan zasobów platformy Azure. Użyj <NAMESPACE> dla przestrzeni nazw wydania rozszerzenia oraz <APPS_NAMESPACE> dla przestrzeni nazw obciążenia aplikacji.

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

Pobierz stan Kubernetes z klastra:

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

Przejrzyj wszystkie wyniki przed udostępnieniem ich. Usuń tokeny, klucze współdzielone, hasła do rejestru, sekrety, nagłówki autoryzacji, dane certyfikatów oraz niepowiązane dane klientów. Nie podzielaj wartości ustawień chronionych rozszerzeniami. Jeśli nie jesteś pewien, czy pole zawiera wrażliwe dane, usuń je i powiadom wsparcie Microsoft, które pole pominąłeś.

Połączony klaster nie jest gotowy

Symptoms

Połączony klaster nie zgłasza poprawnego stanu udostępniania ani statusu połączenia.
Operacje platformy Azure na klastrze kończą się niepowodzeniem lub przekraczają limit czasu.

Przyczyna

Typowe przyczyny to niezdrowi agenci Azure Arc, zablokowana łączność wychodząca, nieobsługiwana konfiguracja inspekcji proxy lub TLS, nieprawidłowy czas systemowy lub niezarejestrowany dostawca zasobów.

Diagnozuj

Uruchom następujące polecenie i sprawdź pola udostępniania i łączności:

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

Sprawdź agentów Azure Arc i ostatnie wydarzenia:

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

Sprawdź, czy klaster może dotrzeć do wymaganych punktów końcowych Kubernetes z obsługą Azure Arc przez skonfigurowaną zaporę i proxy.

Sprawdź, czy węzły klastra mają dokładny czas oraz że wymagani dostawcy są zarejestrowani:

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

Rozwiąż

Przywróć agenty Arc i wymaganą łączność wychodzącą przed wprowadzeniem zmian w zasobach usługi Container Apps. Skoryguj wyłączenia serwera proxy, inspekcję TLS, ustawienia DNS lub synchronizację czasu zgodnie z wymaganiami usługi Azure Arc. Zarejestruj dowolnego dostawcę, który zgłasza NotRegistered.

Verify

Uruchom az connectedk8s show ponownie i potwierdź, że przydzielenie się powiodło i łączność została przywrócona. Potwierdź, że wszystkie pody w przestrzeni nazw azure-arc są gotowe.

Eskaluj

Zbierz identyfikator zasobu połączonego klastra, oczyszczone az connectedk8s show dane wyjściowe, stan kapsuły agenta Arc, zdarzenia oraz zakres czasu, którego dotyczy problem. Nie dołączaj zawartości pliku kubeconfig, tokenów ani danych uwierzytelniających serwera proxy.

Instalacja rozszerzenia nie powodzi się lub przekracza limit czasu

Symptoms

Stan udostępniania rozszerzenia pozostaje w toku lub zgłasza niepowodzenie.
Polecenie oczekiwania na instalację kończy się, ale rozszerzenie nie jest gotowe.

Przyczyna

Typowe przyczyny to nieobsługiwana wersja lub architektura węzła Kubernetes, niewystarczająca pojemność, niepowodzenia pobierania obrazów, odmowy polityki dopuszczenia, konflikty w przestrzeniach nazw, istniejąca instalacja KEDA lub niedostępny load balancer.

Diagnozuj

Sprawdź pełny status rozszerzenia i komunikat o stanie:

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

Sprawdź węzły, pody rozszerzeń, zdarzenia harmonogramowania i pobieranie obrazów:

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

Sprawdź istniejącą instalację KEDA:

kubectl get deployment -A | grep -i keda

Potwierdź, że przestrzeń nazw wersji rozszerzenia i skonfigurowana przestrzeń nazw aplikacji są zgodne, oraz sprawdź usługi LoadBalancer:
```
kubectl get services -n <NAMESPACE>
```

Rozwiąż

Popraw pierwszy zgłoszony problem zależności. Dostępna pojemność klastra, prawidłowa łączność z rejestrem obrazów, uzgodnienie polityki dopuszczania z właścicielem polityki klastra lub rozwiązanie konfliktów przestrzeni nazw. Jeśli KEDA już istnieje, zatrzymaj się i potwierdź obsługiwaną konfigurację współistnienia przed kontynuacją. Nie usuwaj istniejącej instalacji KEDA ani nie stosuj ustawień nieudokumentowanych rozszerzeń, bo inne obciążenia mogą od tego zależeć. Nie usuwaj niestandardowej lokalizacji ani środowiska połączonego, żeby naprawić awarię rozszerzenia. Jeśli po usunięciu przyczyny konieczne jest usunięcie rozszerzenia, przejrzyj wpływ i użyj obsługiwanego az k8s-extension delete polecenia przed ponowną instalacją.

Verify

Uruchom az k8s-extension show i potwierdź, że stan aprowizacji to Succeeded. Upewnij się, że kapsuły rozszerzeniowe działają i są gotowe, zanim utworzysz niestandardową lokalizację.

Eskaluj

Zbieraj zanonimizowany stan rozszerzenia, kanał wydawniczy i wersję, wersję Kubernetes, system operacyjny i architekturę węzła, zdarzenia przestrzeni nazw oraz dzienniki podów, których działanie kończy się niepowodzeniem. Nie dodawaj chronionych ustawień ani danych logowania rejestru.

Pody rozszerzeń oczekują lub uruchamiają się ponownie

Symptoms

Jeden lub więcej modułów rozszerzeń pozostają w stanie Pending, CrashLoopBackOff, ImagePullBackOff lub OOMKilled.
Operacje wspierane przez rozszerzenie są niedostępne lub są przerywane.

Przyczyna

Pody mogą ulec awarii z powodu niewystarczającego CPU lub pamięci, zanieczyszczeń węzłów lub reguł powinowactwa, ograniczeń w pobieraniu obrazu, awarii woluminów, polityki admitacji lub błędów uruchamiania komponentów.

Diagnozuj

Porównaj dotknięty komponent z oczekiwanymi komponentami rozszerzenia oraz żądaniami zasobów w Zasobach utworzonych przez rozszerzenie Container Apps.

Opisz kapsułę i sprawdź stany harmonogramu i kontenera:

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

Dla poda, który uruchamia się ponownie, zbierz aktualne i poprzednie logi:

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

Rozwiąż

Rozwiąż problem widoczny w zdarzeniach poda. Dodać dostępną pojemność, poprawić tainty lub ograniczenia rozmieszczania, przywrócić dostęp do rejestru, naprawić zależności woluminów lub dostosować zatwierdzony wyjątek od zasad. Nie edytuj bezpośrednio wdrożeń zarządzanych przez rozszerzenia, ponieważ rozszerzenie może nadpisać te zmiany.

Verify

Uruchom kubectl getpods -n <NAMESPACE> i potwierdź, że wszystkie oczekiwane pody działają i są gotowe, bez zwiększania liczby restartów.

Eskaluj

Zbieraj zanonimizowane opisy podów, zdarzenia, bieżące i poprzednie logi, zasoby możliwe do przydzielenia na węzłach oraz wersję rozszerzenia. Nie uwzględniaj sekretów Kubernetes ani wartości zmiennych środowiskowych.

Tworzenie niestandardowych lokalizacji nie powiodło się

Symptoms

az customlocation create Nie powiedzie się.
Lokalizacja niestandardowa nie osiąga stanu Succeeded aprowizacji.

Przyczyna

Typowe przyczyny to wyłączona funkcja niestandardowych lokalizacji, nieprawidłowy identyfikator rozszerzenia, niedopasowanie przestrzeni nazw, uprawnienia konta serwisowego lub Azure RBAC, rejestracja dostawcy lub uszkodzony zasób.

Diagnozuj

Potwierdź, że połączony klaster i rozszerzenie działają prawidłowo.

Pobierz ID rozszerzenia i porównaj je z ID użytym do utworzenia niestandardowej lokalizacji:

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

Potwierdź, że niestandardowa przestrzeń nazw lokalizacji odpowiada przestrzeni nazw wersji rozszerzenia oraz skonfigurowanej przestrzeni nazw aplikacji.
Sprawdź Microsoft.ExtendedLocation rejestrację i w razie potrzeby włącz niestandardowe lokalizacje w klastrze.

Rozwiąż

Popraw ID rozszerzenia, przestrzeń nazw, możliwość włączenia funkcji, rejestrację dostawcy lub uprawnienia. Ponów tworzenie dopiero wtedy, gdy rozszerzenie będzie działać prawidłowo. Przed usunięciem nieudanej lokalizacji niestandardowej upewnij się, że nie korzysta z niej żadne połączone środowisko.

Verify

Uruchom az customlocation show i potwierdź, że provisioningState ma wartość Succeeded oraz że obecne są oczekiwane identyfikator rozszerzenia klastra i przestrzeń nazw.

Eskaluj

Zbierz dane wyjściowe oczyszczonej lokalizacji niestandardowej, identyfikatory zasobów połączonego klastra i rozszerzenia, przestrzeń nazw, stany dostawcy, tekst błędu oraz identyfikator korelacji. Nie uwzględniaj tokenów dostępu ani treści kubeconfig.

Tworzenie środowiska połączonego zawodzi

Symptoms

az containerapp connected-env create kończy się niepowodzeniem lub przekracza limit czasu.
Połączone środowisko pozostaje w stanie błędu lub oczekiwania.

Przyczyna

Typowe przyczyny to nieprawidłowa niestandardowa lokalizacja lub rozszerzenie, nieobsługiwany region metadanych Azure, brak rejestracji Microsoft.App albo nieprawidłowa nazwa środowiska lub konfiguracja domeny.

Diagnozuj

Potwierdź, że niestandardowe stany lokalizacji i rozszerzenia to Succeeded.

Sprawdź środowisko połączone i stan dostawcy.

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

Porównaj wybrany region platformy Azure z regionami obsługiwanymi w dokumencie Azure Container Apps on Azure Arc limitations.

Rozwiąż

Najpierw napraw niestandardową lokalizację lub rozszerzenie. Zarejestruj Microsoft.App się, jeśli jest to potrzebne, a następnie ponownie spróbuj operacji środowiska połączonego z obsługiwanym regionem i poprawną nazwą. Nie twórz ponownie lokalizacji niestandardowej, jeśli działa prawidłowo.

Verify

Uruchom az containerapp connected-env show i upewnij się, że provisioningState ma wartość Succeeded oraz że niestandardowe odwołanie do lokalizacji jest poprawne.

Eskaluj

Zbierz oczyszczone dane wyjściowe połączonego środowiska, lokalizacji niestandardowej i rozszerzenia; region platformy Azure; identyfikatory zasobów; oraz identyfikator korelacji. Nie dodawaj sekretów ani nagłówków autoryzacji.

Usługa Ingress nie ma zewnętrznego adresu IP

Symptoms

Usługa ingress rozszerzenia LoadBalancer ma zewnętrzny adres IP <pending>.
Środowisko połączone zostało utworzone, ale nie jest dostępny żaden osiągalny adres wejściowy.

Przyczyna

Klaster Kubernetes może nie mieć działającej LoadBalancer implementacji, pula adresów może być wyczerpana, żądany adres może być niedostępny, albo ruch firewall i health probe może być zablokowany.

Diagnozuj

Wymień usługi i zidentyfikuj usługę wejścia rozszerzenia:
```
kubectl get services -n <NAMESPACE> -o wide
```

Opisz tę usługę i przeanalizuj jej wydarzenia:

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

Potwierdź, że klastrowy balanser obciążenia ma dostępny adres i pozwala na wymagane sondy zdrowotne oraz ruch.
W przypadku AKS na platformie Azure lokalnie zweryfikuj konfigurację modułu równoważenia obciążenia oraz niestandardowe wymaganie wstępne dotyczące CoreDNS.

Rozwiąż

Skonfiguruj lub napraw obsługiwany moduł równoważenia obciążenia Kubernetes, udostępnij dostępny adres i zezwól na ścieżkę sondy kondycji. Jeśli instalacja używała ustawienia rozszerzenia loadBalancerIp , poupewnij się, że adres jest zarezerwowany i przypisany do load balancera przed zmianą konfiguracji rozszerzenia.

Verify

Uruchom kubectl get services -n <NAMESPACE> i potwierdź, że usługa Ingress ma oczekiwany zewnętrzny adres IP. Testuj dostępność do tego adresu z docelowej sieci klienta.

Eskaluj

Zbierz zanonimizowany opis usługi, zdarzenia, implementację modułu równoważenia obciążenia i konfigurację puli adresów, stan sondy kondycji oraz ścieżkę przez zaporę. Nie dołączaj certyfikatów ani uprawnień.

Ingress aplikacji nie jest osiągalny

Symptoms

W pełni kwalifikowana nazwa domenowa aplikacji (FQDN) nie jest rozwiązywana, przekracza limit czasu lub zwraca nieoczekiwaną odpowiedź HTTP lub TLS.
Bezpośredni dostęp do adresu wejściowego działa, ale nazwa hosta aplikacji nie.

Przyczyna

Typowe przyczyny to brak rekordu DNS typu wildcard, różnice w konfiguracji DNS klienta, zablokowany routing, problemy z certyfikatem lub protokołem TLS, nieprawidłowo działający komponent ingress, nieprawidłowy port docelowy, nieudane sondy kondycji aplikacji lub wewnętrzny ingress.

Diagnozuj

Pobierz skonfigurowane ustawienia FQDN i wejścia.

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

Rozwiązuj i żądaj FQDN od dotkniętej sieci klienckiej.

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

Potwierdź, że wynik wskazuje na adres IP ingressu rozszerzenia. Sprawdź pody Ingress, usługi, pody aplikacji i zdarzenia kontroli.

Rozwiąż

Utwórz lub popraw rekord DNS typu wildcard dla domeny połączonego środowiska, przywróć ścieżkę sieciową klienta, popraw konfigurację certyfikatu lub napraw port docelowy aplikacji i jej sondy. Jeśli ingress jest wewnętrzny, przeprowadzaj testy z sieci, która może połączyć się z wewnętrznym modułem równoważenia obciążenia, zamiast udostępniać go jako drogę na skróty podczas rozwiązywania problemów.

Verify

Rozwiąż FQDN aplikacji z każdej docelowej sieci klienckiej i potwierdź, że żądanie HTTP lub HTTPS zwraca oczekiwaną odpowiedź aplikacji.

Eskaluj

Zbierz nazwę FQDN, wynik DNS, adres IP zasobu ingress, oczyszczone szczegółowe dane wyjściowe żądania, stan podów ingressu i aplikacji, zdarzenia sond oraz lokalizację klienta, którego dotyczy problem. Usuń nagłówki autoryzacji, pliki cookie oraz prywatne dane certyfikatów.

Poprawka nie jest gotowa

Symptoms

Nowa wersja nie jest gotowa.
Aplikacja ma zero gotowych replik lub pozostaje w trakcie inicjowania.

Przyczyna

Typowe przyczyny to niekompatybilny obraz lub architektura, nieprawidłowe poświadczenia do rejestru, błędne polecenie startowe lub port, nieudane próby, niewystarczające zasoby, niepowodzenia montowania woluminów lub brakujące referencje do sekretów.

Diagnozuj

Sprawdź stan aplikacji i rewizji:

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

Sprawdź pody, których dotyczy problem, zdarzenia i logi:

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

Rozwiąż

Popraw poświadczenia dostępu do obrazu i rejestru, polecenie uruchamiania, port docelowy, sondy, żądane zasoby, konfigurację woluminu lub odwołanie do obiektu Secret wskazane przez zdarzenia. Wdroż poprawioną konfigurację aplikacji jako nową wersję. Nie edytuj bezpośrednio podów wersji.

Verify

Uruchom az containerapp revision list i potwierdź, że nowa rewizja jest aktywna, w dobrej kondycji i ma gotowe repliki. Wyślij żądanie do aplikacji, jeśli wejście jest włączone.

Eskaluj

Zbieraj oczyszczoną konfigurację aplikacji i wersji, opisy podów, zdarzenia, logi, nazwę obrazu i architekturę oraz wersję rozszerzenia. Nie podawaj haseł do rejestru ani wartości sekretów.

Aplikacja nie skaluje się

Symptoms

Liczba replik nie reaguje na obciążenie ani na źródło zdarzeń.
Aplikacja nie uruchamia się przy zerowej liczbie replik.
Pożądane repliki pozostają w oczekiwaniu.

Przyczyna

Typowe przyczyny to nieprawidłowo działające komponenty KEDA, nieprawidłowa konfiguracja uwierzytelniania skalerów, nieosiągalne źródło wyzwalacza, nieprawidłowo ustawiona minimalna lub maksymalna liczba replik, niewystarczające zasoby klastra lub niedostępny mechanizm aktywacji przy skalowaniu od zera.

Diagnozuj

Sprawdź konfigurację skali aplikacji i stan rewizji.

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

Sprawdź KEDA, składniki odpowiedzialne za skalowanie, pody aplikacji i zdarzenia.

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

Przetestuj łączność ze źródłem wyzwalacza z poziomu klastra bez wyświetlania danych uwierzytelniających.

Rozwiąż

Przywróć kondycję KEDA, popraw regułę skalowania i odwołania do sekretów, zezwól na dostęp do źródła wyzwalania lub dodaj zasoby klastra dostępne do planowania. Potwierdź, że maksymalna liczba replik jest większa niż minimalna i nie przekracza dostępnej pojemności klastra.

Verify

Wygeneruj kontrolowany bodziec wyzwalający lub obciążenie żądaniami i potwierdź, że liczba gotowych replik wzrasta, a następnie wraca do skonfigurowanego minimum. W przypadku skalowania do zera potwierdź, że nowy wyzwalacz aktywuje replikę i zakończy się pomyślnie.

Eskaluj

Zbieraj oczyszczoną konfigurację skali, stan wersji, status i logi kapsuły KEDA, zdarzenia aplikacji, typ wyzwalacza oraz znaczniki czasu testu. Nie dołączaj poświadczeń skalera ani ładunków wiadomości.

Praca się nie zaczyna ani nie kończy

Symptoms

Zadanie uruchamiane ręcznie, zaplanowane lub wyzwalane zdarzeniem nie uruchamia się.
Proces nadal działa, wielokrotnie ponawia próbę lub kończy się błędem.

Przyczyna

Typowe przyczyny to nieprawidłowa konfiguracja wyzwalaczy, harmonogram lub uwierzytelnianie, równoległość i ustawienia zakończenia, zachowanie powtórek lub limitu czasu, niepowodzenie pobierania obrazu, niewystarczająca pojemność lub awaria aplikacji.

Diagnozuj

Sprawdź zlecenie i ostatnie realizacje:

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

Sprawdź pody wykonawcze, zdarzenia i dzienniki w przestrzeni nazw aplikacji:

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

Rozwiąż

Popraw wyzwalacz, harmonogram, odniesienie uwierzytelniania, liczbę ukończenia replik, równoległość, limit powtórek, limit, czas oczekiwania, obraz lub żądanie zasobów wskazane przez zdarzenia wykonania i Kubernetes. Dodaj pojemność klastra, gdy kapsuły wykonawcze pozostają w trakcie oczekiwania. Przechowywać dane o nieudanych wykonaniach do czasu zebrania wymaganych logów.

Verify

Rozpocznij wykonanie kontrolowane lub poczekaj na nie i potwierdź, że osiąga oczekiwany stan zakończenia. Potwierdź, że jego efekt i skutki uboczne są prawidłowe. Zaprojektuj przetwarzanie zadań tak, aby było idempotentne, ponieważ ponowienia i dostarczanie zdarzeń mogą spowodować, że to samo zadanie zostanie wykonane więcej niż raz.

Eskaluj

Zbierz oczyszczoną konfigurację zadań, historię wykonania, opis kapsuły, zdarzenia, logi, typ wyzwalacza oraz znaczniki czasu. Nie uwzględniaj poświadczeń wyzwalacza, danych ładunku ani sekretów.

Brakuje dzienników

Symptoms

Logi aplikacji nie pojawiają się w skonfigurowanym workspace Log Analytics.
kubectl logs działa, ale zapytanie do przestrzeni roboczej nie zwraca żadnych rekordów.

Przyczyna

Log Analytics może nie być skonfigurowana podczas instalacji rozszerzenia, procesor logów może być wyłączony lub niezdrowy, niewłaściwa przestrzeń robocza może zostać zapytana, pobieranie może być opóźnione lub zapytanie może użyć niewłaściwej tabeli lub pola.

Diagnozuj

Sprawdź konfigurację rozszerzenia bez żądania ustawień chronionych i zweryfikowaj docelowy dziennik logu:

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

Sprawdź moduły procesora logów i ostatnie logi:

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

Potwierdź, że wyjście aplikacji istnieje na warstwie Kubernetes:

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

W skonfigurowanej przestrzeni roboczej uruchom ogólne zapytanie przed przefiltrowaniem pól aplikacji:
```
ContainerAppConsoleLogs_CL
| where TimeGenerated > ago(1h)
| take 100
```

Rozwiąż

Wykonaj zapytanie w obszarze roboczym skonfigurowanym podczas instalacji rozszerzenia, przywróć pody procesora logów w złym stanie, korygując zgłoszoną dla nich zależność, oraz popraw tabelę kwerendy lub pola. Nie możesz dodać Log Analytics do istniejącego rozszerzenia po instalacji. Jeśli rozszerzenie nie było skonfigurowane dla Log Analytics, użyj logowania Kubernetes lub zaplanuj wspieraną reinstalację rozszerzenia po ocenie jego wpływu. Ustawienie logProcessor.enabled=false wyłącza przetwarzanie logów i przekierowanie przestrzeni roboczej.

Verify

Zapisz unikalny komunikat testowy na standardowym wyjściu aplikacji. Potwierdź, że kubectl logs jest wyświetlane oraz że po skonfigurowaniu usługi Log Analytics pojawia się w obszarze roboczym po standardowym opóźnieniu pozyskiwania danych.

Eskaluj

Zbierz identyfikator zasobu obszaru roboczego, zanonimizowaną konfigurację rozszerzenia, status i logi poda procesora logów, znaczniki czasu aplikacji i wiadomości testowej oraz tekst zapytania. Nie dołączaj klucza współdzielonego obszaru roboczego ani danych dziennika aplikacji niezwiązanych z problemem.

Błąd rejestracji dostawcy

Symptoms

Operacja zwraca No registered resource provider found.
Wymagany dostawca pozostaje NotRegistered lub Registering.

Przyczyna

Aktywna subskrypcja nie ukończyła rejestracji dostawcy wymaganego przez połączony klaster, rozszerzenie, lokalizację niestandardową, środowisko połączone lub konfigurację usługi Log Analytics.

Diagnozuj

Potwierdź aktywną subskrypcję:

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

Sprawdź wszystkich dostawców używanych przez ścieżkę konfiguracji:

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

Rozwiąż

Zarejestruj dowolnego dostawcę, który nie jest zarejestrowany. Przykład:

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

Rejestracja dostawcy może potrwać kilka minut. Nie odtwarzaj zasobów wielokrotnie podczas rejestracji. Jeśli utworzenie środowiska połączonego zwraca No registered resource provider found, a Microsoft.App już zgłasza Registered, ponownie zarejestruj Microsoft.App za pomocą poprzedniego polecenia, a następnie ponów operację. Ponowna rejestracja dostawcy nie wpływa na istniejące aplikacje ani API.

Verify

Uruchom az provider show--namespace <PROVIDER_NAMESPACE> --query registrationState --output tsv i upewnij się, że zwraca Registered. Spróbuj ponownie wykonać oryginalną operację w tej samej subskrypcji.

Eskaluj

Zbierz identyfikator subskrypcji, przestrzeń nazw dostawcy oraz jego stan, znacznik czasu rejestracji, oryginalny błąd, identyfikator korelacji oraz identyfikator zasobu, którego dotyczy problem. Nie uwzględniaj tokenów dostępu.

Aktualizacja się nie powiodła

Symptoms

Automatyczne lub zainicjowane na żądanie uaktualnienie rozszerzenia pozostaje w toku lub kończy się niepowodzeniem.
Pody rozszerzeń nie działają prawidłowo podczas uaktualnienia lub po nim.

Przyczyna

Typowe przyczyny to kompatybilność z Kubernetes, niewystarczająca pojemność aktualizacji, zablokowane pobieranie obrazów, polityka wstępu, ograniczenia dotyczące zakłóceń w podach lub niezdrowe przedaktualizacyjne rozszerzenie.

Diagnozuj

Zapisz wersję rozszerzenia, kanał wydań, ustawienie automatycznej wersji pomocniczej, stan aprowizacji oraz komunikat stanu.

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

Porównaj aktualną i docelową wersję z informacjami o wydaniu wersji rozszerzenia Container Apps.
Sprawdź pojemność węzłów, moduły rozszerzeniowe, zdarzenia, pobieranie obrazów oraz komunikaty związane z zakłóceniami.
```
kubectl get nodes
kubectl get pods -n <NAMESPACE> -o wide
kubectl get events -n <NAMESPACE> --sort-by=.lastTimestamp
```

Rozwiąż

Przywróć prawidłowe działanie rozszerzenia i odpowiednią zdolność do uaktualnienia, a następnie skoryguj problemy z połączeniem z rejestrem lub odmowy wynikające z zasad zgłoszone w zdarzeniach. Nie zmieniaj ręcznie zasobów roboczych Kubernetes zarządzanych przez rozszerzenia ani nie próbuj wykonywać nieudokumentowanego wycofania. Przed zmianą kanału wydań, ustawienia automatycznej aktualizacji lub wersji rozszerzenia zapoznaj się z obsługiwaną ścieżką aktualizacji z pomocą techniczną firmy Microsoft.

Verify

Uruchom az k8s-extension show i upewnij się, że proces aprowizacji kończy się powodzeniem przy docelowej obsługiwanej wersji. Potwierdź, że wszystkie moduły rozszerzenia są ustabilizowane oraz że operacje środowiska połączonego i aplikacji są skuteczne.

Eskaluj

Zbierz oczyszczone dane wyjściowe rozszerzenia, bieżące i docelowe wersje, gałąź wydania, wersję Kubernetes, pojemność węzła, zdarzenia, logi niedziałających podów, czas rozpoczęcia aktualizacji oraz identyfikatory korelacyjne. Nie dodawaj chronionych ustawień ani danych logowania rejestru.

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2026-09-22