Diagnozowanie i rozwiązywanie problemów z siecią AKS za pomocą zaawansowanych usług sieciowych kontenerów.

Ten przewodnik przeprowadzi Cię przez diagnozowanie i rozwiązywanie rzeczywistych problemów z siecią w Azure Kubernetes Service (AKS) przy użyciu Advanced Container Networking Services (ACNS). Każda instrukcja zaczyna się od objawu (awarie DNS, straty pakietów, brak równowagi ruchu, błędy L7), pokazuje, który sygnał należy sprawdzić najpierw i informuje, kiedy należy analizować dzienniki.

Przewodnik jest zorganizowany wokół zadań, a nie funkcji. Przeczytaj model psychiczny raz, a następnie przejdź prosto do podręcznika, który pasuje do objawu.

Co ten przewodnik pomaga rozwiązać

• Błędy rozpoznawania nazw DNS w zasobnikach (NXDOMAIN, SERVFAIL, brakujące odpowiedzi).
• Utrata pakietów spowodowana błędnie skonfigurowanymi zasadami sieci, śledzeniem połączeń lub pogorszeniem łączności.
• Brak równowagi ruchu między zasobnikami lub przestrzeniami nazw (gorące zasobniki, nierównomierny rozkład obciążenia).
• Błędy aplikacji warstwy L7 (błędy HTTP 4xx/5xx, awarie gRPC, utrata komunikatów Kafka).
• Monitorowanie kondycji sieci w całym klastrze i planowanie pojemności.
• Kontrola kosztów w zakresie obserwowalności poprzez zbieranie ukierunkowanych metryk i dzienników.

Model mentalny: jak metryki, dzienniki i filtrowanie pasują do siebie

Usługa ACNS zapewnia trzy sygnały. Każda z nich odpowiada na inne pytanie.

Sygnał	Odpowiedzi	Najlepsze dla	Gdzie żyje
Metryki sieci kontenerów	Co się dzieje, na jakiej skali?	Wykrywanie anomalii, pulpity nawigacyjne, alerty, planowanie pojemności	Azure zarządzany Prometheus + Grafana
Dzienniki sieci kontenerów (przechowywane)(tylko Cilium)	Dlaczego tak się stało? Które kontenery, jaki werdykt?	Analiza głównej przyczyny, trendy historyczne, zgodność	obszar roboczy Log Analytics (tabela ContainerNetworkLogs), dashboardy portalu Azure lub dowolny moduł zbierający zgodny z OpenTelemetry (Splunk, Datadog itp.)
Dzienniki sieci kontenerów (na żądanie)(Jedynie Cilium)	Co dzieje się teraz?	Debugowanie na żywo podczas aktywnego zdarzenia	Hubble CLI, Hubble UI
Filtrowanie metryk(tylko Cilium)	Które sygnały rzeczywiście potrzebuję?	Zakres zbierania danych dla krytycznych obciążeń, kontrola kosztów	ContainerNetworkMetric CRD
Filtry dzienników i agregacje(tylko Cilium)	Które przepływy są rzeczywiście potrzebne?	Ograniczanie przechwytywania dzienników do krytycznego ruchu, aby kontrolować koszty	ContainerNetworkLog CRD
Agent Container Network Insights(wersja zapoznawcza)	Gdzie mogę nawet zacząć?	Analiza głównej przyczyny (RCA) oparta na sztucznej inteligencji z zastosowaniem metryk, przepływów Hubble, zasad Cilium, CoreDNS oraz liczników kart interfejsu sieciowego/jądra na poziomie hosta.	Dostęp do aplikacji internetowej w klastrze za pośrednictwem przeglądarki

Uwaga / Notatka

Dzienniki sieci kontenerów (przechowane i dostępne na żądanie), ContainerNetworkLog CRD, filtrowanie dzienników i agregacja dzienników przepływu wymagają płaszczyzny danych Cilium. W klastrach innych niż Cilium użyj metryk sieci kontenerów do klasyfikacji i polegaj na telemetrii sieci na poziomie klastra w celu dokładniejszego zbadania.

Aby uzyskać bardziej szczegółowe informacje na temat funkcji, zobacz Container network metrics (Metryki sieci kontenerów), Container network logs (Dzienniki sieci kontenerów) i Configure metrics filtering (Konfigurowanie filtrowania metryk).

Standardowy przepływ rozwiązywania problemów

Użyj tej pętli dla dowolnego zdarzenia sieciowego:

1. Zacznij od dashboardów metryk. Potwierdź anomalię: nagły wzrost liczby spadków, błędów, resetowań protokołu TCP lub awarii DNS. Zidentyfikuj węzeł, przestrzeń nazw lub obciążenie, którego dotyczy problem.
2. Przejdź do zapisanych dzienników. Przefiltruj tabelę ContainerNetworkLogs według przestrzeni nazw i przedziału czasu z kroku 1. Dzienniki informują o werdykcie, przyczynie upuszczania, obciążeniach źródłowych/docelowych i kodach stanu L7, które nie są przenoszone przez metryki.
3. Odtwórz dzienniki na żywo przy użyciu dzienników na żądanie. Jeśli problem jest sporadyczny lub został już rozwiązany w przechowywanych danych, użyj Hubble CLI lub Hubble UI, aby przechwycić przepływy na żywo dla tego obciążenia.
4. Zweryfikuj poprawkę. Ponownie sprawdź ten sam panel metryk i uruchom ponownie to samo zapytanie KQL. Anomalia powinna zniknąć.
5. Dostrajanie kolekcji. W przypadku nadmiernego zebrania danych podczas zdarzenia, w razie potrzeby zawężaj ContainerNetworkLog CRD lub zastosuj ContainerNetworkMetric filtr, aby w przyszłości przechwytywać tylko to, co jest potrzebne.

