Diagnostika a řešení problémů sítě AKS pomocí služby Advanced Container Networking Services

Tato příručka vás provede diagnostikou a řešením reálných problémů se sítěmi v Azure Kubernetes Service (AKS) pomocí služby Advanced Container Networking Services (ACNS). Každý playbook začíná příznakem (selhání DNS, výpadky paketů, nerovnováha provozu, chyby L7), ukazuje, který signál se má nejdřív zkontrolovat, a řekne vám, kdy přejít k podrobnostem protokolů.

Průvodce je uspořádaný podle úkolů, ne funkcí. Přečtěte si mentální model a poté rovnou přejděte k příručce, která odpovídá vašemu problému.

Co vám tento průvodce pomůže vyřešit

• Selhání překladu DNS v podech (NXDOMAIN, SERVFAIL, chybějící odpovědi).
• Ztráty paketů způsobené chybně nakonfigurovanými zásadami sítě, sledováním připojení nebo zhoršením konektivity.
• Nerovnováha provozu mezi pody nebo obory názvů (horké pody, nerovnoměrná distribuce zatížení).
• Chyby aplikace L7 (HTTP 4xx/5xx, selhání gRPC, poklesy Kafka)
• Monitorování stavu sítě na úrovni clusteru a plánování kapacity
• Kontrola nákladů na pozorovatelnost prostřednictvím cílené metriky a shromažďování protokolů

Mentální model: jak se metriky, protokoly a filtrování vejdou dohromady

ACNS vám dává tři signály. Každá odpovídá na jinou otázku.

Signál	Odpovědi	Nejlepší pro	Kde se nachází
Metriky sítě kontejnerů	Co se děje, v jakém měřítku?	Detekce anomálií, řídicí panely, výstrahy, plánování kapacity	Azure managed Prometheus + Grafana
Protokoly sítě kontejnerů (uložené)(pouze Cilium)	Proč se to stalo? Jaké moduly, jaký je verdikt?	Analýza původní příčiny, historické trendy, dodržování předpisů	pracovní prostor Log Analytics (ContainerNetworkLogs tabulka), řídicí panely portálu Azure nebo jakýkoli kolektor kompatibilní s OpenTelemetry (Splunk, Datadog atd.)
Síťové protokoly kontejneru (na vyžádání) (pouze Cilium)	Co se právě teď děje?	Živé ladění během aktivního incidentu	Rozhraní příkazového řádku Hubble (CLI), uživatelské rozhraní Hubble (UI)
Filtrování metrik(pouze Cilium)	Jaké signály skutečně potřebuji?	Vymezení kolekce na kritické úlohy, řízení nákladů	ContainerNetworkMetric CRD
Filtry protokolů a agregace(pouze Cilium)	Které toky skutečně potřebuji?	Omezení zachytávání logů pro kritický provoz, řízení nákladů	ContainerNetworkLog CRD
Container Network Insights Agent(Preview)	Kde mám dokonce začít?	Analýza RCA řízená AI napříč metrikami, toky Hubble, zásadami Cilium, coreDNS a čítači síťových adaptérů a jader na úrovni hostitele	Webová aplikace v clusteru, ke které se přistupuje přes prohlížeč

Note

Protokoly sítě kontejnerů (uložené a na vyžádání), ContainerNetworkLog CRD, filtrování protokolů a agregace protokolů toku vyžadují rovinu dat Cilium. Ve clusterech, které nevyužívají Cilium, používejte metriky kontejnerové sítě pro třídění a spolehněte se na telemetrii na úrovni clustru pro hlubší šetření.

Podrobnější referenční informace o funkcích najdete v tématu Metriky sítě kontejnerů, protokoly sítě kontejnerů a Konfigurace filtrování metrik.

Standardní tok řešení potíží

Tuto smyčku použijte pro všechny incidenty sítě:

1. Začněte na řídicích panelech metrik. Ověřte anomálii: špičku v poklesech, chybách, resetech TCP nebo selhání DNS. Identifikujte ovlivněný uzel, obor názvů nebo úlohu.
2. Přejděte na uložené protokoly. Vyfiltrujte ContainerNetworkLogs tabulku podle oboru názvů a časového intervalu z kroku 1. Z protokolů zjistíte verdikt, důvod vyřazení, zdrojové a cílové pracovní zátěže a L7 stavové kódy, které metriky nezahrnují.
3. Reprodukujte živě s protokoly na vyžádání. Pokud k problému dochází přerušovaně nebo je už opraven v uložených datech, použijte CLI Hubble nebo UI Hubble k zachycení živých toků pro danou pracovní zátěž.
4. Ověřte opravu. Znovu zkontrolujte stejný panel metrik a znovu spusťte stejný dotaz KQL. Anomálie by měla být pryč.
5. Vylaďte kolekci. Pokud jste během incidentu nasbírali příliš mnoho dat, zužte ContainerNetworkLog CRD nebo použijte ContainerNetworkMetric filtr, abyste zachytili pouze to, co budete potřebovat nadále.

