Einrichtung von Netzwerkprotokollen für Container

Dieses Handbuch führt Sie durch das Konfigurieren von Containernetzwerkprotokollen in Advanced Container Networking Services für Azure Kubernetes Service (AKS). Sie können gespeicherte Protokolle für die kontinuierliche Sammlung mit persistentem Speicher oder On-Demand-Protokolle für die Problembehandlung in Echtzeit einrichten.

Eine Übersicht darüber, welche Containernetzwerkprotokolle erfasst werden und wann jeder Modus verwendet werden soll, finden Sie unter Was sind Containernetzwerkprotokolle?.

Voraussetzungen

• Ein Azure Konto mit einem aktiven Abonnement. Falls Sie kein Abonnement besitzen, können Sie ein kostenloses Konto erstellen, bevor Sie beginnen.

• Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Get started with Azure Cloud Shell.

  

• Wenn Sie CLI-Referenzbefehle lieber lokal ausführen möchten, install die Azure CLI. Wenn Sie Windows oder macOS verwenden, sollten Sie Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter How to run the Azure CLI in a Docker container.

  • Wenn Sie eine lokale Installation verwenden, melden Sie sich mit dem Befehl az login beim Azure CLI an. Um den Authentifizierungsprozess abzuschließen, führen Sie die schritte aus, die in Ihrem Terminal angezeigt werden. Weitere Anmeldeoptionen finden Sie unter Authentifizieren bei Azure mit Azure CLI.

  • Wenn Sie dazu aufgefordert werden, installieren Sie die Azure CLI Erweiterung bei der ersten Verwendung. Weitere Informationen zu Erweiterungen finden Sie unter Use and manage extensions with the Azure CLI.

  • Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um auf die neueste Version zu aktualisieren.

• Azure CLI, Version 2.85.0 oder höher. Führen Sie az --version zum Prüfen aus. Informationen zum Installieren oder Aktualisieren finden Sie unter Install Azure CLI.

• Die aks-preview-Azure CLI-Erweiterung Version 20.0.0b4 oder höher:

  # Install the aks-preview extension
  az extension add --name aks-preview
  # Update the extension to make sure you have the latest version installed
  az extension update --name aks-preview
  

• Der Modus für gespeicherte Protokolle erfordert die Cilium-Datenebene.

• Der Modus „On-Demand-Protokolle” funktioniert sowohl mit Cilium- als auch mit Nicht-Cilium-Datenebenen.

• Ihr Cluster muss Kubernetes, Version 1.33 oder höher, ausführen.

• Daten des Layer 7-Flusses werden nur erfasst, wenn die Unterstützung von Layer 7-Richtlinien aktiviert ist. Weitere Informationen finden Sie unter Konfigurieren einer Layer 7-Richtlinie.

• DNS-Flüsse und -Metriken werden nur erfasst, wenn eine Cilium-FQDN-Netzwerkrichtlinie angewendet wird. Weitere Informationen finden Sie unter Konfigurieren einer FQDN-Richtlinie.

Konfigurieren des Modus für gespeicherte Protokolle

Im Modus "Gespeicherte Protokolle" kann ACNS kontinuierlich Netzwerkflussprotokolle auf jedem Knoten erfassen. Zwei Dinge sind erforderlich, damit Logs zu fließen beginnen:

1. ACNS muss im Cluster aktiviert sein. Dies stellt die Cilium-Agentkomponenten bereit, die Flüsse erfassen.
2. Es muss mindestens eine ContainerNetworkLog CRD verwendet werden. Dadurch wird definiert, welcher Datenverkehr erfasst wird. Ohne CRD werden keine Protokolle generiert.

Sobald beide vorhanden sind, werden Flussprotokolle auf jedem Knoten auf /var/log/acns/hubble/events.log geschrieben. Ähnliche Flüsse werden automatisch in zusammengefasste Datensätze über die Flussprotokollaggregation gruppiert, wodurch das Datenvolumen reduziert wird, während die benötigten Muster beibehalten werden.

Das Aktivieren des Azure Monitor-Add-Ons ist ein separater, optionaler Schritt, der diese Protokolle in einen Log Analytics-Arbeitsbereich überträgt. Dies wirkt sich nicht auf die Protokollgenerierung aus.

Sie können dies für einen neuen Cluster einrichten oder auf einem vorhandenen Cluster aktivieren.