Wskazówka

Wolisz opisać problem zamiast przeklikiwać się przez pulpity nawigacyjne? Agent usługi Container Network Insights (wersja zapoznawcza) automatyzuje kroki od 1 do 3, klasyfikując problem, zbierając dowody za pomocą poleceń korygujących, Cilium, Hubble, CoreDNS i statystyk sieciowych na poziomie hosta oraz zwracając ustrukturyzowaną analizę głównej przyczyny za pomocą kubectlpoleceń korygowania. Uzupełnia ten przewodnik, a nie zastępuje go — agent zapewnia szybkie pierwsze przejrzenie; playbooki w tym miejscu umożliwiają zweryfikowanie lub dokładniejsze sprawdzenie. Agent jest w trybie tylko do odczytu; poprawkę nadal musisz zastosować samodzielnie.

Uwaga / Notatka

Metryki usługi ACNS nie mierzą opóźnienia. Użyj Azure Monitor metryk wydajności aplikacji lub telemetrii siatki usług na potrzeby analizy opóźnień. Usługa ACNS przedstawia wielkość ruchu, liczby odrzuceń, przyczyny odrzuceń, stany połączeń TCP, resety TCP, liczniki zapytań/odpowiedzi DNS i kody oraz decyzje dotyczące przepływu L4/L7.

Wbudowane tablice rozdzielcze w skrócie

Skonfiguruj je raz za pomocą polecenia Skonfiguruj możliwość obserwowania sieci kontenerów. Odwołujesz się do nich w podręcznikach.

Dashboard	Użyj, gdy musisz...
Klastry	Uzyskaj ogólny widok bajtów/pakietów przekazywanych i odrzuconych dla każdego węzła.
DNS (klaster)	Wykryj problemy z systemem DNS w całym klastrze.
DNS (obciążenie)	Skontroluj szczegóły zachowania DNS dla jednego Deployment/DaemonSet (na przykład CoreDNS).
Spadki (obciążenie)	Zobacz częstotliwość spadku, przyczynę spadku i kierunek dla określonego obciążenia.
Przepływy Podów (Namespace)	Znajdź, które pody w przestrzeni nazw wysyłają lub odbierają najwięcej ruchu lub pakietów utraconych.
Przepływy Podów (Obciążenie)	Zagłęb się w szczegóły przepływów L4/L7 dla jednego zadania, w tym resety TCP.
Przepływy L7 (namespace/zadanie)	Sprawdź przepływy HTTP, gRPC i Kafka. Tylko płaszczyzna danych cilium wymaga zasad L7.
Dzienniki przepływu/ dzienniki przepływu (ruch zewnętrzny)	Wizualizuj przechowywane dzienniki sieci kontenerów w portalu Azure lub w Grafana.

---

Podręcznik 1: Diagnozowanie błędów rozpoznawania nazw DNS

Objaw. Zasobniki rejestrują błędy, takie jak DNS_PROBE_FINISHED_NXDOMAIN, SERVFAILlub zawieszają się podczas rozpoznawania nazw usług.

Celem. Określ, czy błąd jest nadrzędny (CoreDNS lub zewnętrzny program rozpoznawania nazw), oparty na zasadach (odmowa nazwy FQDN) lub specyficzny dla obciążenia.

Krok 1. Potwierdzenie anomalii w metrykach DNS

Otwórz pulpit nawigacyjny DNS (klaster). Poszukaj nagłych zmian w liczbie żądań, liczbie odpowiedzi lub Procent żądań bez odpowiedzi. Panele podsumowania wyświetlają najbardziej typowe zapytania, najbardziej typowe kody odpowiedzi i węzły generujące najwięcej błędów.

Czego szukać: Trwały wzrost odpowiedzi na błędy, spadek pomyślnych odpowiedzi lub pojedynczy węzeł dominuje w liczbie błędów. Zanotuj znacznik czasu anomalii.

Krok 2: Identyfikowanie najbardziej hałaśliwych podów

Przewiń w dół na tym samym pulpicie nawigacyjnym do panelu, który klasyfikuje zasobniki według błędów DNS we wszystkich przestrzeniach nazw. Najważniejsze wpisy to twoi początkowi podejrzani.

Punkt decyzyjny.

• Jeśli błędy są skoncentrowane w podach CoreDNS, przejdź do pulpitu nawigacyjnego DNS (obciążenie) z wybraną pozycją kube-system / coredns — samo CoreDNS albo jego nadrzędne rozwiązanie jest problemem.
• Jeśli błędy są skoncentrowane w obciążeniu aplikacji, to obciążenie generuje nieprawidłowe zapytania lub jest odrzucane przez politykę FQDN.

Krok 3. Przechodzenie do szczegółów obciążenia, którego dotyczy problem

Otwórz pulpit nawigacyjny DNS (obciążenie) dla określonego obciążenia.

• Panele żądań DNS/odpowiedzi DNS. Wysoki procent brakujących odpowiedzi na żądania wskazuje na przekroczenie limitu czasu upstream lub przeciążenie zapytań.

  