Tip

Raději popíšete problém místo kliknutí na řídicí panely? Container Network Insights Agent (Preview) automatizuje kroky 1–3 tím, že klasifikuje váš problém, shromažďuje důkazy prostřednictvím kubectl, Cilium, Hubble, CoreDNS a statistiky sítě na úrovni hostitele a vrací strukturovanou analýzu RCA pomocí nápravných příkazů. Doplňuje tuto příručku, nikoli ji nahrazuje – agent vám poskytne rychlé počáteční vyhodnocení; zde uvedené postupy vám umožní ověřit a ponořit se do tématu hlouběji. Agent je pouze pro čtení; opravu však musíte provést sami.

Note

Metriky ACNS neměří latenci. K analýze latence použijte Azure Monitor metriky výkonu aplikací nebo telemetrii sítě služeb. ACNS zobrazí objem provozu, počty poklesů, důvody poklesu, stavy TCP, resetování protokolu TCP, počty dotazů a odpovědí DNS a kódy a verdikty toku L4/L7.

Integrované řídicí panely na první pohled

Nastavte je jednou pomocí možnosti Nastavit pozorovatelnost kontejnerové sítě. Budete na ně odkazovat v playbookech.

Dashboard	Použijte, když potřebujete...
Shluky	Získejte flotilní přehled o bajtech a paketech přesměrovaných a vyřazených na každý uzel.
DNS (cluster)	Zjistěte problémy s DNS v rámci celého clusteru.
DNS (pracovní zátěž)	Přejděte k podrobnostem chování DNS pro jedno nasazení nebo DaemonSet (například CoreDNS).
Poklesy (zátěž)	Podívejte se na míru poklesu, důvod poklesu a směr konkrétní úlohy.
Pod Flows (Jmenný prostor)	Zjistěte, které pody v názvovém oboru odesílají nebo přijímají nejvíce datového provozu nebo mají nejvíce ztrát.
Toky podů (úlohy)	Prozkoumejte toky L4/L7 pro jeden pracovní úkol, včetně TCP resetů.
L7 Flows (Namespace / Pracovní zatížení)	Prozkoumejte toky HTTP, gRPC a Kafka. Pouze datová rovina Cilium vyžaduje zásadu L7.
Protokoly toku / Protokoly toku (externí provoz)	Vizualizujte uložené protokoly sítě kontejnerů na portálu Azure nebo Grafana.

---

Playbook 1: Diagnostika selhání překladu DNS

Příznak Chyby v protokolech podů, jako je DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL, nebo zablokování během překládání názvů služeb.

Cílem. Určete, jestli je selhání upstreamovým (CoreDNS nebo externí resolver), politika řízené odepření (FQDN) nebo specifické pro úlohu.

Krok 1: Potvrzení anomálie v metrikách DNS

Otevřete řídicí panel DNS (cluster). Vyhledejte náhlé změny objemu požadavků, objemu odpovědí nebo % žádostí bez odpovědi. Na souhrnných panelech se vyskytují nejběžnější dotazy, nejběžnější kódy odpovědí a uzly, které generují nejvíce chyb.

Co hledat: Trvalý nárůst chybových odpovědí, pokles úspěšných odpovědí nebo jeden uzel, který dominuje počtu chyb. Poznamenejte si časové razítko anomálií.

Krok 2: Identifikace nejhlučnějších podů

Posuňte se na stejném řídicím panelu dolů na panel, který řadí pody podle chyb DNS napříč všemi obory názvů. Hlavní položky jsou vaše počáteční podezřelé.

Rozhodovací bod.

• Pokud jsou chyby zahuštěné v podech CoreDNS, přejděte na řídicí panel DNS (Workload) a vyberte kube-system / coredns — problémem je buď samotný CoreDNS, nebo jeho upstreamový překladač.
• Pokud jsou chyby soustředěné v úloze aplikace, tato úloha generuje chybné dotazy nebo je zamítána zásadami FQDN (plně kvalifikovaného názvu domény).

Krok 3: Podrobně prozkoumejte ovlivněné zatížení

Otevřete řídicí panel DNS (Workload) pro úlohu, kterou jste identifikovali.

• Dns Requests / DNS Responses panels. Vysoké procento chybějících odpovědí na požadavky ukazuje na časové limity upstreamu nebo přetížení dotazů.

  

