Co to są metryki sieci kontenerów?

Każdy zasobnik, usługa i węzeł w klastrze Kubernetes stale generuje aktywność sieci: otwieranie połączeń, przekazywanie pakietów lub usuwanie ich, rozwiązywanie lub niepowodzenie zapytań DNS. Zrozumienie, że działanie jest niezbędne do debugowania, planowania pojemności i utrzymania dobrej kondycji usług. Większość konfiguracji monitorowania ma dwa podstawowe niedostatki:

• Za mało widoczności. Agregacje na poziomie węzła informują, że coś jest nie tak, ale nie gdzie. Bez podziałów na poziomie podu, które obejmują kontekst źródłowy i docelowy, izolowanie problematycznego obciążenia oznacza zgadywanie.
• Za dużo danych na dużą skalę. Klaster z uruchomionymi setkami mikrousług może produkować tysiące serii czasowych metryk na węzeł. Zbieranie wszystkich elementów zwiększa koszty magazynowania i spowalnia pulpity nawigacyjne.

Metryki sieci kontenerów w Advanced Container Networking Services dla Azure Kubernetes Service (AKS) rozwiązują oba problemy. Funkcja zbiera metryki sieciowe na poziomie węzła i podu w obsługiwanych płaszczyznach danych Cilium i nie-Cilium na systemach Linux i Windows.

W klastrach Cilium możesz przejść krok dalej dzięki filtrowaniu na poziomie źródła, co pozwala wybrać dokładnie, które przestrzenie nazw, obciążenia i typy metryk są zbierane przed opuszczeniem węzła.

Filtrowanie danych o metrykach kontenerów to mechanizm wstępnego przetwarzania danych obserwacyjnych. Zamiast zbierać wszystkie dostępne metryki i filtrować je później na pulpitach nawigacyjnych lub w zapytaniach, zdefiniuj, co zbierać u źródła. To umożliwia zachowanie metryk o wysokiej wartości dla obciążeń, którymi się zajmujesz, i unikanie wczytywania szeregów czasowych, które są o niskiej wartości lub pełne szumu.

Wynik: możliwość aktywnego monitorowania sieci na dowolnym obsługiwanym torze danych, z opcjonalnym, efektywnym kosztowo filtrowaniem na Cilium.

Metryki sieci kontenerów zapewniają szczegółową widoczność na poziomie obciążenia na potrzeby rozwiązywania problemów i planowania, podczas gdy filtrowanie na poziomie źródła w usłudze Cilium pomaga utrzymać koszty obserwowalności proporcjonalne do obciążeń krytycznych dla działania firmy.

Błyskawiczne zbieranie i filtrowanie

Skorzystaj z tej tabeli, aby szybko zrozumieć, gdzie dostępna jest szeroka kolekcja i gdzie dostępne jest szczegółowe filtrowanie:

Najważniejsze korzyści

• Granularność na poziomie węzła i poda. Śledzenie ilości ruchu, współczynników spadku i stanów połączeń na poziomie węzła na potrzeby kondycji infrastruktury. Zanurz się w szczegóły poszczególnych podów z etykietami źródłowymi i docelowymi, aby zidentyfikować dokładne obciążenie powodujące problem.

• Szybsze rozwiązywanie problemów. Gdy usługa zacznie usuwać pakiety lub zapytania DNS kończą się niepowodzeniem, metryki na poziomie zasobnika umożliwiają izolowanie problemu z określonym zasobnikem, przestrzenią nazw lub protokołem w ciągu kilku sekund, a nie godzin.

• Elastyczna wizualizacja. Przechowuj metryki w Azure Managed Prometheus i wizualizuj je w Azure Managed Grafana (w pełni zarządzane) lub przynieś własną infrastrukturę Prometheus i Grafana.

• Skalowalne według projektu. Potok obsługuje duże, dynamiczne klastry z setkami węzłów i tysiącami podów, bez konieczności wybierania pomiędzy kompleksowym pokryciem a zarządzalnymi wolumenami danych.

• Docelowa możliwość obserwacji (klastry cilium). W przypadku klastrów Cilium filtrowanie na poziomie źródła umożliwia definiowanie przestrzeni nazw, etykiet zasobników lub typów metryk, o których chodzi, i zbieranie ich tylko. Nie jest wymagane przycinanie po zakończeniu zbierania danych.