So verläuft der Ablauf gespeicherter Protokolle von Anfang bis Ende

                    ┌─────────────────────────────────────────────┐
                    │                AKS node                     │
                    │                                             │
   Pod traffic ───▶ │  Cilium agent (ACNS)                        │
                    │       │                                     │
                    │       ▼                                     │
                    │  ContainerNetworkLog CRD ── filters flows   │
                    │       │                                     │
                    │       ▼                                     │
                    │  /var/log/acns/hubble/events.log            │
                    │  (50 MB rotating, host-local)               │
                    └───────┬─────────────────────────────────────┘
                            │
              ┌─────────────┴──────────────┐
              ▼                            ▼
   Azure Monitor add-on        OpenTelemetry collector
   (optional)                  or logging service (optional)
              │                            │
              ▼                            ▼
   ContainerNetworkLogs        Your SIEM / observability
   table in Log Analytics      backend
              │
              ▼
   Azure portal / Grafana
   dashboards, KQL

Bereitstellungsoptionen

End-to-End-Einrichtung

Führen Sie diese Schritte in der angegebenen Reihenfolge aus. Die Schritte 1 und 2 sind erforderlich. Schritt 3 ist optional und nur erforderlich, wenn Protokolle an Azure Monitor weitergeleitet werden sollen.

Legen Sie die Umgebungsvariablen einmal fest, und verwenden Sie sie überall.

# Replace placeholders with your own values
export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"
export LOCATION="<location>"

Schritt 1: Sicherstellen, dass ACNS auf Ihrem Cluster aktiviert ist

Verwenden Sie die Option, die Ihrer Situation entspricht.

Option A: Erstellen eines neuen Clusters mit ACNS

# Create the resource group if it doesn't already exist
az group create --name $RESOURCE_GROUP --location $LOCATION

# Create an AKS cluster with ACNS
az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --pod-cidr 192.168.0.0/16 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --generate-ssh-keys \
  --enable-acns \
  --acns-advanced-networkpolicies L7

Rufen Sie Ihre Clusteranmeldeinformationen ab, damit Sie kubectl Befehle ausführen können:

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

Option B: Verwenden eines vorhandenen Clusters

Wenn ihr Cluster bereits ACNS aktiviert hat, können Sie mit Schritt 2 fortfahren. Andernfalls Ihre Anmeldeinformationen abrufen, damit Sie kubectl-Befehle ausführen können.

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

Schritt 2: Anwenden einer ContainerNetworkLog CRD zum Starten der Protokollsammlung

Der Modus "Gespeicherte Protokolle" erfasst nichts, bis Sie mindestens eine ContainerNetworkLog benutzerdefinierte Ressource anwenden. Diese Ressource spezifiziert, welcher Datenverkehr erfasst werden soll: nach Namespace, Pod, Dienst, Protokoll oder Urteil.

Sobald eine CRD angewendet wird, werden übereinstimmende Datenströme auf jedem Knoten in /var/log/acns/hubble/events.log geschrieben.

kubectl apply -f <crd.yaml>

Die vollständige Vorlage "ContainerNetworkLog CRD " finden Sie unten für alle verfügbaren Felder.

An diesem Punkt verfügt jeder Knoten über Datenflussaufzeichnungen /var/log/acns/hubble/events.log im JSON-Format. Wenn Das alles ist, was Sie benötigen, sind Sie fertig.

Schritt 3 (optional): Weiterleiten von Protokollen an Azure Monitor für beständigen Speicher

Führen Sie diesen Schritt aus, wenn Protokolle an einen Log Analytics Arbeitsbereich für langfristige Aufbewahrung, KQL-Abfragen und die integrierten Azure Portal- und Grafana-Dashboards weitergeleitet werden sollen. Überspringen Sie es, wenn Sie beabsichtigen, hostlokale Protokolle direkt zu nutzen oder sie über Ihren eigenen OpenTelemetry-Sammel- oder Protokollierungsdienst weiterzuleiten.

3a. Aktivieren sie das Azure Monitor-Add-On (Log Analytics):

# To use the default Log Analytics workspace
az aks enable-addons -a monitoring -g $RESOURCE_GROUP -n $CLUSTER_NAME

# To use an existing Log Analytics workspace
az aks enable-addons -a monitoring -g $RESOURCE_GROUP -n $CLUSTER_NAME --workspace-resource-id <workspace-resource-id>

3b. Das Flag für Container-Netzwerkprotokolle aktivieren.

