Skonfiguruj metryki sieci kontenera dla Azure Kubernetes Service (AKS)

Użyj metryk sieci kontenera, aby zidentyfikować spadki pakietów, zbadać zachowanie systemu DNS i znaleźć obciążenia robocze związane z problemami z siecią. Ten przewodnik umożliwia zbieranie danych w usłudze Azure Kubernetes Service (AKS), łączy je z zapleczem Prometheus i pokazuje, jak wyświetlać kondycję sieci na pulpitach nawigacyjnych ACNS Grafana.

Użyj usługi zarządzanej Azure Monitor dla rozwiązania Prometheus i wyświetl pulpity nawigacyjne sieci bezpośrednio w portalu Azure. Pulpity nawigacyjne Grafana w portalu są dostępne bez dodatkowych kosztów; nie musisz tworzyć wystąpienia Azure Managed Grafana. Możesz też użyć własnego wdrożenia Rozwiązania Prometheus i narzędzia Grafana. Kolekcja metryk jest dostępna na obsługiwanych płaszczyznach danych Cilium i innych niż Cilium; Metryki na poziomie zasobnika wymagają systemu Linux. Zobacz omówienie metryk, aby uzyskać informacje o obsługiwanych platformach i dostępnych metrykach.

W klastrach Cilium można następnie filtrować poszczególne metryki według obciążenia lub tożsamości zabezpieczeń albo włączyć metryki dla zewnętrznych docelowych adresów IP i portów docelowych. Są to opcjonalne następne kroki, a nie wymagania dotyczące podstawowego zbierania danych.

Na przykład zacznij od filtrów uwzględniania w celu zbierania metryk przepływu z jednej aplikacji. Dodaj filtry wykluczania tylko wtedy, gdy potrzebujesz wyjątku, takiego jak pominięcie ruchu do określonego miejsca docelowego. Aby zachować szeroką kolekcję podczas usuwania obserwacji odrzuceń z testów obciążeniowych, należy zamiast tego użyć filtru tylko do wykluczenia. Zobacz przykłady filtrowania metryk.

Aby uzyskać informacje o przechowywanych dziennikach lub inspekcji Hubble w czasie rzeczywistym zamiast metryk, zobacz Konfigurowanie dzienników sieci kontenerów.

Prerequisites

• Konto Azure z aktywną subskrypcją. W razie potrzeby utwórz bezpłatne konto.
• Powłoka Bash w Azure Cloud Shell lub lokalnym terminalu Bash z bieżącym interfejsem Azure CLI i kubectl. Uruchom polecenie az --version, aby sprawdzić instalację CLI.
• Uprawnienia do tworzenia lub aktualizowania klastra oraz wybranych zasobów monitorowania, a także uprawnienia do odczytu obszaru roboczego Azure Monitor zawierającego metryki. W przypadku ścieżki zarządzanej zapoznaj się z wymaganiami wstępnymi Azure Monitor.
• Obsługiwana wersja Kubernetes AKS i system operacyjny węzła. Nie twórz nowych pul węzłów na wycofanych obrazach Azure Linux 2.0. Zobacz Uaktualnianie systemu operacyjnego węzła.
• Uruchamianie obciążeń z ruchem sieciowym w celu wypełnienia pulpitów nawigacyjnych obciążenia. Pusty klaster nie będzie pokazywał ruchu aplikacji.
• W przypadku metryk DNS w Cilium skonfiguruj widoczność systemu DNS, stosując zasady inspekcji DNS i generując ruch DNS. W przypadku metryk HTTP ukończ konfigurację zasad warstwy 7: włącz L7 w klastrze, zastosuj zasady inspekcji HTTP do obciążenia i wygeneruj ruch HTTP za pośrednictwem tych zasad. Konfigurowanie filtrów metryk nie stosuje tych zasad ani nie weryfikuje generowania obserwacji. Żadne z nich nie jest wymagane do podstawowego monitorowania sieci na poziomie węzła.

Krok 1: Włącz ACNS i połącz się z klastrem

Zaloguj się za pomocą az login, jeśli używasz lokalnego interfejsu wiersza polecenia. Wybierz subskrypcję i ustaw wartości używane w tym przewodniku:

az account set --subscription "<subscription-id>"
export RESOURCE_GROUP="<aks-resource-group>"
export CLUSTER_NAME="<aks-cluster-name>"
export LOCATION="<azure-region>"

Korzystanie z istniejącego klastra

Jeśli usługa ACNS jest już włączona, pomiń polecenie aktualizacji. W przeciwnym razie włącz ją:

az aks update \
    --resource-group "$RESOURCE_GROUP" \
    --name "$CLUSTER_NAME" \
    --enable-acns

Włączenie usługi ACNS nie zmienia płaszczyzny danych istniejącego klastra. Filtrowanie metryk i dodatkowe włączenie metryk opisane później wymagają Cilium. Aby uzyskać informacje o innych możliwościach usługi ACNS i ich wymaganiach wstępnych, zobacz omówienie usługi ACNS.

Lub utwórz nowy klaster

Utwórz grupę zasobów, jeśli jeszcze nie istnieje:

az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

Wybierz jedną z następujących opcji. Te polecenia używają domyślnej wersji usługi AKS Kubernetes w regionie, zamiast przypinać starszą wersję. Aby wybrać inną obsługiwaną wersję, sprawdź az aks get-versions --location "$LOCATION" -o table i dodaj --kubernetes-version z wybraną wersją.

Cilium

Wybierz pozycję Cilium, jeśli planujesz używać filtrowania metryk na poziomie źródła lub dodatkowych metryk external-IP i destination-port:

az aks create \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --generate-ssh-keys \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --node-count 2 \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

Non-Cilium

Ta opcja obsługuje zbieranie metryk dostępnych dla płaszczyzny danych spoza Cilium. Nie udostępnia ścieżki filtrowania CNM specyficznej dla Cilium ani funkcji zabezpieczeń sieciowych kontenerów. W kwestii ograniczeń FIPS zobacz ograniczenia platformy Metrics.

az aks create \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --generate-ssh-keys \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

Pobieranie poświadczeń klastra

W przypadku nowego lub istniejącego klastra połącz się i potwierdź bieżący kontekst:

az aks get-credentials --name "$CLUSTER_NAME" --resource-group "$RESOURCE_GROUP"

kubectl config current-context
kubectl get nodes

Zatrzymaj, jeśli kontekst nie jest docelowym klastrem lub polecenia kończą się niepowodzeniem. Przed kontynuowaniem rozwiąż problemy z połączeniem, uprawnieniami lub gotowością węzła.

Krok 2: Wybierz ścieżkę kolekcji

Najpierw skonfiguruj jedną ścieżkę. Jeśli już pomyślnie zbierasz metryki sieciowe, zachowaj konfigurację i przejdź do kroku 3 lub kroku 4. Konfigurowanie zduplikowanych skrobań może zwiększyć pozyskiwanie danych i zniekształcać wyniki zapytań.

Azure Managed Prometheus i pulpity nawigacyjne portalu

Użyj obszaru roboczego usługi Azure Monitor dla metryk Prometheus. Obszar roboczy Log Analytics przechowuje dzienniki i nie zastępuje tego obszaru roboczego metryk.

Poniższy przykład tworzy obszar roboczy Azure Monitor w grupie zasobów klastra. Jeśli masz już obszar roboczy, ustaw AZURE_MONITOR_NAME na jego nazwę, pomiń tworzenie i uzyskaj jego identyfikator na podstawie jego rzeczywistej grupy zasobów. Użyj lokalizacji obsługiwanej w obszarach roboczych Azure Monitor.

Tworzenie lub wybieranie obszaru roboczego Azure Monitor

export AZURE_MONITOR_NAME="<azure-monitor-name>"

az resource create \
    --resource-group "$RESOURCE_GROUP" \
    --namespace Microsoft.Monitor \
    --resource-type accounts \
    --name "$AZURE_MONITOR_NAME" \
    --location "$LOCATION" \
    --properties '{}'

Włącz zarządzaną kolekcję Prometheus

Uzyskaj identyfikator zasobu obszaru roboczego Azure Monitor:

azuremonitorId=$(az resource show \
    --resource-group "$RESOURCE_GROUP" \
    --name "$AZURE_MONITOR_NAME" \
    --resource-type "Microsoft.Monitor/accounts" \
    --query id --output tsv)

Przed kontynuowaniem sprawdź polecenie pod kątem błędów i upewnij się, że azuremonitorId zawiera identyfikator zasobu docelowego obszaru roboczego. Włącz skrobanie:

az aks update \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --enable-azure-monitor-metrics \
    --azure-monitor-workspace-resource-id "$azuremonitorId"

Sprawdź zasobniki metryk Azure Monitor:

kubectl get pods -n kube-system -o wide | grep ama-metrics

Przed sprawdzeniem danych rozwiąż problemy z niegotowymi podami. Same pody nie gwarantują skutecznego scrapowania ani pozyskiwania. W przypadku problemów z uprawnieniami lub zbieraniem danych postępuj zgodnie z instrukcjami Włącz monitorowanie w usłudze AKS.

Dla pulpitów nawigacyjnych portalu Azure nie jest wymagany żaden oddzielny zasób narzędzia Grafana ani link Grafana. Kontynuuj wybór metryk, a następnie otwórz panele sieci w kroku 4.

Twój własny Prometheus i Grafana

Użyj istniejącego wdrożenia rozwiązania Prometheus, które umożliwia odnajdywanie zasobników Kubernetes i docieranie do punktów końcowych metryk agenta. Najpierw skonfiguruj uwierzytelnianie interfejsu API Kubernetes, kontrolę dostępu opartego na rolach i dostęp sieciowy. W poniższym przykładzie opisano metryki na poziomie zasobnika Hubble'a; nie konfiguruje metryk Cilium na poziomie węzła ani metryk Retina.

Dodaj to zadanie do istniejącej scrape_configs listy, zachowując inne zadania. Jeśli operator zarządza Prometheusem, użyj obsługiwanego mechanizmu konfiguracji zamiast edytowania wygenerowanego pliku konfiguracji. Zastąp myAKSCluster etykietą klastra:

scrape_configs:
  - job_name: networkobservability-hubble
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_pod_label_k8s_app]
        regex: 'kube-system;(retina|cilium)'
        action: keep
      - source_labels: [__meta_kubernetes_pod_phase]
        regex: Running
        action: keep
      - source_labels: [__meta_kubernetes_pod_ip]
        regex: '([^:]+)'
        replacement: '$1:9965'
        target_label: __address__
      - source_labels: [__meta_kubernetes_pod_ip]
        regex: '(.+:.*)'
        replacement: '[$1]:9965'
        target_label: __address__
      - target_label: cluster
        replacement: myAKSCluster
      - source_labels: [__meta_kubernetes_pod_node_name]
        target_label: instance
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'hubble_dns_queries_total|hubble_dns_responses_total|hubble_drop_total|hubble_tcp_flags_total'
        action: keep

Zweryfikuj scaloną konfigurację za pomocą promtool check config "<prometheus-config-file>", jeśli jest ono dostępne we wdrożeniu, a następnie ponownie wczytaj Prometheus przy użyciu normalnej procedury operacyjnej. W obszarze Cele sprawdź, czy cele dla networkobservability-hubble mają stan UP. Sprawdź błędy indeksowania, jeśli nie zostały zindeksowane. W przykładzie przyjęto założenie, że punkt końcowy Hubble jest uwidoczniony na porcie 9965; sprawdź punkt końcowy wdrożenia, jeśli jest inny.

Połącz Grafanę z tym źródłem danych Prometheus. Kontynuuj wybór metryk w kroku 3, a następnie otwórz pulpity nawigacyjne w kroku 4.

Krok 3. Wybieranie metryk Hubble do pozyskiwania

Aby ograniczyć ilość danych o wysokiej kardynalności i koszty pozyskiwania, zarządzany Prometheus minimalny profil pozyskiwania domyślnie nie zbiera tych metryk:

• hubble_flows_processed_total
• hubble_flows_to_world_total
• hubble_port_distribution_total