• Niższe koszty pozyskiwania metryk (klastry Cilium). Ponieważ filtrowanie odbywa się w źródle na każdym węźle, niepożądane serie czasowe metryk nigdy nie są zbierane, przesyłane ani przetwarzane do backendu Prometheus. Płacisz tylko za metryki, których rzeczywiście potrzebujesz. W dużych klastrach, w których niefiltrowana kolekcja może generować tysiące szeregów czasowych na węzeł, filtrowanie na poziomie źródła może znacznie zmniejszyć koszty związane z ingestowaniem i przechowywaniem w zarządzanym przez Azure Prometheus.

Jak to działa

Stos agenta na każdym węźle zależy od płaszczyzny danych, jak pokazano na diagramie.

Węzły Cilium systemu Linux używają warstwowego stosu opartego na eBPF: punkty zaczepienia jądra eBPF przechwytują nieprzetworzone dane ruchu, przetwarza je Cilium i Hubble udostępnia je jako metryki formatu Prometheus. Ponieważ Hubble znajduje się między węzłem a punktem końcowym pobierania danych, filtrowanie na poziomie źródłowym odbywa się na tej warstwie. Wybierasz przestrzenie nazw, etykiety zasobników i typy metryk przed opuszczeniem węzła przez dane.

Węzły Linux bez Cilium używają haków jądra eBPF przekazujących do Microsoft Retina, z warstwą Hubble na górze do inspekcji ruchu sieciowego. Microsoft Retina obsługuje zbieranie metryk i eksportuje metryki na poziomie węzła i na poziomie podu w formacie Prometheus.

Ze wszystkich ścieżek metryki są zbierane w formacie Prometheus i przesyłane do Azure Managed Prometheus lub własnego zaplecza Prometheus, a następnie wizualizowane w Azure Managed Grafana lub własnym środowisku Grafana.

Aby rozpocząć, skonfiguruj metryki sieci kontenera, a następnie skonfiguruj filtrowanie metryk sieci kontenera dla klastrów Cilium.

Kiedy należy używać metryk sieci kontenerów

Metryki sieci kontenerów są przeznaczone dla zespołów, które wymagają skoncentrowanych, przydatnych danych sieciowych, a nie nieprzetworzonych danych telemetrycznych. Typowe scenariusze obejmują:

• Debugowanie określonego obciążenia. Użyj metryk na poziomie podu, aby odizolować straty pakietów, resetowanie protokołu TCP lub błędy DNS dla konkretnej usługi. W klastrach Cilium filtrowanie może zawęzić kolekcję tylko do tego namespace lub etykiety poda, eliminując szum obejmujący cały klaster.
• Monitorowanie klastrów wielodostępnych. Śledź kondycję sieci w ramach przestrzeni nazw, aby każdy zespół miał widoczność własnych wzorców ruchu. W klastrach Cilium filtracja zakresowa ogranicza kolekcję do przestrzeni nazw specyficznych dla najemcy.
• Planowanie pojemności. Śledzenie liczby przesłanych dalej i porzuconych bajtów dla każdego węzła, aby zidentyfikować nasycone łącza lub niezrównoważone rozmieszczenie obciążenia.
• Monitorowanie kondycji DNS. Uwidaczniaj niepowodzenia zapytań DNS i wolne czasy rozwiązywania zapytań, aby przechwycić problemy przed eskalacją błędów aplikacji.
• Zmniejszenie kosztów obserwowania na dużą skalę. W dużych klastrach niefiltrowana kolekcja może generować tysiące szeregów czasowych na węzeł. W klastrach Cilium filtrowanie na poziomie źródła usuwa niepożądane serie przed przetwarzaniem, co pozwala na to, by koszty pozostawały zgodne z tymi wybranymi obciążeniami i typami metryk.

Jak wybrać, co należy zbierać (klastry cilium)

Użyj tego modelu wdrażania, aby zrównoważyć widoczność i koszty:

1. Zacznij od szerokiej kolekcji w przestrzeni nazw nieprodukcyjnej, aby ustanowić punkt odniesienia.
2. Zachowaj metryki upuszczenia pakietów, stanu DNS i TCP dla krytycznych przestrzeni nazw.
3. Ogranicz metryki przepływu o wysokiej kardynalności tylko do obciążeń kluczowych dla firmy.
4. Przejrzyj trendy pozyskiwania Prometheus i ulepszaj filtry co tydzień.