• Chyby DNS podle typu Porovná špičku s kódem:

  • NXDOMAIN – nesprávný nebo zastaralý název domény v konfiguraci aplikace.
  • SERVFAIL – nadřazený problém řešitele.
  • Dotaz odmítnut – pravidla FQDN nebo neshoda konfigurace DNS.

  

• Vrátily se IP adresy odpovědí DNS. Potvrdí úspěšnou míru řešení. Pokles obvykle znamená, že CoreDNS nemůže dosáhnout upstream; náhlé přepětí může znamenat bouři dotazů.

• Tabulka odpovědí DNS Pomocí tohoto příkazu můžete odhalit vzory, jako je "A záznamy selžou, ale AAAA záznamy uspějí," což obvykle signalizuje chybně nakonfigurovaný protokolový zásobník pro prostředí pouze s IPv4.

  

Krok 4: Potvrzení s uloženými protokoly

Spuštěním tohoto dotazu KQL v pracovním prostoru Log Analytics zobrazíte vzory chyb DNS. Agregované řádky zachovávají Verdict, obory názvů, úlohy a Layer7.dns.rcode, takže tento dotaz funguje s výchozí (agregovanou) ContainerNetworkLogs tabulkou:

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

Nahraďte <start-time> a <end-time> časovými razítky ve formátu 2026-04-30T15:00:00Z.

Co zkontrolovat ve výsledcích:

• Verdikt. DROPPED znamená, že dotazu brání plně kvalifikovaný název domény nebo síťová politika. FORWARDED s jiným typem než NOERRORDnsRcode (například NXDOMAIN, SERVFAIL) znamená, že upstreamový resolver vrátil chybu.
• Zdrojové a cílové pracovní zátěže. Ověřte, že provoz směřuje do očekávané úlohy CoreDNS.
• DnsRcode. Kód odpovědi DNS na první pohled identifikuje režim selhání.

Note

Skutečná dotazovaná doména (Layer7.dns.query) a jednotlivé IP adresy podů nejsou součástí agregačního klíče, takže se vyřadí z agregovaných řádků. Pokud je chcete obnovit, přepněte na protokoly na vyžádání (viz krok 5).

Stejné toky můžete vizualizovat také na portálu Azure v clusteru AKS>Insights>Networking>Flow Logs.

Krok 5: Reprodukujte v reálném čase, pokud k problému dochází přerušovaně

Pokud už špička prošla a nemůžete ji zachytit v uložených protokolech, použijte rozhraní příkazového řádku Hubble na vyžádání:

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

Krok 6: Ověření opravy

Po aktualizaci zásad FQDN, opravě konfigurace aplikace nebo škálování CoreDNS znovu otevřete řídicí panel DNS (Workload). Míra chyb by měla klesnout do minuty nebo dvou. Znovu spusťte dotaz KQL pro stejné časové okno, abyste potvrdili, že selhávající dotazy zmizely.

Note

Metriky DNS v clusterech Cilium vyžadují síťovou zásadu Cilium FQDN. Viz Konfigurace zásad plně kvalifikovaného názvu domény. Na rovinách dat mimo Cilium se ve výchozím nastavení shromažďují metriky DNS.

---

Playbook 2: Prozkoumání zahozených paketů

Příznak Služby se navzájem nemůžou spojit. Sondy selžou. Časový limit připojení vypršel. Počet zahozených paketů se zvyšuje na řídicích panelech.

Cílem. Určete, jestli jsou výpadky způsobené síťovou politikou, vyčerpáním sledování připojení nebo problémy s připojením k upstreamu — a která úloha je za ně zodpovědná.

Krok 1: Vyhledání poklesů na úrovni oboru názvů

Otevřete Pod Flows (Namespace). Teplotní mapy odhalují jmenné prostory a pody s nejvyšší mírou odchozího a příchozího úbytku.

Jasnější buňky označují vyšší míru poklesu. Poznamenejte si obor názvů a časové okno.

Krok 2: Podrobně se zabývat ovlivněným zatížením

Otevřete Drop (Workload) a vyberte úlohu, kterou jste identifikovali.

• Snímek zatížení ukazuje maximální a minimální poklesy odchozích paketů za sekundu. Použijte ho k posouzení závažnosti.

  

• Vyřazený provoz podle důvodu je nejdůležitější panel. Důvod vám řekne, co opravit:

  • Zásada byla odepřena – NetworkPolicy nebo CiliumNetworkPolicy blokuje provoz.
  • CT: Vložení mapy se nezdařilo – tabulka sledování připojení je plná; škálování uzlu nebo snížení četnosti změn připojení
  • Nepodporovaný protokol L3 / Neplatný paket – aplikace nebo proxy server odesílají poškozený provoz.

  