az aks update --enable-acns \
  --enable-container-network-logs \
  -g $RESOURCE_GROUP \
  -n $CLUSTER_NAME

Um Protokolle an einen bestimmten Azure Monitor Arbeitsbereich zu senden, fügen Sie das Flag --azure-monitor-workspace-resource-id hinzu:

az aks update --enable-acns \
  --enable-container-network-logs \
  --azure-monitor-workspace-resource-id $AZURE_MONITOR_ID \
  -g $RESOURCE_GROUP \
  -n $CLUSTER_NAME

Tastenkombination: Erstellen Sie von Anfang an einen Cluster mit Log Analytics

Wenn Sie einen neuen Cluster erstellen und bereits wissen, dass Protokolle an einen Log Analytics Arbeitsbereich gesendet werden sollen, können Sie Schritt 1 und Schritt 3 in einem einzigen Erstellungsbefehl kombinieren:

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --pod-cidr 192.168.0.0/16 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --generate-ssh-keys \
  --enable-acns \
  --enable-addons monitoring \
  --enable-container-network-logs \
  --acns-advanced-networkpolicies L7

Um Protokolle an einen bestimmten Arbeitsbereich zu senden, fügen Sie das --azure-monitor-workspace-resource-id Kennzeichen hinzu:

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --pod-cidr 192.168.0.0/16 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --generate-ssh-keys \
  --enable-acns \
  --enable-addons monitoring \
  --enable-container-network-logs \
  --azure-monitor-workspace-resource-id $AZURE_MONITOR_ID \
  --acns-advanced-networkpolicies L7

Es muss noch Schritt 2 abgeschlossen werden (ein ContainerNetworkLog-CRD anwenden), um zu definieren, welcher Datenverkehr erfasst werden soll. Log Analytics-Integration ist bereits vorhanden, sodass übereinstimmende Flüsse automatisch gesammelt und an Ihren Arbeitsbereich gesendet werden.

ContainerNetworkLog CRD-Vorlage

Die ContainerNetworkLog benutzerdefinierte Ressource definiert, welche Netzwerkflüsse erfasst werden sollen. Sie können mehrere benutzerdefinierte Ressourcen in einem einzelnen Cluster erstellen, und jede kann auf unterschiedliche Namespaces, Pods oder Protokolle abzielen.

apiVersion: acn.azure.com/v1alpha1
kind: ContainerNetworkLog
metadata:
  name: sample-containernetworklog # Cluster scoped
spec:
  includefilters: # At least one filter is required
    - name: sample-filter
      from:
        namespacedPod: # Format: namespace/pod
          - sample-namespace/sample-pod
        labelSelector:
          matchLabels:
            app: frontend
            k8s:io.kubernetes.pod.namespace: sample-namespace
          matchExpressions:
            - key: environment
              operator: In
              values:
                - production
                - staging
        ip: # Single IP or CIDR
          - "192.168.1.10"
          - "10.0.0.1"
      to:
        namespacedPod:
          - sample-namespace2/sample-pod2
        labelSelector:
          matchLabels:
            app: backend
            k8s:io.kubernetes.pod.namespace: sample-namespace2
          matchExpressions:
            - key: tier
              operator: NotIn
              values:
                - dev
        ip:
          - "192.168.1.20"
          - "10.0.1.1"
      protocol: # tcp, udp, dns
        - tcp
        - udp
        - dns
      verdict: # forwarded, dropped
        - forwarded
        - dropped

Erstellen Sie einfach eine YAML-Datei mit der obigen Vorlage, passen Sie die Filter nach Bedarf an, und wenden Sie sie mit kubectl apply -f <crd.yaml>.

CRD-Feldreferenz

Erfassen von Layer 7- und DNS-Flüssen

Die ContainerNetworkLog-CRD erfasst Layer 3- und Layer 4-Flüsse für den Datenverkehr, der in includeFilters ausgewählt wurde. Layer 7 (HTTP, gRPC, Kafka) und DNS-Einträge werden nur angezeigt, wenn der übereinstimmende Datenverkehr auch von einer Cilium-Netzwerkrichtlinie abgedeckt wird, die sich für die L7-Inspektion oder DNS-Sichtbarkeit entscheidet. Ohne diese Richtlinie bleiben L7- und DNS-Felder in Ihren Ablaufprotokollen leer.

Sie benötigen beide Teile:

• Unterstützung von L7 auf Clusterebene. Die L7-Richtlinienunterstützung muss im Cluster aktiviert sein. Ausführliche Informationen finden Sie unter Konfigurieren einer Layer 7-Richtlinie.
• Eine Cilium-Netzwerkrichtlinie, die L7- oder DNS-Regeln eingrenzt. Ein CiliumNetworkPolicy mit rules.http, rules.kafka oder rules.dns für die Workloads anwenden, deren Datenverkehr überprüft werden soll. Für Egress mit DNS-Berücksichtigung rules.dns mit toFQDNs kombinieren. Weitere Informationen finden Sie unter Konfigurieren einer FQDN-Richtlinie.

Im folgenden Beispiel wird die DNS-Inspektion für Lookups des Typs kube-dns und die L7 HTTP-Inspektion für den Egress zu *.example.com aktiviert.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-dns-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: myapp
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchPattern: "*.example.com"
    - toFQDNs:
        - matchPattern: "*.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/1"

Anwenden:

kubectl apply -f l7-dns-policy.yaml

Nachdem die Richtlinie angewendet wurde, werden übereinstimmende Datenströme im ContainerNetworkLogsLayer7-Feld ausgefüllt, und DNS-Nachschlagevorgänge werden mit dns.rcode und verwandten Metadaten angezeigt.

Überprüfen des Setups

Diese Schritte gelten sowohl für neue als auch für vorhandene Clustersetups.

Abrufen von Clusteranmeldeinformationen

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

Vergewissern Sie sich, dass Containernetzwerkprotokolle aktiviert sind

az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

Suchen Sie in der Ausgabe nach diesen Abschnitten:

"networkProfile": {
  "advancedNetworking": {
    "enabled": true,
    "observability": {
      "enabled": true
    }
  }
}

"osmagent": {
  "config": {
    "enableContainerNetworkLogs": "True"
  }
}

Überprüfen des benutzerdefinierten Ressourcenstatus

Alle ContainerNetworkLog-Ressourcen im Cluster auflisten:

kubectl get containernetworklog

Sie erhalten den Namen der soeben erstellten containernetworklog-Ressource. Verwenden Sie diesen Namen im folgenden Befehl, um den Status zu überprüfen:

Überprüfen Sie den Status einer bestimmten Ressource:

kubectl describe containernetworklog <cr-name>

Das Status>State-Feld sollte CONFIGURED anzeigen. Wenn dies angezeigt wird FAILED, überprüfen Sie, ob die Filterspezifikation gültig ist.

Spec:
  Includefilters:
    From:
      Namespaced Pod:
        namespace/pod-
    Name:  sample-filter
    Protocol:
      tcp
    To:
      Namespaced Pod:
        namespace/pod-
    Verdict:
      dropped
Status:
  State:      CONFIGURED
  Timestamp:  2025-05-01T11:24:48Z

Sie können mehrere ContainerNetworkLog benutzerdefinierte Ressourcen anwenden. Jeder hat einen eigenen Status.

Abfrageprotokolle in Log Analytics

Wenn Log Analytics konfiguriert ist, können Sie Verlaufsflussprotokolle mithilfe der tabelle ContainerNetworkLogs in Ihrem Log Analytics Arbeitsbereich abfragen. Verwenden Sie Kusto Query Language (KQL), um Netzwerkmuster zu analysieren, Sicherheitsvorfälle zu identifizieren, Konnektivität zu beheben und Ursachenanalysen durchzuführen.

Beispielabfragen finden Sie in der AKS Labs-Dokumentation unter "Progressive Diagnose" mithilfe von Ablaufprotokollen .

Visualisieren mit Grafana-Dashboards

Sie können über das Azure-Portal auf vordefinierte Grafana-Dashboards zugreifen. Vor Begin sicherstellen, dass die Azure Monitor Log-Pods ausgeführt werden:

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

Erwartete Ausgabe:

ama-logs-9bxc6                                   3/3     Running   1 (39m ago)   44m
ama-logs-fd568                                   3/3     Running   1 (40m ago)   44m
ama-logs-rs-65bdd98f75-hqnd2                     2/2     Running   1 (43m ago)   22h

Gewähren Sie Grafana Zugriff auf Überwachungsdaten

Ihr verwalteter Grafana-Arbeitsbereich benötigt die Rolle Monitoring Reader für das Abonnement, das Ihren Log Analytics Arbeitsbereich enthält.