• Błędy DNS według typu. Dopasować impuls do kodu:

  • NXDOMAIN — nieprawidłowa lub nieaktywna nazwa domeny w konfiguracji aplikacji.
  • SERVFAIL — problem z rozwiązaniem nadrzędnym.
  • Odmowa zapytania — niezgodność zasad FQDN lub konfiguracji DNS.

  

• Zwrócone adresy IP odpowiedzi DNS. Potwierdza pomyślny wskaźnik rozwiązania. Spadek zwykle oznacza, że usługa CoreDNS nie może dotrzeć do serwera nadrzędnego; nagły wzrost może wskazywać na nawałnicę zapytań.

• Tabela odpowiedzi DNS. Służy do odnajdywania wzorców, takich jak " Rekordy A kończą się niepowodzeniem, ale rekordy AAAAA kończą się powodzeniem", co zwykle wskazuje na stos nieprawidłowo skonfigurowany dla środowisk tylko IPv4.

  

Krok 4. Potwierdzanie przechowywanych dzienników

Uruchom to zapytanie KQL w obszarze roboczym Log Analytics, aby wyświetlić wzorce błędów DNS. Zagregowane wiersze zachowują Verdictprzestrzenie nazw, obciążenia i Layer7.dns.rcode, więc to zapytanie działa względem domyślnej (zagregowanej) ContainerNetworkLogs tabeli:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L4 = parse_json(Layer4), L7 = parse_json(Layer7)
| where L4.UDP.destination_port == 53
| where Reply == true
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name),
         DnsRcode    = tostring(L7.dns.rcode)
| where DnsRcode != "NOERROR"
| summarize ResponseCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DnsRcode, Verdict
| order by ResponseCount desc

Zastąp <start-time> i <end-time> znacznikami czasu w formacie 2026-04-30T15:00:00Z.

Co należy sprawdzić w wynikach:

• Werdykt. DROPPED oznacza, że albo FQDN, albo polityka sieciowa blokują zapytanie. FORWARDED w przypadku elementu innego niż NOERRORDnsRcode (na przykład NXDOMAIN, SERVFAIL) oznacza, że resolver nadrzędny zwrócił błąd.
• Obciążenia źródłowe/docelowe. Upewnij się, że ruch jest kierowany do oczekiwanej usługi CoreDNS.
• DnsRcode. Kod odpowiedzi DNS identyfikuje tryb awarii na pierwszy rzut oka.

Uwaga / Notatka

Rzeczywista domena zapytana (Layer7.dns.query) oraz poszczególne adresy IP podów nie są uwzględniane w kluczu agregacji, dlatego są pomijane w zagregowanych wierszach. Aby je odzyskać, przejdź do dzienników na żądanie (zobacz Krok 5).

Te same przepływy można również wizualizować w portalu Azure w obszarze AKS cluster>Insights>Networking>Flow Logs.

Krok 5. Odtwarzanie na żywo, jeśli problem występuje sporadycznie

Jeśli szczyt już minął i nie można go przechwycić w przechowywanych dziennikach, użyj Hubble CLI na żądanie:

hubble observe --namespace <ns> --port 53 --type l7 --follow

Krok 6. Weryfikowanie poprawki

Po zaktualizowaniu zasad FQDN, naprawieniu konfiguracji aplikacji lub skalowaniu sieci CoreDNS otwórz ponownie pulpit nawigacyjny DNS (obciążenie). Szybkość błędów powinna spaść w ciągu minuty lub dwóch. Uruchom ponownie zapytanie KQL dla tego samego okna czasu, aby potwierdzić, że zapytania zakończone niepowodzeniem zostały zakończone.

Uwaga / Notatka

Metryki DNS w klastrach Cilium wymagają sieciowych zasad Cilium FQDN. Zobacz Konfigurowanie zasad FQDN. Na płaszczyznach danych innych niż Cilium metryki DNS są zbierane domyślnie.

---

Podręcznik 2: Badanie spadków pakietów

Objaw. Usługi nie mogą się ze sobą skontaktować. Sondy kończą się niepowodzeniem. Przekroczono limit czasu połączeń. Liczniki błędów rosną na tablicach.

Celem. Określ, czy spadki są spowodowane przez zasady sieciowe, wyczerpanie śledzenia połączeń lub problemy z łącznością nadrzędną — i które obciążenie jest odpowiedzialne.

Krok 1. Lokalizowanie spadków na poziomie przestrzeni nazw

Otwórz Pod Flows (przestrzeń nazw). Mapy cieplne przedstawiają przestrzenie nazw i zasobniki z najwyższymi wskaźnikami utraty ruchu wychodzącego i przychodzącego.

Jaśniejsze komórki wskazują wyższe wskaźniki spadku. Zanotuj przestrzeń nazw i przedział czasu.

Krok 2. Przechodzenie do szczegółów obciążenia, którego dotyczy problem

Otwórz element Drops (Workload) i wybierz zidentyfikowane przez ciebie obciążenie.

• Migawka obciążenia pokazuje maksymalne/minimalne spadki pakietów wychodzących w pakietach na sekundę. Służy do oceny stopnia nasilenia.

  

• Porzucony ruch według przyczyn jest najważniejszym panelem. Przyczyna informuje o tym, co należy naprawić:

  • Polityka zablokowana — NetworkPolicy lub CiliumNetworkPolicy blokują ruch.
  • CT: Wstawianie mapy nie powiodło się — tabela śledzenia połączeń jest pełna; zwiększenie mocy węzła lub zmniejszenie współczynnika zmian połączenia.
  • Nieobsługiwany protokół L3 / Nieprawidłowy pakiet — aplikacja lub serwer proxy wysyła źle sformułowany ruch.

  