• Teplotní mapa příchozích/odchozích výpadků. Určuje, které konkrétní páry podů ztrácejí provoz.

  

• Skládané celkové poklesy podle zdrojového podu. Pořadí podle závažnosti určuje viníky, abyste věděli, na kterou repliku se nejprve podívat.

  

Krok 3: Potvrzení vyřazených toků v uložených protokolech

Najděte přesné zdrojové a cílové zátěže vyřazeného datového provozu. Verdict, DropReasonnamespaces a úlohy jsou všechny součástí agregačního klíče, takže tento dotaz funguje na agregovaných datech:

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

Až ho identifikujete, omezte ho na jeden jmenný prostor.

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

Řídicí panel Flow Logs na portálu Azure zobrazuje stejná data vizuálně, včetně grafu závislostí služby, který zvýrazňuje blokované cesty.

Krok 4: Ověření zásad

Jakmile znáte zdrojový a cílový pod:

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

Porovná neúspěšný tok s pravidly příchozího a výchozího přenosu dat. Nejběžnější příčinou je přidání výchozího pravidla zamítnutí bez nastavení pravidla povolení pro legitimní cestu.

Krok 5: Ověření opravy

Po úpravě zásad by měl být graf pro Dropped Traffic by Reason rovný. Znovu spusťte dotaz KQL – DROPPED měly by se přestat zobrazovat verdikty pro daný pár zdroje a cíle.

Tip

Pokud prošetřujete aktivní incident a uložené protokoly nejsou povolené, spusťte stream hubble observe --verdict DROPPED --namespace <ns> za provozu, aniž byste změnili konfiguraci clusteru.

---

Playbook 3: Vyhledání nerovnováhy v síťovém provozu a aktivních uzlů

Příznak Několik podů nasazení jsou přetížené CPU nebo sítí, zatímco jiné jsou nečinné. Tcp resetuje stoupání. Sestavy latence pocházejí od uživatelů (latence samotná není viditelná v metrikách ACNS – viz poznámka v mentálním modelu).

Cílem. Určete, které pody nesou nepřiměřený provoz a jestli resetování značí přetížení nebo chybné vyrovnávání zatížení.

Krok 1: Porovnání provozu na úrovni podu

Otevřete Pod Flows (Procesy pracovní zátěže). Snímek zatížení shrnuje odchozí a příchozí provoz a ztráty.

Panel typu provozu podle tras ukazuje podobu provozu v průběhu času. Široká mezera mezi odchozím a příchozím objemem často poukazuje na úzké místo v toku.

Krok 2: Najděte horké skupiny pomocí tepelných map.

Heatmapy na úrovni podů dělají nevyváženost zřejmou. Pokud se jeden pod (například default/tcp-client-0) zobrazí v odchozí i příchozí heatmapě s mnohem tmavšími buňkami než jeho repliky, provoz je tam koncentrovaný.

Běžné příčiny:

• Služba sessionAffinity: ClientIP ukotví klienty na jeden pod.
• Bezobslužná služba s rychlým překladem DNS.
• Hašování externího balancéru zatížení na nízkokardinalitním poli.

Krok 3: Použití resetování protokolu TCP jako signálu sytosti

Otevřete panely metrik resetování protokolu TCP .

• Tepelná mapa odchozích TCP RST podle zdrojového podu. Horký zdrojový pod, který také generuje RST, je přetížen – aplikace agresivně ukončuje připojení.

  

• Heatmapa příchozího protokolu TCP RST podle cílového pouzdra. Pokud pod přijímá RST z mnoha zdrojů, obvykle to znamená, že nemůže přijímat nová připojení dostatečně rychle (plná fronta, pomalu naslouchající).

  

• Celkový součet RST podle zdroje/cíle. Trendy v průběhu času vám říkají, jestli se jedná o incident, nebo o nový stabilní stav.

Krok 4: Potvrzení pomocí protokolů

Identifikujte nejvytíženější úlohy podle celkového objemu datového toku. Použijte agregované sloupce počtu toků místo count(), které počítají pouze agregované řádky, nikoli základní toky.

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

Note

Příznaky TCP pro jednotlivé pakety (například RST) nejsou součástí agregačního klíče, takže se zahodí z agregovaných řádků v ContainerNetworkLogs. Pokud chcete prozkoumat resetování protokolu TCP na úrovni toku, použijte výše uvedené řídicí panely pro resetování PROTOKOLU TCP a cestu k protokolům na vyžádání – streamujte živé toky RST s hubble observe --type trace --verdict FORWARDED --tcp-flags RST.