Wenn Sie Abonnementbesitzer oder Benutzerzugriffsadministrator sind, erhält der Verwaltete Grafana-Arbeitsbereich diese Rolle automatisch, wenn sie erstellt wird.

Wenn dies nicht der Fall ist oder sich Ihre Log Analytics- und Grafana-Arbeitsbereiche in unterschiedlichen Abonnements befinden, erteilen Sie die Rolle manuell:

1. Wechseln Sie in Ihrem verwalteten Grafana-Arbeitsbereich zu Einstellungen>Identität.

   

2. Wählen Sie Azure Rollenzuweisungen>Rollenzuweisungen hinzufügen aus.

   

3. Legen Sie Bereich auf Abonnement fest, wählen Sie Ihr Abonnement aus, legen Sie Rolle auf Überwachungsleser fest, und wählen Sie Speichern aus.

   

4. Überprüfen Sie die Datenquelle auf der Registerkarte " Datenquelle " ihrer verwalteten Grafana-Instanz:

   

Zugreifen auf die Dashboards

So öffnen Sie die Dashboards aus dem Azure-Portal:

1. Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.
2. Wählen Sie Dashboards mit Grafana (Vorschau) aus.
3. Durchsuchen Sie die verfügbaren Dashboards unter Azure Monitor oder Azure Managed Prometheus.

Suchen Sie nach den Dashboards unter Azure Monitor>Insights>Containers>Networking. Es gibt zwei Optionen, je nachdem, welche Ebene Sie für Ihre ContainerNetworkLogs Tabelle in Log Analytics ausgewählt haben:

Beide Dashboards zeigen an, welche AKS-Workloads miteinander kommunizieren, einschließlich Anforderungen, Antworten, Abbrüchen und Fehlern. Verwenden Sie die Ebene, die der für Ihre ContainerNetworkLogs Tabelle konfigurierten Ebene entspricht.

Weitere Informationen zu den Dashboardkomponenten finden Sie in der Übersicht über Containernetzwerkprotokolle.

Konfigurieren des bedarfsgesteuerten Protokollmodus

Mithilfe von On-Demand-Protokollen können Sie Flussdaten in Echtzeit ohne beständigen Speicher erfassen. Dieser Modus funktioniert sowohl mit Cilium- als auch mit Nicht-Cilium-Datenebenen.

Ihr Cluster benötigt die Aktivierung von Erweiterten Containernetzwerkdiensten. Wenn Sie noch keinen ACNS-fähigen Cluster haben, erstellen Sie einen:

export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"

az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --generate-ssh-keys \
    --location eastus \
    --max-pods 250 \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --node-count 2 \
    --pod-cidr 192.168.0.0/16 \
    --kubernetes-version 1.33 \
    --enable-acns

export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"

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

Aktivieren von ACNS auf einem vorhandenen Cluster

So aktivieren Sie ACNS auf einem Cluster, über den Sie bereits verfügen:

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

Abrufen Ihrer Cluster-Anmeldeinformationen:

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

Installieren Sie die Hubble CLI

export HUBBLE_VERSION=v1.16.3
export HUBBLE_ARCH=amd64

if [ "$(uname -m)" = "aarch64" ]; then HUBBLE_ARCH=arm64; fi
curl -L --fail --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}
sha256sum --check hubble-linux-${HUBBLE_ARCH}.tar.gz.sha256sum
sudo tar xzvfC hubble-linux-${HUBBLE_ARCH}.tar.gz /usr/local/bin
rm hubble-linux-${HUBBLE_ARCH}.tar.gz{,.sha256sum}

Verwenden Sie die Hubble-CLI

1. Stellen Sie sicher, dass der Hubble-Relay-Pod läuft:

   kubectl get pods -o wide -n kube-system -l k8s-app=hubble-relay
   

   Erwartete Ausgabe:

   hubble-relay-7ddd887cdb-h6khj     1/1  Running     0       23h
   

2. Port-Weiterleitung des Hubble-Relays:

   kubectl port-forward -n kube-system svc/hubble-relay --address 127.0.0.1 4245:443
   