• Mapa cieplna spadków przychodzących/wychodzących. Ustala, które konkretne pary podów tracą ruch.

  

• Skumulowane łączne spadki według modułu źródłowego. Klasyfikuje przestępców, aby wiedzieć, która replika ma najpierw patrzeć.

  

Krok 3. Potwierdzenie porzuconych przepływów w przechowywanych dziennikach

Znajdź dokładne obciążenia źródłowe i docelowe porzuconego ruchu. Verdict, DropReason, przestrzenie nazw i obciążenia znajdują się w kluczu agregacji, więc to zapytanie działa na zagregowanych danych:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DropReason, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

Zawęź do wybranej przestrzeni nazw, gdy już ją zidentyfikujesz.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| where SourceNamespace == "<namespace-name>"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DestinationNamespace, DstWorkload, DropReason, TrafficDirection
| order by DropCount desc

Pulpit nawigacyjny Flow logs w portalu Azure przedstawia te same dane wizualnie, w tym wykres zależności usługi, który wyróżnia zablokowane ścieżki.

Krok 4. Sprawdzanie krzyżowe zasad

Gdy znasz pod źródłowy i pod docelowy:

kubectl get netpol,cnp -A
kubectl describe cnp -n <namespace> <policy-name>

Dopasuj przepływ, który zakończył się niepowodzeniem względem reguł ruchu przychodzącego/wychodzącego. Najczęstszą przyczyną jest dodanie zasad odmowy domyślnej bez reguły zezwalania dla prawidłowej ścieżki.

Krok 5. Weryfikowanie poprawki

Po dostosowaniu zasad Dropped Traffic by Reason wykres powinien spaść płasko dla odmowy zasad. Uruchom ponownie zapytanie KQL — DROPPED werdykty dla tej pary źródło-cel nie powinny już się pojawiać.

Wskazówka

Jeśli analizujesz aktywne zdarzenie i przechowywane dzienniki nie są włączone, uruchom polecenie hubble observe --verdict DROPPED --namespace <ns>, aby przesyłać dane na żywo bez zmiany konfiguracji klastra.

---

Plan działania 3: Znajdowanie dysproporcji ruchu i gorących podów

Objaw. Kilka podów wdrożenia obciąża CPU lub sieć, podczas gdy inne są nieaktywne. Liczba resetów TCP rośnie. Raporty o opóźnieniach pochodzą od użytkowników (samo opóźnienie nie jest widoczne w metrykach usługi ACNS — zobacz notatkę w modelu mentalnym).

Celem. Określ, które pody przenoszą nieproporcjonalny ruch i czy resety wskazują na przeciążenie lub nieprawidłowo skonfigurowane równoważenie obciążenia.

Krok 1: Porównanie ruchu na poziomie podu

Otwórz Strumienie Podów (Obciążenie robocze). Migawka obciążenia podsumowuje ruch wychodzący/przychodzący i porzucone pakiety.

Panel traffic-by-trace-type pokazuje kształt ruchu w czasie. Szeroka przepaść między wolumenem wychodzącym i przychodzącym często wskazuje na wąskie gardło dalej w procesie.

Krok 2. Dostrzec gorące pody z mapami cieplnymi

Mapy ciepła na poziomie modułu uwidaczniają nierównowagę. Jeśli jeden zasobnik (na przykład default/tcp-client-0) pojawia się zarówno na wychodzących, jak i przychodzących mapach cieplnych, z komórkami znacznie ciemniejszymi niż jego repliki, oznacza to, że ruch jest tam skoncentrowany.

Typowe przyczyny:

• Usługa sessionAffinity: ClientIP przypinania klientów do jednego podu.
• Usługa działająca bez interfejsu użytkownika z trwałym rozpoznawaniem nazw DNS.
• Zewnętrzny moduł równoważenia obciążenia z hashowaniem na polu o niskiej kardynalności.

Krok 3. Używanie resetów TCP jako sygnału nasycenia

Otwórz panele metryk resetowania protokołu TCP .

• Mapa cieplna wychodzącego protokołu TCP RST według zasobnika źródłowego. Gorący zasobnik źródłowy, który również generuje RST, jest przeciążony — aplikacja agresywnie zamyka połączenia.

  

• Mapa cieplna przychodzącego protokołu TCP RST według zasobnika docelowego. Zasobnik odbierający połączenia rsTs z wielu źródeł zwykle oznacza, że nie może zaakceptować nowych połączeń wystarczająco szybko (lista prac pełna, odbiornik powolny).

  

• Skumulowany łączny RST według źródła/miejsca docelowego. Trendy w czasie informują o tym, czy resetowanie jest zdarzeniem, czy nowym stanem stałym.

Krok 4. Potwierdzanie przy użyciu dzienników

Zidentyfikuj najbardziej ruchliwe obciążenia według całkowitego woluminu przepływu. Użyj zagregowanych kolumn zliczanych przepływów, a nie count(), które zliczają tylko zagregowane wiersze, a nie podstawowe przepływy:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend SrcWorkload = tostring(SourceWorkloads[0].name)
| summarize TotalFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload
| top 10 by TotalFlows desc

Uwaga / Notatka