Krok 5: Ověření opravy

Po škálování úlohy, opětovném vyvážení služby nebo opravě pravidel spřažení by se tepelná mapa měla rovnoměrněji zjasnit na více podů a rychlost TCP RST by měla klesnout.

---

Playbook 4: Monitorování stavu sítě na úrovni clusteru

Tuto možnost použijte v případě, že potřebujete zobrazení flotily: plánování kapacity, řídicí panely na volání nebo rychlá kontrola stavu v mnoha clusterech.

Otevřete Kubernetes / sítě / clustery.

Signály ke sledování a významu:

Panel	Sledujte	Pravděpodobná příčina
Bajty / přeposílané pakety	Náhlé útesy nebo špičky	Úzké místo nebo restart zatížení
Bajty / Ztracené pakety (cluster)	Trvalé stoupání	Regrese zásad nebo sytá vazba
Byty / zahozené pakety podle důvodu	Nový důvod se objevuje	Nový problém s chybnou konfigurací nebo úrovní jádra
Bajty / pakety odmítnuté uzlem	Dominování jednoho uzlu	Místní hardware uzlu, chybná konfigurace nebo hlučný soused
Distribuce stavu připojení TCP	Nadbytečné SYN_SENT nebo TIME_WAIT	Selhání připojení nebo četnost změn soketů z krátkodobých připojení

Když něco na tomto řídicím panelu vypadá špatně, přejděte na odpovídající příručku (Příručka 1 pro DNS, Příručka 2 pro ztráty, Příručka 3 pro přetížené pody).

---

Playbook 5: Diagnostika chyb aplikační vrstvy (L7)

Příznak Míra chyb HTTP 4xx/5xx stoupá. gRPC volání se nezdaří. Kafka Consumers zaostávají. K dispozici v clusterech Cilium s povoleným vynucením zásad L7 a CiliumNetworkPolicy, který obsahuje pravidla L7 – viz Konfigurace zásad vrstvy 7.

Cílem. Zjistěte, jestli chyby L7 pocházejí z chybně nakonfigurovaných klientů, selhání na straně serveru nebo odepřených toků.

Note

Vynucení L7 vyžaduje vytvoření nebo aktualizaci clusteru .--acns-advanced-networkpolicies L7 Nastavení L7 také umožňuje filtrování plně kvalifikovaného názvu domény. Pravidla L7 nejsou podporována v CiliumClusterwideNetworkPolicy (CCNP) a provoz L7 prochází přes proxy server envoy, který může přidat latenci nad ~3 000 požadavků za sekundu na uzel. Viz aspekty zásad L7.

Krok 1: Otevření řídicího panelu L7

Použijte Kubernetes / Síťování / L7 (Úloha) pro jednu službu nebo L7 (Obor názvů) pro celého tenanta.

Krok 2: Rozlišení mezi zablokovaným a přesměrovaným HTTP provozem

Výsledkový panel rozdělí provoz HTTP na předané a zamítnuté toky. Špička vyřazeného protokolu HTTP obvykle znamená, že CiliumNetworkPolicy zamítá požadavek na L7 (například blokuje cestu nebo metodu).

Krok 3: Sledování stavových kódů v průběhu času

Na panelu stavového kódu se dozvíte, jestli se jedná o chyby na straně klienta nebo na straně serveru. Nárůst 4xx ukazuje na chybné vstupy, tokeny s vypršenou platností nebo odepřené cesty. Nárůst výskytů 5xx chyb kvůli selhání back-endu.

Krok 4: Vyhledání problémových podů

Heatmapa 4xx ukazuje, z jakých zdrojových podů pochází nejvíce neúspěšných požadavků. Jeden jasně zářící pod obvykle znamená zaseknutou smyčku opakovaného pokusu klienta nebo chybně nakonfigurovanou repliku.

Krok 5: Potvrzení pomocí KQL

Načtení provozu HTTP rozděleného podle stavového kódu Layer7.http.code je součástí agregačního klíče, takže to funguje s agregovanými řádky:

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

Pro gRPC a Kafka Layer7 nese datovou část specifickou pro protokol, ale pouze http.code a dns.rcode jsou agregační klíče. Verdict Vyfiltrujte identitu úlohy a protokoly na vyžádání používejte v případě, že potřebujete metodu gRPC nebo téma 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

Note

Jemně odstupňované atributy L7 (adresy URL HTTP, metody gRPC, témata Kafka, názvy dotazů DNS) nejsou v agregačním klíči a jsou vyřazeny z agregovaných řádků. Pro tuto úroveň podrobností použijte toky Hubble na vyžádání.