3. Konfigurieren von mTLS-Zertifikaten für den Hubble-Client:

   #!/usr/bin/env bash
   set -euo pipefail
   set -x
   
   CERT_DIR="$(pwd)/.certs"
   mkdir -p "$CERT_DIR"
   
   declare -A CERT_FILES=(
     ["tls.crt"]="tls-client-cert-file"
     ["tls.key"]="tls-client-key-file"
     ["ca.crt"]="tls-ca-cert-files"
   )
   
   for FILE in "${!CERT_FILES[@]}"; do
     KEY="${CERT_FILES[$FILE]}"
     JSONPATH="{.data['${FILE//./\\.}']}"
   
     kubectl get secret hubble-relay-client-certs -n kube-system \
       -o jsonpath="${JSONPATH}" | \
       base64 -d > "$CERT_DIR/$FILE"
   
     hubble config set "$KEY" "$CERT_DIR/$FILE"
   done
   
   hubble config set tls true
   hubble config set tls-server-name instance.hubble-relay.cilium.io
   

4. Überprüfen Sie, ob die geheimen Schlüssel vorhanden sind:

   kubectl get secrets -n kube-system | grep hubble-
   

   Erwartete Ausgabe:

   kube-system     hubble-relay-client-certs     kubernetes.io/tls     3     9d
   kube-system     hubble-relay-server-certs     kubernetes.io/tls     3     9d
   kube-system     hubble-server-certs           kubernetes.io/tls     3     9d
   

5. Beobachte Flüsse aus einem bestimmten Pod:

   hubble observe --pod hubble-relay-7ddd887cdb-h6khj
   

Einrichten der Hubble-Benutzeroberfläche

1. Speichern Sie das folgende Manifest unter hubble-ui.yaml:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: hubble-ui
     namespace: kube-system
   ---
   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: hubble-ui
     labels:
       app.kubernetes.io/part-of: retina
   rules:
     - apiGroups:
         - networking.k8s.io
       resources:
         - networkpolicies
       verbs:
         - get
         - list
         - watch
     - apiGroups:
         - ""
       resources:
         - componentstatuses
         - endpoints
         - namespaces
         - nodes
         - pods
         - services
       verbs:
         - get
         - list
         - watch
     - apiGroups:
         - apiextensions.k8s.io
       resources:
         - customresourcedefinitions
       verbs:
         - get
         - list
         - watch
     - apiGroups:
         - cilium.io
       resources:
         - "*"
       verbs:
         - get
         - list
         - watch
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: hubble-ui
     labels:
       app.kubernetes.io/part-of: retina
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: hubble-ui
   subjects:
     - kind: ServiceAccount
       name: hubble-ui
       namespace: kube-system
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: hubble-ui-nginx
     namespace: kube-system
   data:
     nginx.conf: |
       server {
           listen       8081;
           server_name  localhost;
           root /app;
           index index.html;
           client_max_body_size 1G;
           location / {
               proxy_set_header Host $host;
               proxy_set_header X-Real-IP $remote_addr;
               # CORS
               add_header Access-Control-Allow-Methods "GET, POST, PUT, HEAD, DELETE, OPTIONS";
               add_header Access-Control-Allow-Origin *;
               add_header Access-Control-Max-Age 1728000;
               add_header Access-Control-Expose-Headers content-length,grpc-status,grpc-message;
               add_header Access-Control-Allow-Headers range,keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout;
               if ($request_method = OPTIONS) {
                   return 204;
               }
               # /CORS
               location /api {
                   proxy_http_version 1.1;
                   proxy_pass_request_headers on;
                   proxy_hide_header Access-Control-Allow-Origin;
                   proxy_pass http://127.0.0.1:8090;
               }
               location / {
                   try_files $uri $uri/ /index.html /index.html;
               }
               # Liveness probe
               location /healthz {
                   access_log off;
                   add_header Content-Type text/plain;
                   return 200 'ok';
               }
           }
       }
   ---
   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: hubble-ui
     namespace: kube-system
     labels:
       k8s-app: hubble-ui
       app.kubernetes.io/name: hubble-ui
       app.kubernetes.io/part-of: retina
   spec:
     replicas: 1
     selector:
       matchLabels:
         k8s-app: hubble-ui
     template:
       metadata:
         labels:
           k8s-app: hubble-ui
           app.kubernetes.io/name: hubble-ui
           app.kubernetes.io/part-of: retina
       spec:
         serviceAccountName: hubble-ui
         automountServiceAccountToken: true
         containers:
         - name: frontend
           image: mcr.microsoft.com/oss/cilium/hubble-ui:v0.12.2
           imagePullPolicy: Always
           ports:
           - name: http
             containerPort: 8081
           livenessProbe:
             httpGet:
               path: /healthz
               port: 8081
           readinessProbe:
             httpGet:
               path: /
               port: 8081
           resources: {}
           volumeMounts:
           - name: hubble-ui-nginx-conf
             mountPath: /etc/nginx/conf.d/default.conf
             subPath: nginx.conf
           - name: tmp-dir
             mountPath: /tmp
           terminationMessagePolicy: FallbackToLogsOnError
           securityContext: {}
         - name: backend
           image: mcr.microsoft.com/oss/cilium/hubble-ui-backend:v0.12.2
           imagePullPolicy: Always
           env:
           - name: EVENTS_SERVER_PORT
             value: "8090"
           - name: FLOWS_API_ADDR
             value: "hubble-relay:443"
           - name: TLS_TO_RELAY_ENABLED
             value: "true"
           - name: TLS_RELAY_SERVER_NAME
             value: ui.hubble-relay.cilium.io
           - name: TLS_RELAY_CA_CERT_FILES
             value: /var/lib/hubble-ui/certs/hubble-relay-ca.crt
           - name: TLS_RELAY_CLIENT_CERT_FILE
             value: /var/lib/hubble-ui/certs/client.crt
           - name: TLS_RELAY_CLIENT_KEY_FILE
             value: /var/lib/hubble-ui/certs/client.key
           livenessProbe:
             httpGet:
               path: /healthz
               port: 8090
           readinessProbe:
             httpGet:
               path: /healthz
               port: 8090
           ports:
           - name: grpc
             containerPort: 8090
           resources: {}
           volumeMounts:
           - name: hubble-ui-client-certs
             mountPath: /var/lib/hubble-ui/certs
             readOnly: true
           terminationMessagePolicy: FallbackToLogsOnError
           securityContext: {}
         nodeSelector:
           kubernetes.io/os: linux
         volumes:
         - configMap:
             defaultMode: 420
             name: hubble-ui-nginx
           name: hubble-ui-nginx-conf
         - emptyDir: {}
           name: tmp-dir
         - name: hubble-ui-client-certs
           projected:
             defaultMode: 0400
             sources:
             - secret:
                 name: hubble-relay-client-certs
                 items:
                   - key: tls.crt
                     path: client.crt
                   - key: tls.key
                     path: client.key
                   - key: ca.crt
                     path: hubble-relay-ca.crt
   ---
   kind: Service
   apiVersion: v1
   metadata:
     name: hubble-ui
     namespace: kube-system
     labels:
       k8s-app: hubble-ui
       app.kubernetes.io/name: hubble-ui
       app.kubernetes.io/part-of: retina
   spec:
     type: ClusterIP
     selector:
       k8s-app: hubble-ui
     ports:
       - name: http
         port: 80
         targetPort: 8081
   