Jeśli potrzebujesz dowolnej z tych trzech metryk, dodaj ich nazwy do istniejącej konfiguracji kolekcji. W przeciwnym razie przejdź do kroku 4.

Metryki muszą być dostępne w punkcie końcowym agenta, zanim będzie można je przetworzyć. Aby włączyć opcjonalne metryki world lub portu docelowego w Cilium, zobacz Konfigurowanie filtrowania metryk sieci kontenera.

Postępuj zgodnie z instrukcjami w poniższej sekcji dla backendu Prometheus.

Zezwalaj na rodziny metryk w zarządzanym Prometheus

Użyj wybranych opcji, aby zaktualizować networkobservabilityHubble listę dozwolonych w ama-metrics-settings-configmap ConfigMap w kube-system. Ta zmiana umożliwia modułowi zbierającemu uwzględnienie tych metryk z punktu końcowego metryk Prometheus agenta.

1. Jeśli element ConfigMap nie istnieje, utwórz go przy użyciu obsługiwanego szablonu w Dostosowywanie scrapingu Prometheusa. Jeśli już istnieje, wykonaj kopię zapasową przed wprowadzeniem zmian:

   kubectl get configmap ama-metrics-settings-configmap -n kube-system \
     -o yaml > ama-metrics-settings-before.yaml
   

   Przed kontynuowaniem usuń wszystkie błędy.

2. Otwórz ConfigMap do edycji. W schemacie v2 znajdź networkobservabilityHubble w default-targets-metrics-keep-list sekcji w obszarze data.cluster-metrics. Zachowaj istniejący schemat ConfigMap i inne ustawienia.

   kubectl edit configmap ama-metrics-settings-configmap -n kube-system
   

3. Pozostaw włączone minimalne pozyskiwanie. Dodaj każdą dodatkową nazwę metryki do istniejącejnetworkobservabilityHubble wartości, oddzielając je ciągiem |. Jeśli na przykład bieżąca wartość to:

   networkobservabilityHubble = "hubble_dns_queries_total|hubble_drop_total"
   

   Aby również pozyskać metryki przepływu, zmień ją na:

   networkobservabilityHubble = "hubble_dns_queries_total|hubble_drop_total|hubble_flows_processed_total"
   

   Użyj własnej istniejącej wartości jako punktu początkowego, a nie przykładowej wartości. To ustawienie nie jest kompletnym obiektem ConfigMap. Zbieranie większej liczby metryk może zwiększyć wolumen pozyskiwania danych i koszt.

4. Zapisz i zamknij edytor. Zezwól modułowi zbierającemu na ponowne załadowanie ustawień, a następnie wykonaj zapytanie o każdą dodaną metrykę w rozwiązaniu Prometheus. W poprzednim przykładzie wykonaj zapytanie hubble_flows_processed_total i sprawdź najnowsze próbki podczas przepływu odpowiedniego ruchu. Wykonaj również zapytanie dotyczące istniejącej metryki, na przykład hubble_dns_queries_total, jeśli już ją zbierasz, aby potwierdzić, że nadal otrzymuje nowe próbki. Przed przejściem do kroku 4 sprawdź pulpity nawigacyjne i alerty, które używają tych metryk.

Zezwalaj rodzinom metryk w swoim Prometheusie

Dołącz dodatkowe nazwy metryk do wyrażenia keep istniejącego metric_relabel_configs zadania, oddzielone za pomocą |. Zachowaj wszystkie istniejące nazwy i wzorce. Jeśli na przykład bieżące wyrażenie to hubble_dns_queries_total|hubble_drop_total, dodaj metryki przepływu w następujący sposób:

metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'hubble_dns_queries_total|hubble_drop_total|hubble_flows_processed_total'
    action: keep

Użyj własnego istniejącego wyrażenia jako punktu początkowego. Zaktualizuj istniejącą regułę zachowania zamiast dołączać drugą regułę; druga reguła zachowania może odrzucać metryki zachowane przez pierwszą. Zweryfikuj i załaduj ponownie konfigurację. Wykonaj zapytanie dla każdej dodanej metryki, takiej jak hubble_flows_processed_total, i istniejącej metryki w rozwiązaniu Prometheus. Upewnij się, że oba otrzymują najnowsze próbki podczas przepływu odpowiedniego ruchu, a następnie otwórz pulpity nawigacyjne sieci w kroku 4.