Na co se zaměřit během analýzy L7 RCA

• Objem a tvar provozu. K nalezení nerovnováhy použijte heat mapy; Jedna horká replika často vysvětluje chybovost.
• Trend stavových kódů 4xx vs 5xx zužuje šetření na straně klienta nebo serveru.
• Verdikt.Odmítnuté L7 toky znamenají, že zásada L7 žádost odmítá – přečtěte si zásadu a potvrďte záměr.

---

Podrobný rozbor funkcí (kdy použít co)

Jakmile znáte playbooky, použijte tuto část jako stručný přehled.

Metriky sítě kontejnerů

• Používá se pro: detekce anomálií, řídicí panely, upozorňování, plánování kapacity.
• Přeskočit pro: kořenová příčina, která potřebuje identifikaci (který pod, kterou cestu, který verdikt).
• Členitost: na úrovni uzlu na všech datových rovinách; na úrovni podu v systému Linux.
• Úlohy citlivé na náklady: Pomocí filtrování metrik na clusterech Cilium zachovávejte jenom obory názvů, popisky a typy metrik, o které vám záleží. Filtrování probíhá před sběrem dat, takže nežádoucí řady nikdy nedorazí k Prometheovi.

Protokoly sítě kontejneru (uložené)

• Používá se pro: analýza původní příčiny, historické trendy, dodržování předpisů nebo audit.

• Rovina dat:Pouze Cilium. Uložené protokoly nejsou k dispozici v clusterech mimo Cilium.

• Povinný krok: Definujte ContainerNetworkLog CRD vybírající požadovaný provoz. Bez něj se neshromažďují žádné protokoly. Viz Nastavení protokolů sítě kontejneru.

• Kam jsou protokoly ukládány: Cilium ve výchozím nastavení zapisuje záznamy toku do /var/log/acns/hubble/events.log každého uzlu (50 MB kruhový buffer). Odtud máte dvě cesty k úložišti:

  • Azure Log Analytics (spravované, doporučené) – Container Insights odesílá protokoly do tabulky ContainerNetworkLogs pro KQL dotazy a integrované řídicí panely portálu Azure.
  • Přineste si vlastního kolektoru – nasměrujte agenta kompatibilního s OpenTelemetry (Splunk, Datadog, Elastic, jakýkoli OTel kolektor) na cestu ke spuštěním protokolům hostitele, abyste mohli přeposílat toky do vašeho existujícího zásobníku pozorovatelnosti, a to buď místo, nebo kromě Log Analytics.

• Řízení nákladů: Agregace protokolu toků sjednocuje podobné toky během 30sekundového okna, zachovává vzory při snižování objemu. Kombinujte s úzkým includeFilters pro nejlepší výsledky.

• Vizualizace: použijte řídicí panely Flow Logs – Analytická vrstva nebo Flow Logs – Základní vrstva v části Azure InsightsContainersNetworking.

  

  

Protokoly sítě kontejnerů (na vyžádání)

• Používá se pro: živé incidenty, občasné problémy, jednorázové šetření beze změny konfigurace kolekce.

• Datový plán:Pouze Cilium.

• Nástroje: Hubble CLI pro filtrování terminálu; Hubble UI pro vizuální mapy služba-služba.

• Žádné trvalé úložiště, žádné další náklady, žádné nastavení nad rámec povolení ACNS.

  

Filtrování metrik (klastry Cilium)

Pomocí ContainerNetworkMetric CRD můžete určit, které metriky Hubble se exportují pro každý uzel. Užitečné, když potřebujete široké monitorování u několika důležitých jmenných prostorů, ale nechcete platit za datové toky s vysokou kardinalitou napříč všemi.

Obvyklé scénáře:

• Udržujte DNS a odstraňte metriky v celém clusteru; omezte metriky toku na produkční jmenné prostory.
• Vylučte obory názvů systému ve velkém objemu, jako je kube-system, ze metrik toku.
• Vymezit obory názvů pro jednotlivé tenanty na jejich vlastní bloky filtrů.

Úplné příklady CRD najdete v tématu Konfigurace filtrování metrik sítě kontejnerů.

---

Osvědčené postupy