2. Anwenden des Manifests:

   kubectl apply -f hubble-ui.yaml
   

3. Portweiterleitung einrichten:

   kubectl -n kube-system port-forward svc/hubble-ui 12000:80
   

4. Öffnen Sie http://localhost:12000/ in Ihrem Browser, um auf die Hubble-Benutzeroberfläche zuzugreifen.

Troubleshooting

• ACNS nicht aktiviert. Wird --enable-container-network-logs ohne ACNS ausgeführt, wird Folgendes erzeugt:

  'Ablaufprotokolle erfordern' --enable-acns', erweiterte Netzwerke müssen aktiviert sind

• Kubernetes-Version zu alt. Die Ausführung von --enable-container-network-logs auf einem Cluster, der älter als Version 1.33.0 ist, führt zu:

  The specified orchestrator version %s is not valid. Advanced Networking Flow Logs is only supported on Kubernetes version 1.33.0 or later.

• CRD wurde nicht erkannt. Das Anwenden eines ContainerNetworkLog auf einem Cluster ohne ACNS erzeugt Folgendes:

  error: resource mapping not found for <....>": no matches for kind "ContainerNetworkLog" in version "acn.azure.com/v1alpha1"

  Stellen Sie sicher, dass ACNS im Cluster aktiviert ist.

Modus für gespeicherte Protokolle deaktivieren

Gespeicherte Protokolle verfügen über zwei Ebenen : Protokollgenerierung auf dem Knoten und optionale Weiterleitung an Azure Monitor. Sie können beide Ebenen unabhängig deaktivieren.

Beenden des Generierens von Protokollen