Flagi TCP dla pakietu (takie jak RST) nie są częścią klucza agregacji, więc są one porzucane z zagregowanych wierszy w pliku ContainerNetworkLogs. Aby zbadać resetowanie protokołu TCP na poziomie przepływu, użyj powyższych pulpitów nawigacyjnych resetowania protokołu TCP oraz ścieżki dzienników na żądanie — przesyłaj strumieniowo przepływy RST na żywo za pomocą hubble observe --type trace --verdict FORWARDED --tcp-flags RST.

Krok 5. Weryfikowanie poprawki

Po skalowaniu obciążenia, zrównoważeniu usługi lub naprawieniu reguł afinity mapa cieplna powinna równomiernie rozjaśnić się w większej liczbie zasobników, a szybkość RST protokołu TCP powinna spaść.

---

Podręcznik 4: monitorowanie kondycji sieci w całym klastrze

Użyj tej opcji, gdy potrzebujesz widoku zespołu: planowania pojemności, pulpitów dyżurów lub szybkiego sprawdzania kondycji w wielu klastrach.

Otwórz platformę Kubernetes/Sieć/Klastry.

Sygnały do obejrzenia i co oznaczają:

panelu	Uważaj na	Prawdopodobna przyczyna
Bajty/pakiety przekazywane	Nagłe klify lub gwałtowne wzrosty	Wąskie gardło lub ponowne uruchomienie obciążenia
Odrzucone bajty/pakiety (klaster)	Trwały wznoszenie	Regresja polityki lub łącze nasycone
Bajty/pakiety porzucone przez przyczynę	Pojawia się nowa przyczyna	Nowy problem z błędną konfiguracją lub problem na poziomie jądra
Bajty i pakiety odrzucone przez węzeł	Jednolity węzeł dominujący	Lokalny sprzęt węzła, niewłaściwa konfiguracja lub zakłócający sąsiad
Dystrybucja stanu połączenia TCP	Nadmiar SYN_SENT lub TIME_WAIT	Błędy łączności lub zmiany gniazd sieciowych wynikające z krótkotrwałych połączeń

Gdy coś na tym pulpicie nawigacyjnym wygląda źle, przejdź do pasującego podręcznika (podręcznik 1 dla systemu DNS, podręcznik 2 dla kropli, podręcznik 3 dla gorących zasobników).

---

Podręcznik 5: Diagnozowanie błędów warstwy aplikacji (L7)

Objaw. Http 4xx/5xx współczynniki błędów wspinają się. Wywołania gRPC kończą się niepowodzeniem. Opóźnienie użytkowników platformy Kafka. Dostępne w klastrach Cilium z włączonym wymuszaniem zasad L7 i regułami CiliumNetworkPolicy L7 — zobacz Konfigurowanie zasad warstwy 7.

Celem. Określ, czy błędy L7 pochodzą z błędnie skonfigurowanych klientów, błędów po stronie serwera lub odrzuconych przepływów.

Uwaga / Notatka

Wymuszanie L7 wymaga utworzenia lub zaktualizowania klastra za pomocą --acns-advanced-networkpolicies L7 polecenia. Ustawienie L7 włącza również filtrowanie nazw FQDN. Reguły L7 nie są obsługiwane w CiliumClusterwideNetworkPolicy (CCNP), a ruch L7 przepływa przez serwer proxy Envoy, który może generować opóźnienie powyżej około 3,000 żądań na sekundę na węzeł. Zobacz Zagadnienia dotyczące zasad L7.

Krok 1. Otwieranie pulpitu nawigacyjnego L7

Użyj Kubernetes / Networking / L7 (obciążenie robocze) dla jednej usługi lub L7 (Namespace) dla całego tenant.

Krok 2: Oddzielenie ruchu porzuconego i przekazywanego przez HTTP

Panel werdyktu dzieli ruch HTTP na przepływy przekazywane i porzucone. Wzrost liczby porzuconych żądań HTTP zwykle oznacza, że ciliumNetworkPolicy odrzuca żądanie na poziomie L7 (na przykład blokowanie ścieżki lub metody).

Krok 3. Śledzenie kodów stanu w czasie

Panel kodów stanu informuje, czy błędy są po stronie klienta, czy po stronie serwera. Wzrost liczby 4xx wskazuje na nieprawidłowe dane wejściowe, wygasłe tokeny lub odrzucone ścieżki. Wzrost liczby 5xx punktów w przypadku awarii zaplecza.

Krok 4. Znajdowanie przestępczych zasobników

Mapa cieplna 4xx pokazuje, które pody źródłowe generują najwięcej nieudanych żądań. Pojedynczy pod, wyraźnie świecący, zwykle oznacza zablokowaną pętlę ponawiania prób klienta lub nieprawidłowo skonfigurowaną replikę.

Krok 5: Potwierdź za pomocą języka KQL

Pobieranie ruchu sieciowego HTTP podzielonego według kodu statusu. Layer7.http.code jest częścią klucza agregacji, więc działa to względem zagregowanych wierszy:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L7 = parse_json(Layer7)
| where isnotnull(L7.http)
| extend StatusCode  = tostring(L7.http.code),
         SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount),
            UniqueCodes = dcount(StatusCode)
    by SrcWorkload, DstWorkload, StatusCode
| order by ErrorFlows desc