• Začněte široce a pak zúžit. Povolte široké protokoly nebo metriky po dobu několika dnů, zkontrolujte, co skutečně používáte, a pak utáhněte ContainerNetworkLog a ContainerNetworkMetric filtry.
• Zachovejte časové intervaly metrik a protokolů zarovnané. Při vyšetřování incidentu použijte stejný počáteční/koncový čas na řídicím panelu a dotazu KQL, aby signály korelovaly čistě.
• Preferujte předdefinované řídicí panely. Probírá nejčastější dotazy. Vlastní panely jsou obvykle potřeba jenom po dokončení počátečního třídění.
• Vrstva ContainerNetworkLogs podle potřeby. Přechod na úroveň Basic pro úlohy citlivé na náklady; použijte odpovídající řídicí panel úrovně Basic. Viz plány tabulek Log Analytics.
• Zachází s agregovanými protokoly a protokoly na vyžádání jako s doplňky. Agregované protokoly jsou skvělé pro detekci trendů a vzorů, ale přeskočte podrobnosti o jednotlivých tocích. Používejte na vyžádání (Hubble) pro jemně odstupňovanou kontrolu.
• Ověřte opravy pomocí stejného panelu, na kterém došlo k problému. Pokud je stejný panel po změně plochý, máte skutečnou opravu.

Běžné nástrahy

• Zapomeňte na ContainerNetworkLog CRD. Povolení protokolů sítě kontejneru v clusteru nic nezachytí, dokud nenakonfigurujete alespoň jeden CRD, který vybere provoz.
• Pokoušíte se použít uložené protokoly pro živé incidenty, které už prošly. Pokud protokoly nebyly povoleny před incidentem nebo spadaly mimo zachycený filtr, přepněte na Hubble toky na vyžádání pro další výskyt.
• Řídicí panely L7 jsou prázdné v clusteru Cilium. Metriky L7 vyžadují --acns-advanced-networkpolicies L7 na clusteru aCiliumNetworkPolicy s pravidly L7. CCNP nepodporuje pravidla L7. Viz Použití zásad L7.
• Metriky DNS jsou prázdné v Cilium. DNS viditelnost vyžaduje CiliumNetworkPolicy s pravidlem dns, obvykle společně s toFQDNs.
• matchPattern: "*" zablokuje všechny DNS. Holý zástupný znak není podporován. Použijte vzor s úvodním zástupným znakem, například *.example.com nebo app*.example.com. Viz Použití zásad filtrování plně kvalifikovaného názvu domény.

Pozorovatelnost sítě, která je součástí monitorování Azure

Když povolíte spravovanou službu Azure Monitor pro Prometheus v clusteru AKS, základní metriky sledování sítě uzlů se ve výchozím nastavení shromažďují prostřednictvím cíle networkobservabilityRetina. To poskytuje:

• Základní metriky sítě na úrovni uzlu: Základní viditelnost síťového provozu na úrovni uzlu
• Výchozí cíle Prometheus: Metriky pozorovatelnosti sítě jsou automaticky shromažďovány službou Azure Monitor.
• Integrace služby Azure Monitor: Bezproblémová integrace se službou Azure Monitor; metriky se shromažďují automaticky a dají se vizualizovat v Grafana.
• Nevyžaduje se žádné další nastavení: Automatické povolení při konfiguraci spravovaného nástroje Prometheus ve službě Azure Monitor
• Podpora Microsoftu: Podporováno jako součást služby Azure Monitor a AKS

Poznámka: To vyžaduje, aby byla ve vašem clusteru AKS povolená spravovaná služba Azure Monitoru pro Prometheus, která může mít přidružené náklady.

Začínáme: Povolte spravovanou službu Azure Monitor pro Prometheus ve vašem clusteru AKS prostřednictvím Azure Portalu nebo rozhraní příkazového řádku. Metriky pozorovatelnosti sítě se automaticky shromažďují a budou dostupné pro vizualizaci ve službě Azure Managed Grafana.

Pozorovatelnost sítě s operačním systémem Retina OSS

I když Advanced Container Networking Services (ACNS) je placená nabídka, která poskytuje komplexní možnosti pozorovatelnosti sítě, Microsoft také podporuje pozorovatelnost sítě s operačním systémem Retina OSS, opensourcovou platformou pozorovatelnosti sítě, která poskytuje základní možnosti monitorování sítě.

Retina OSS je opensourcová platforma pozorovatelnosti dostupná na retina.sh a GitHubu. Poskytuje:

• Pozorovatelnost sítě založená na eBPF: Využívá technologie eBPF ke shromažďování přehledů s minimální režií.
• Hloubková analýza provozu s kontextem Kubernetes: Komplexní zachytávání a analýza toků síťového provozu s úplnou integrací Kubernetes
• Pokročilá shromažďování metrik: metriky vrstvy 4, metriky DNS a možnosti zachytávání distribuovaných paketů
• Rozšiřitelnost založená na modulech plug-in: Přizpůsobení a rozšíření funkcí prostřednictvím architektury modulů plug-in
• Metriky kompatibilní s Prometheus: Export komplexních síťových metrik ve formátu Prometheus s konfigurovatelnými režimy metrik
• Zachytávání distribuovaných paketů: Zachytávání paketů na vyžádání napříč několika uzly pro účely hloubkového řešení potíží
• Nezávislá na platformě a CNI: Funguje s jakýmkoli clusterem Kubernetes (AKS, s podporou arc, místně), s libovolným operačním systémem (Linux nebo Windows) a s jakýmkoli CNI
• Podpora komunity: Open source s podporou a příspěvky řízenými komunitou
• Samoobslužná správa: Úplná kontrola nad nasazením a konfigurací
• Integrace Hubble: Integrace s Cilium's Hubble pro další síťové přehledy

Začínáme: Nasazení Retina OSS pomocí Helm chartů nebo Kubernetes manifestů z oficiálního úložiště Retina. Nastavte Prometheus a Grafana pro vizualizaci metrik, konfiguraci hloubkové analýzy provozu s kontextem Kubernetes, povolení distribuovaného zachytávání paketů pro pokročilé řešení potíží a přizpůsobení funkcí pomocí architektury založené na modulu plug-in pro konkrétní případy použití.

Porovnání nabídek pozorovatelnosti sítě

Offering	Support	Náklady	Vedení	Nasazení	Případy použití
Advanced Container Networking Services (ACNS)	Podpora microsoftu pro velké organizace	Placená služba Azure	Plně spravovaná microsoftem	Integrace Azure jedním kliknutím	Sledování spravovaného podniku: toků sítě na úrovni podů, metriky na úrovni podů, metriky DNS, trvalé uložené záznamy, analýza provozu vrstvy 7, vynucení bezpečnostních politik sítě, poskytování přehledů o dodržování předpisů, pokročilé řídicí panely Grafana, přehledy s podporou AI
Pozorovatelnost sítě (Azure Monitor)	Podpora Microsoftu jako součást služby Azure Monitor	Spravovaný systém Prometheus v rámci Azure Monitor (platí se náklady na Azure Monitor)	Plně spravovaná microsoftem	Automatická, když je povolená spravovaná služba Azure Monitor Prometheus	Monitorování sítě uzlů: Pouze metriky sítě na úrovni clusteru a uzlu, žádná viditelnost na úrovni podů, žádné uložené protokoly, žádná analýza DNS – vhodná pro základní monitorování infrastruktury a uživatele, kteří chtějí minimální pozorovatelnost sítě bez další konfigurace
Retina OSS	Podpora komunity	Bezplatné a opensourcové	Samostatně spravovaný	Ruční nastavení prostřednictvím Helmu nebo manifestů v jakémkoli clusteru Kubernetes	Nespravovaná pokročilá pozorovatelnost: zachytávání paketů v reálném čase, vlastní shromažďování metrik, hloubková analýza sítě založená na protokolu eBPF, integrace Hubble, nasazení s více cloudy, vlastní kanály pozorovatelnosti, pokročilé ladění s integrací tcpdump/Wireshark a vývojová/testovací prostředí

Víc se uč

Advanced Container Networking Services (ACNS)

• Přehled platformy:Co je Advanced Container Networking Services pro AKS?
• Nastavení pozorovatelnosti:Nastavení pozorovatelnosti kontejnerové sítě
• Metriky sítě kontejnerů:Přehled metrik sítě kontejnerů
• Protokoly sítě kontejnerů:Přehled protokolů sítě kontejnerů a nastavení protokolů sítě kontejnerů
• Filtrování metrik (Cilium):Konfigurace filtrování metrik sítě kontejnerů

Diagnostika řízená AI

• Container Network Insights Agent (Preview):Přehled a nastavení agenta
• Server AKS MCP:Server kontextu modelu AKS

Bezpečnost kontejnerových sítí (Cilium)

• Filtrování plně kvalifikovaného názvu domény:Koncepty a použití zásad filtrování plně kvalifikovaného názvu domény
• Zásady vrstvy 7:Koncepty a použití zásad L7
• Vzájemné tls (Cilium):Koncepty a konfigurace vzájemného protokolu TLS
• Šifrování v přenosu:Koncepty šifrování WireGuard

Datová rovina a platforma

• Azure CNI s technologií Cilium:Konfiguruje Azure CNI s technologií Cilium
• Výkon směrování hostitele eBPF:Výkon sítě kontejnerů s eBPF směrováním hostitele
• Log Analytics plány tabulek:Zvolte plán tabulky na základě používání dat

Opensourcové nástroje

• Retina:retina.sh a GitHub úložiště Microsoft Retina
• Hubble (projekt Cilium):Dokumentace k Hubble