Die Protokollgenerierung wird durch ContainerNetworkLog benutzerdefinierte Ressourcen gesteuert. Durch Löschen all dieser Datensätze wird verhindert, dass neue Flow-Datensätze auf jedem Knoten auf /var/log/acns/hubble/events.log geschrieben werden .

kubectl delete containernetworklog --all

Um eine bestimmte Ressource anstelle aller Ressourcen zu entfernen, führen Sie den Befehl kubectl delete containernetworklog <cr-name>aus.

Beenden der Weiterleitung von Protokollen an Azure Monitor

Wenn Sie das Senden von Protokollen nur an Ihren Log Analytics Arbeitsbereich beenden möchten, sie aber weiterhin auf dem Knoten generieren möchten, deaktivieren Sie die Azure Monitor Integration:

az aks update -n $CLUSTER_NAME -g $RESOURCE_GROUP --disable-container-network-logs

Vorhandene ContainerNetworkLog-Ressourcen bleiben wirksam, sodass Datenflüsse weiterhin an jedem Knoten bei /var/log/acns/hubble/events.log anlangen, bis diese Ressourcen entfernt werden.

Bereinigen von Ressourcen

Wenn Sie die Ressourcen nicht mehr benötigen, löschen Sie die Ressourcengruppe:

az group delete --name $RESOURCE_GROUP

Einschränkungen

Datenebene und Kubernetes-Version

• Der Protokollspeichermodus erfordert die Cilium-Datenebene und Kubernetes 1.33 oder höher.
• On-Demand-Protokolle (Hubble CLI und Hubble UI) arbeiten sowohl mit Cilium- als auch mit Nicht-Cilium-Datenebenen.

Layer 7 und DNS-Sichtbarkeit

• Layer 7-Flussdatensätze werden nur aufgefüllt, wenn die L7-Richtlinienunterstützung auf dem Cluster aktiviert ist und ein CiliumNetworkPolicy mit L7-Regeln den Datenverkehr abdeckt. Ausführliche Informationen finden Sie unter Konfigurieren einer Layer 7-Richtlinie.
• DNS-Einträge werden nur aufgefüllt, wenn eine Cilium-FQDN-Richtlinie (rules.dns plus toFQDNs) den Datenverkehr abdeckt.

Hostlokaler Speicher

• Ohne Azure Monitor oder einen externen Sammelvorgang werden Flussdatenprotokolle auf jedem Knoten bei /var/log/acns/hubble/events.log gespeichert und auf 50 MB begrenzt. Wenn die Obergrenze erreicht ist, werden ältere Einträge überschrieben.
• Datenflussprotokolle werden in Hostknoten geschrieben und vom Azure Monitor Agent erfasst. Wenn Sie die Log Analytics-Integration nach dem Anwenden eines ContainerNetworkLog CRD aktivieren, werden ab diesem Zeitpunkt nur neue Protokolle erfasst. Verlaufsprotokolle auf dem Host werden nicht erfasst.

Log Analytics

• Das Wechseln des Log Analytics Arbeitsbereichs nach dem Aktivieren von Containernetzwerkprotokollen kann dazu führen, dass Protokolle nicht mehr in den neuen Arbeitsbereich fließen. Dies geschieht, da die vorhandene Konfiguration der Azure Monitor Datensammlung nicht automatisch aktualisiert wird. Um dieses Problem zu verhindern, konfigurieren Sie den gewünschten Arbeitsbereich, wenn Sie zuerst Containernetzwerkprotokolle aktivieren oder die zugeordnete Datensammlungsregel beim Ändern von Arbeitsbereichen manuell aktualisieren. Siehe Konfigurieren der Datensammlung in Containereinblicken.
• Die ContainerNetworkLogs Tabelle unterstützt die Ebenen "Analyse" (Standard) und "Einfach ". Die Hilfsebene wird nicht unterstützt.

Aggregationskompromisse

• Die Flussprotokollaggregation behält keine einzelnen Flusszeitstempel, IP-Adressen pro Pod oder Felder mit hoher Kardinalität wie HTTP-URLs und DNS-Abfragenamen bei. Verwenden Sie protokolle auf Anfrage für die Untersuchung pro Datenfluss.

Verwandte Inhalte

• Was sind Containernetzwerkprotokolle?
• Erweiterte Containernetzwerkdienste für AKS
• Beobachtbarkeit von Containernetzwerken in fortgeschrittenen Container-Netzwerkdiensten