W przypadku gRPC i Kafka, Layer7 przenosi ładunek specyficzny dla protokołu, ale tylko http.code i dns.rcode są kluczami agregacji. Filtruj według Verdict oraz tożsamości obciążenia i używaj dzienników na żądanie, gdy potrzebujesz metody gRPC lub tematu Kafka.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where Verdict == "DROPPED"
| summarize DroppedFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DstWorkload
| order by DroppedFlows desc

Uwaga / Notatka

Szczegółowe atrybuty L7 (adresy URL HTTP, metody gRPC, tematy platformy Kafka, nazwy zapytań DNS) nie znajdują się w kluczu agregacji i są usuwane z zagregowanych wierszy. Użyj przepływów Hubble na żądanie dla tego poziomu szczegółowości.

Co należy skupić się na trakcie analizy głównej przyczyny L7

• Rozmiar i kształt ruchu. Użyj map cieplnych, aby znaleźć brak równowagi; często jedna replika o wysokiej temperaturze wyjaśnia wskaźnik błędów.
• Trend kodu stanu. 4xx a 5xx zawęża badanie do strony klienta lub serwera.
• Werdykt.Odrzucone przepływy warstwy 7 oznaczają, że polityka warstwy 7 odrzuca żądanie — przeczytaj politykę i potwierdź intencję.

---

Szczegółowe omówienie funkcji (kiedy co stosować)

Skorzystaj z tej sekcji jako podręcznego odniesienia, kiedy znasz już schematy.

Metryki sieci kontenerów

• Służy do: wykrywania anomalii, dashboardów, alertów, planowania pojemności.
• Pomiń z powodu: głównej przyczyny wymagającej identyfikacji (który pod, która ścieżka, który werdykt).
• Stopień szczegółowości: poziom węzła na wszystkich płaszczyznach danych; na poziomie zasobnika w systemie Linux.
• Obciążenia zależne od kosztów: zastosuj filtrowanie metryk w klastrach Cilium, aby zachować tylko te przestrzenie nazw, etykiety i typy metryk, które cię interesują. Filtrowanie odbywa się przed zrzutem danych, więc niechciane serie nigdy nie docierają do Prometheus.

Dzienniki sieci kontenerów (przechowywane)

• Służy do: analiza głównej przyczyny, trendy historyczne, zgodność/inspekcja.

• Płaszczyzna danych:Tylko Cilium. Przechowywane dzienniki nie są dostępne w klastrach bez Cilium.

• Obowiązkowy krok: zdefiniuj ContainerNetworkLog CRD, który wybiera preferowany ruch. Bez niego żadne dzienniki nie są zbierane. Zobacz Konfigurowanie dzienników sieci kontenerów.

• Gdzie dzienniki lądują: domyślnie Cilium zapisuje rekordy przepływu w /var/log/acns/hubble/events.log każdym węźle (bufor obrotowy 50 MB). Z tego miejsca masz dwie ścieżki przechowywania:

  • Azure Log Analytics (zarządzane, zalecane) — Container Insights przesyła dzienniki do tabeli ContainerNetworkLogs na potrzeby zapytań KQL i wbudowanych pulpitów nawigacyjnych w portalu Azure.
  • Użyj własnego kolektora — skonfiguruj agenta zgodnego z OpenTelemetry (Splunk, Datadog, Elastic, dowolny kolektor OTel) na ścieżce dziennika hosta, aby przekazywać dane do istniejącego środowiska obserwacyjnego, zamiast do Log Analytics lub dodatkowo do niego.

• Kontrola kosztów: agregacja dzienników przepływu konsoliduje podobne przepływy w 30-sekundowym oknie, zachowując wzorce przy jednoczesnym zmniejszaniu objętości. Aby uzyskać najlepsze wyniki, połącz z wąskim includeFilters.

• Wizualizacja: użyj pulpitów nawigacyjnych Dzienniki przepływu - warstwa analizy lub Dzienniki przepływu - warstwa podstawowa w Azure>Insights>Containers>Networking.

  

  

Dzienniki sieciowe kontenerów (na żądanie)

• Służy do: zdarzenia na żywo, sporadyczne problemy, badanie ad hoc bez zmiany konfiguracji kolekcji.

• Płaszczyzna danych:Wyłącznie Cilium.

• Narzędzia: Hubble CLI do filtrowania w terminalu; Hubble UI do wizualizacji map połączeń usługowych.

• Brak magazynu trwałego, bez dodatkowych kosztów, bez konfiguracji poza włączaniem usługi ACNS.

  

Filtrowanie metryk (klastry Cilium)

Zastosuj CRD, aby kontrolować, które metryki Hubble'a są eksportowane dla każdego węzła. Przydatne, gdy potrzebujesz szerokiej obserwacji w kilku krytycznych przestrzeniach nazw, ale nie chcesz płacić za serię przepływów o wysokiej kardynalności we wszystkich z nich.

Typowe wzorce:

• Zachowaj DNS i wyłącz metryki w całym klastrze; ogranicz metryki przepływu do produkcyjnych przestrzeni nazw.
• Wyklucz przestrzenie nazw systemu o wysokim obciążeniu, takie jak kube-system, z metryk przepływu.
• Przypisz przestrzenie nazw dla każdej dzierżawy do własnych bloków filtrów.

Aby zapoznać się z pełnymi przykładami crD, zobacz Konfigurowanie filtrowania metryk sieci kontenera.

---

Najlepsze rozwiązania