Krok 4. Wyświetlanie pulpitów nawigacyjnych sieciowych usługi ACNS

Azure Portal

Po włączeniu kolekcji Azure Monitor otwórz pulpit nawigacyjny sieci:

1. Otwórz klaster usługi AKS w witrynie Azure Portal.
2. W obszarze Monitorowanie wybierz pozycję Pulpity nawigacyjne za pomocą narzędzia Grafana.
3. Wybierz pulpit z listy, a następnie wybierz przestrzeń nazw lub obciążenie robocze i zakres czasu obejmujący aktywność sieciową.

Aby uzyskać szczegółowe informacje, zobacz Korzystanie z pulpitów nawigacyjnych Grafana w usłudze AKS.

Dostępne pulpity sieciowe

Użyj następujących sześciu paneli Kubernetes / Networking, aby zapoznać się z aktywnością sieciową klastra. Identyfikatory importu są udostępniane tylko dla klientów korzystających z własnej aplikacji Grafana; Nie są one potrzebne dla wbudowanych pulpitów nawigacyjnych portalu Azure.

Zacznij od Clusters na potrzeby kondycji sieci na poziomie węzła, a następnie otwórz pulpit nawigacyjny obciążenia lub przestrzeni nazw, aby zbadać ruch, straty pakietów lub zachowanie DNS. Należy uwzględnić opóźnienie zbierania po włączeniu monitorowania lub zmianie keep listy.

Panele DNS wymagają widoczności DNS. Panele Pod Flows wymagają elementu hubble_flows_processed_total na liście zachowywanych elementów skonfigurowanej w kroku 3. Pusty panel może oznaczać brak pasującego ruchu, brakującą kolekcję lub niepoprawny zakres czasu lub zaznaczenie. Niekoniecznie oznacza to, że występuje problem z siecią.

Opcjonalnie: użyj oddzielnego wdrożenia narzędzia Grafana

Jeśli używasz już Azure Managed Grafana, możesz połączyć go z obszarem roboczym Azure Monitor i użyć pulpitów nawigacyjnych Kubernetes / Networking / ... w obszarze Pulpity > nawigacyjne Azure Managed Prometheus. Azure Managed Grafana jest oddzielną, płatną usługą, a nie wymaganiem wstępnym dla pulpitów nawigacyjnych portalu.

W przypadku własnej aplikacji Grafana zaimportuj pulpity nawigacyjne przy użyciu identyfikatorów w poprzedniej tabeli i wybierz źródło danych Prometheus.

Rozwiązywanie problemów z brakującymi metrykami

Uprzątnij zasoby

Przywróć tylko zmiany wprowadzone przez Ciebie w ramach dochodzenia na listach dozwolonych CNM i Prometheus. Zachowaj ustawienia używane przez inne zespoły i wszelkie zmiany wprowadzone od czasu utworzenia kopii zapasowej. Usunięcie wpisu CNM powoduje wyłączenie opcjonalnej metryki tylko wtedy, gdy ten wpis ją włączył; metryki udostępniane przez usługę pozostają włączone. Usuwanie filtrów może poszerzyć zbiór wyników. Próbki historyczne nadal podlegają retencji po stronie backendu.

Usuń grupę zasobów tylko wtedy, gdy utworzono ją wyłącznie na potrzeby tego ćwiczenia i nikt nie potrzebuje żadnego zasobu w niej. Następujące polecenie usuwa klaster i wszystkie inne zasoby w tej grupie:

az group delete --name "$RESOURCE_GROUP"

Dalsze kroki

• Wybierz metryki i poznaj ich limity.
• Filtrowanie metryk i włączanie dodatkowych metryk w Cilium.
• Skonfiguruj przechowywane lub tworzone na żądanie dzienniki sieciowe.
• Zapoznaj się z usługami Advanced Container Networking Services.