Takie podejście pomaga zachować metryki o wysokiej wartości, kontrolując jednocześnie wzrost szeregów czasowych i koszty pozyskiwania danych.

Przed przejrzeniem tabel metryk

Pamiętaj o tych kwestiach:

• Metryki na poziomie węzła są dostępne na obsługiwanych płaszczyznach danych Cilium i innych niż Cilium.
• Metryki na poziomie podu są dostępne w systemie Linux.
• Filtrowanie na poziomie źródła jest dostępne tylko w klastrach Cilium.
• W klastrach Cilium metryki DNS wymagają stosowania zasad sieciowych Cilium FQDN.

Referencja metryk

Metryki na poziomie węzła

Metryki na poziomie węzła zapewniają zagregowane statystyki ruchu na węzeł — przekazywane i porzucone pakiety, liczby bajtów i stany połączenia. Te metryki są przechowywane w formacie Prometheus i można je wizualizować w narzędziu Grafana.

Następujące metryki są agregowane na każdy węzeł. Wszystkie metryki obejmują następujące etykiety:

• cluster
• instance (nazwa węzła)

Metryki na poziomie zasobnika (metryki Hub)

Metryki na poziomie podu obejmują informacje o podzie źródłowym i docelowym, dzięki czemu można wskazać problemy z siecią na poziomie poszczególnych obciążeń roboczych. Te metryki obejmują wolumin ruchu, porzucone pakiety, resetowanie protokołu TCP i przepływy warstwy 4/Warstwy 7.

Metryki DNS (liczby zapytań, kody odpowiedzi i błędy) są domyślnie zbierane na płaszczyznach danych innych niż Cilium. Na płaszczyznach danych Cilium metryki DNS wymagają zasad sieciowych Cilium FQDN. Możesz również rozwiązywać problemy z systemem DNS w czasie rzeczywistym przy użyciu interfejsu wiersza polecenia hubble'a.

W poniższej tabeli opisano metryki, które są agregowane dla każdego zasobnika (informacje o węźle są przechowywane).

Wszystkie metryki obejmują etykiety:

• cluster

• instance (nazwa węzła)

• source lub destination

  • W przypadku ruchu wychodzącego etykieta source wskazuje przestrzeń nazw i nazwę podu źródłowego.

  • W przypadku ruchu przychodzącego etykieta destination wskazuje przestrzeń nazw i nazwę zasobnika docelowego.

Limitations

Platforma i płaszczyzna danych:

• Metryki na poziomie zasobnika są dostępne tylko w systemie Linux.
• Płaszczyzna danych Cilium jest obsługiwana począwszy od wersji Kubernetes 1.29.
• Filtrowanie metryk na poziomie źródłowym jest dostępne tylko w klastrach Cilium.
• Etykiety metryk mają subtelne różnice między klastrami Cilium i nie-Cilium.

Metryki DNS:

• W klastrach Cilium metryki DNS wymagają zasad sieciowych Cilium FQDN lub można użyć interfejsu wiersza poleceń Hubble do rozwiązywania problemów z DNS w czasie rzeczywistym.

Znane problemy:

• Jeśli agent węzła Hubble ulegnie awarii, przekaźnik Hubble może się zawiesić, co może przerwać sesje Hubble CLI.

Obsługa standardu FIPS (tylko płaszczyzny danych innych niż Cilium):

• FiPS nie jest dostępny w węzłach Ubuntu 20.04 z powodu ograniczeń jądra. Zamiast tego użyj puli węzłów Azure Linux lub Ubuntu 22.04. To ograniczenie nie dotyczy płaszczyzn danych Cilium.

Skala:

• Usługa zarządzana Prometheus w Azure Monitor i Azure Managed Grafana nakłada specyficzne dla usługi ograniczenia skali. Aby uzyskać więcej informacji, zobacz artykuł Scrape Prometheus metrics at scale in Azure Monitor.

Pricing

Aby uzyskać więcej informacji na temat cen, zobacz Advanced Container Networking Services — cennik.

Treści powiązane

• Konfigurowanie metryk sieci kontenera
• Konfigurowanie filtrowania metryk sieci kontenerów
• Zaawansowane usługi sieciowe dla kontenerów w AKS
• Obserwowanie sieci kontenerów w usługach Advanced Container Networking Services
• Zabezpieczenia sieci kontenerów w usłudze Advanced Container Networking Services