• Zaczynaj szeroko, a następnie zawężaj. Włącz szerokie dzienniki/metryki na kilka dni, przejrzyj to, czego faktycznie używasz, a następnie zaostrz filtry ContainerNetworkLog i ContainerNetworkMetric.
• Utrzymuj wyrównane okna czasu dla metryk i logów. Podczas badania zdarzenia użyj tego samego czasu rozpoczęcia/zakończenia na pulpicie nawigacyjnym i w zapytaniu KQL, aby sygnały były dobrze skorelowane.
• Preferuj wstępnie utworzone pulpity nawigacyjne. Obejmują one najczęściej zadawane pytania. Panele niestandardowe są zwykle potrzebne tylko po przejściu wstępnego triage.
• Warstwa ContainerNetworkLogs według potrzeb. Przejdź do warstwy Podstawowa dla obciążeń wrażliwych na koszty; użyj pasującego pulpitu nawigacyjnego w warstwie Podstawowa. Zobacz Log Analytics plany tabel.
• Traktuj zagregowane dzienniki i dzienniki na żądanie jako uzupełnienie. Zagregowane dzienniki doskonale nadają się do wykrywania trendów i wzorców, ale pomijają szczegóły przepływu. Używaj Hubble na żądanie do szczegółowej analizy.
• Zweryfikuj poprawki za pomocą tego samego panelu, który pokazał problem. Jeśli ten sam panel przestanie działać po zmianie, masz realną naprawę.

Typowe pułapki

• Zapominając o ContainerNetworkLog CRD. Włączenie dzienników sieciowych kontenerów w klastrze nie zbiera żadnych danych, dopóki nie zastosujesz co najmniej jednego CRD, który wybiera ruch sieciowy.
• Próba użycia przechowywanych dzienników dla przeszłych incydentów, które już się zakończyły. Jeśli dzienniki nie były włączone przed incydentem lub nie mieściły się w przechwyconym filtrze, przełącz się na przepływy na żądanie Hubble przy następnym wystąpieniu.
• Pulpity nawigacyjne L7 są puste w klastrze Cilium. Metryki L7 wymagają zarówno --acns-advanced-networkpolicies L7 na klastrze jak iCiliumNetworkPolicy z regułami L7. CCNP nie obsługuje reguł L7. Zobacz Stosowanie zasad L7.
• Metryki DNS są puste w Cilium. Widoczność DNS wymaga , który ma regułę (zazwyczaj obok ).
• matchPattern: "*" blokuje wszystkie dns. Nieokreślony symbol wieloznaczny nie jest obsługiwany. Użyj wzorca z wiodącymi symbolami wieloznacznymi, takiego jak *.example.com lub app*.example.com. Przeczytaj o Stosowaniu zasad filtrowania nazw FQDN.

Możliwość obserwowania sieci w połączeniu z monitorowaniem platformy Azure

Po włączeniu zarządzanej usługi Azure Monitor dla rozwiązania Prometheus w klastrze AKS, podstawowe metryki monitorowania sieci węzłów są domyślnie zbierane za pośrednictwem celu networkobservabilityRetina. Zapewnia to:

• Podstawowe metryki sieci na poziomie węzła: podstawowa widoczność ruchu sieciowego na poziomie węzła
• Domyślne elementy docelowe rozwiązania Prometheus: Metryki obserwacji sieci są automatycznie usuwane przez usługę Azure Monitor
• Integracja z usługą Azure Monitor: bezproblemowa integracja z usługą Azure Monitor; metryki są zbierane automatycznie i mogą być wizualizowane w narzędziu Grafana
• Nie jest wymagana żadna dodatkowa konfiguracja: automatycznie włączone po skonfigurowaniu zarządzanego rozwiązania Prometheus w usłudze Azure Monitor
• Pomoc techniczna firmy Microsoft: obsługiwane w ramach usług Azure Monitor i AKS

Uwaga: Wymaga to włączenia zarządzanej usługi Azure Monitor dla Prometheus w klastrze AKS, co może wiązać się z kosztami.

Wprowadzenie: Włącz usługę zarządzaną Azure Monitor dla Prometheus w klastrze AKS za pośrednictwem portalu Azure lub interfejsu wiersza polecenia. Metryki obserwacji sieci będą automatycznie zbierane i dostępne do wizualizacji w usłudze Azure Managed Grafana.

Obserwowalność sieci za pomocą Retina OSS

Chociaż Advanced Container Networking Services (ACNS) to płatna oferta, która zapewnia kompleksowe możliwości obserwacji sieci, firma Microsoft obsługuje również możliwość obserwacji sieci z systemem operacyjnym Retina, platformą do obserwacji sieci typu open source, która zapewnia podstawowe możliwości monitorowania sieci.

System operacyjny Retina to platforma do obserwacji typu open source dostępna w retina.sh i GitHub. Zapewnia:

• Możliwość obserwowania sieci opartej na protokole eBPF: używa technologii eBPF do zbierania szczegółowych informacji z minimalnym obciążeniem
• Głęboka analiza ruchu w kontekście platformy Kubernetes: kompleksowe przechwytywanie i analizowanie przepływów ruchu sieciowego przy użyciu pełnej integracji rozwiązania Kubernetes
• Zaawansowana kolekcja metryk: metryki warstwy 4, metryki DNS i możliwości przechwytywania pakietów rozproszonych
• Rozszerzalność oparta na wtyczkach: dostosowywanie i rozszerzanie funkcjonalności za pomocą architektury wtyczki
• Metryki zgodne z rozwiązaniem Prometheus: Eksportowanie kompleksowych metryk sieci w formacie Prometheus z konfigurowalnymi trybami metryk
• Przechwytywanie pakietów rozproszonych: przechwytywanie pakietów na żądanie w wielu węzłach na potrzeby głębokiego rozwiązywania problemów
• Niezależna od platformy i sieci CNI: współpracuje z dowolnym klastrem Kubernetes (AKS, z obsługą usługi Arc, środowiskiem lokalnym), dowolnym systemem operacyjnym (Linux/Windows) i dowolnym CNI
• Wsparcie społeczności: open source ze wsparciem społeczności i wkładem społeczności
• Samodzielne zarządzanie: pełna kontrola nad wdrażaniem i konfiguracją
• Integracja z usługą Hubble: integruje się z hubblem Cilium, aby uzyskać dodatkowe szczegółowe informacje o sieci

Rozpoczęcie pracy: Wdrażaj Retina OSS przy użyciu pakietów Helm lub manifestów Kubernetes z oficjalnego repozytorium Retina. Skonfiguruj rozwiązanie Prometheus i Grafana, aby wizualizować metryki, skonfigurować głęboką analizę ruchu przy użyciu kontekstu Kubernetes, włączyć przechwytywanie pakietów rozproszonych na potrzeby zaawansowanego rozwiązywania problemów i dostosować funkcjonalność przy użyciu architektury opartej na wtyczkach dla określonych przypadków użycia.

Porównanie ofert obserwacji sieci

Offering	Support	Koszt	Zarządzanie	Wdrożenie	Przypadki użycia
Advanced Container Networking Services (ACNS)	Pomoc techniczna dla przedsiębiorstw firmy Microsoft	Płatna usługa platformy Azure	W pełni zarządzane przez firmę Microsoft	Integracja z platformą Azure jednym kliknięciem	Zarządzana obserwowalność przedsiębiorstwa: przepływy sieciowe na poziomie podu, metryki na poziomie podu, metryki DNS, trwale przechowywane dzienniki, analiza ruchu w warstwie 7, wymuszanie polityk bezpieczeństwa sieci, raportowanie zgodności, zaawansowane pulpity nawigacyjne Grafana, spostrzeżenia oparte na sztucznej inteligencji
Obserwowanie sieci (Azure Monitor)	Pomoc techniczna firmy Microsoft w ramach usługi Azure Monitor	Dołączone do zarządzanego rozwiązania Prometheus w usłudze Azure Monitor (mają zastosowanie koszty usługi Azure Monitor)	W pełni zarządzane przez firmę Microsoft	Automatyczne, gdy usługa Prometheus zarządzana przez usługę Azure Monitor jest włączona	Monitorowanie sieci węzłów: metryki sieci na poziomie klastra i węzła, brak widoczności na poziomie zasobnika, brak przechowywanych dzienników, brak analizy DNS — odpowiednie dla podstawowego monitorowania infrastruktury i użytkowników, którzy chcą minimalnej możliwości obserwowania sieci bez dodatkowej konfiguracji
Retina OSS	Wsparcie społeczności	Bezpłatne i open source	Samodzielne zarządzanie	Ręczna konfiguracja z użyciem Helm lub manifestów w dowolnym klastrze Kubernetes	Zaawansowane obserwowanie niezarządzane: przechwytywanie pakietów w czasie rzeczywistym, zbieranie metryk niestandardowych, analiza sieci głębokiej opartej na EBPF, integracja z hubblem, wdrożenia wielochmurowe, niestandardowe potoki obserwacji, zaawansowane debugowanie za pomocą integracji tcpdump/Wireshark oraz środowiska programistyczne/testowe

Dowiedz się więcej

Advanced Container Networking Services (ACNS)

• Omówienie platformy:Co to jest Advanced Container Networking Services dla AKS?
• Skonfiguruj obserwowalność:Skonfiguruj obserwowalność sieci kontenerów
• Metryki sieci kontenerów:Omówienie metryk sieci kontenerów
• Dzienniki sieci kontenerów:Omówienie dzienników siecikontenerów i Konfigurowanie dzienników sieci kontenerów
• Filtrowanie metryk (Cilium):Konfigurowanie filtrowania metryk sieci kontenerów

Diagnostyka oparta na sztucznej inteligencji

• Agent usługi Container Network Insights (wersja zapoznawcza):Omówienie i konfigurowanie agenta
• Serwer AKS MCP:Serwer protokołu kontekstowego modelu AKS

Zabezpieczenia sieci kontenera (Cilium)

• Filtrowanie nazw FQDN:Pojęcia i stosowanie zasad filtrowania nazw FQDN
• Zasady warstwy 7:Pojęcia i stosowanie zasad L7
• Wzajemne protokoły TLS (Cilium):Pojęcia i konfigurowanie wzajemnego protokołu TLS
• Szyfrowanie podczas przesyłania:Pojęcia dotyczące szyfrowania WireGuard

Warstwa danych i platforma

• Azure CNI obsługiwane przez cilium:Konfigurowanie Azure CNI obsługiwanej przez cilium
• Wydajność routingu hostów eBPF:Wydajność sieci kontenera z routingiem hosta eBPF
• Plany tabeli Log Analytics:Wybierz plan tabeli na podstawie użycia danych

Narzędzia typu open source

• Retina:retina.sh oraz repozytorium GitHub Microsoft Retina
• Hubble (projekt Cilium):Dokumentacja usługi Hubble