Configurare i log di rete dei contenitori

Questa guida illustra come configurare i log di rete dei contenitori in Servizi di rete contenitore avanzata per Servizio Azure Kubernetes (AKS). È possibile configurare i log archiviati per la raccolta continua con l'archiviazione permanente o i log su richiesta per la risoluzione dei problemi in tempo reale.

Per una panoramica dell'acquisizione dei log di rete dei contenitori e dell'uso di ogni modalità, vedere Che cosa sono i log di rete dei contenitori?.

Prerequisiti

• Un account Azure con una sottoscrizione attiva. Se non ne hai uno, crea un account gratuito prima di iniziare.

• Usare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Introduzione a Azure Cloud Shell.

  

• Se si preferisce, per eseguire localmente i comandi di riferimento CLI, installare l'interfaccia della riga di comando di Azure per eseguire i relativi comandi di riferimento. Se si esegue in Windows o macOS, è consigliabile eseguire interfaccia della riga di comando di Azure in un contenitore Docker. Per altre informazioni, vedere Come eseguire il interfaccia della riga di comando di Azure in un contenitore Docker.

  • Se si usa un'installazione locale, accedere al interfaccia della riga di comando di Azure usando il comando az login. Per completare il processo di autenticazione, seguire i passaggi visualizzati nel terminale. Per altre opzioni di accesso, vedere Authenticate to Azure using interfaccia della riga di comando di Azure.For other sign-in options, see Authenticate to Azure using interfaccia della riga di comando di Azure.

  • Quando richiesto, installare l'estensione interfaccia della riga di comando di Azure al primo uso. Per altre informazioni sulle estensioni, vedere Usare e gestire le estensioni con interfaccia della riga di comando di Azure.

  • Esegui az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento alla versione più recente, avviare az upgrade.

• Interfaccia a riga di comando di Azure v. 2.85.0 o successiva. Eseguire az --version per verificare. Per installare o aggiornare, vedere Installare interfaccia della riga di comando di Azure.

• L'estensione dell'interfaccia della riga di comando di Azure aks-preview versione 20.0.0b4 o successiva:

  # 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
  

• La modalità di registrazione dei log richiede il piano dati Cilium.

• La modalità log su richiesta funziona sia con i piani dati Cilium che con quelli non Cilium.

• Il cluster deve eseguire Kubernetes versione 1.33 o successiva.

• I dati del flusso di livello 7 vengono acquisiti solo quando è abilitato il supporto dei criteri di livello 7. Per altre informazioni, vedere Configurare un criterio di livello 7.

• I flussi DNS e le metriche vengono acquisiti solo quando viene applicato un criterio di rete FQDN Cilium. Per altre informazioni, vedere Configurare un criterio FQDN.

Configurare la modalità dei log archiviati

La modalità log archiviati consente a ACNS di acquisire continuamente i log dei flussi di rete in ogni nodo. Per avviare il flusso dei log sono necessari due elementi:

1. AcNS deve essere abilitato nel cluster. Esegue il provisioning dei componenti dell'agente Cilium che acquisisce i flussi.
2. È necessario applicare almeno un ContainerNetworkLog CRD. Definisce quale traffico viene acquisito. Senza un CRD, non vengono generati log.

Quando entrambi sono presenti, i file di log dei flussi vengono scritti su /var/log/acns/hubble/events.log in ogni nodo. I flussi simili vengono raggruppati automaticamente in record riepilogati tramite l'aggregazione dei log di flusso, riducendo al tempo stesso i modelli necessari.

L'abilitazione del componente aggiuntivo Monitoraggio di Azure è un passaggio facoltativo separato che include tali log in un'area di lavoro Log Analytics. Non influisce sulla generazione dei log.

È possibile configurarlo in un nuovo cluster o abilitarlo in un cluster esistente.

Come i log archiviati fluiscono end-to-end

                    ┌─────────────────────────────────────────────┐
                    │                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

Opzioni di distribuzione

Nuovo cluster

Passaggio 1: Creare un cluster con ACNS abilitato

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

# 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

# Optional: add --node-vm-size Standard_D4ads_v5 if the default VM size is not available in your subscription

Ottenere le credenziali del cluster in modo da poter eseguire kubectl i comandi:

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

Passaggio 2: Definire cosa registrare con una risorsa personalizzata ContainerNetworkLog

La modalità log archiviati non raccoglie alcun elemento finché non si definisce almeno una ContainerNetworkLog risorsa personalizzata. Questa risorsa specifica il traffico da acquisire: per spazio dei nomi, pod, servizio, protocollo o verdetto.

Quando viene applicata una risorsa personalizzata, i flussi corrispondenti vengono scritti su /var/log/acns/hubble/events.log in ogni nodo host.

Consultare il modello CRD ContainerNetworkLog completo per tutti i campi disponibili, o applicare direttamente uno:

kubectl apply -f <crd.yaml>

I log nei nodi host sono temporanei. I file ruotano automaticamente a 50 MB e le voci più vecchie vengono sovrascritte. Per l'archiviazione permanente, configurare Monitoraggio di Azure (passaggio successivo). È anche possibile integrare un servizio di registrazione partner come un agente di raccolta OpenTelemetry.

Leggere o inoltrare i log senza Monitoraggio di Azure

L'integrazione di Monitoraggio di Azure è facoltativa. Dopo il passaggio 2, ogni nodo ha record di flusso in /var/log/acns/hubble/events.log formato JSON. È possibile leggere questi file direttamente nel nodo o inoltrarli a un back-end SIEM o osservabilità usando qualsiasi agente di raccolta o registrazione compatibile con OpenTelemetry.

Questo percorso può essere usato invece di Monitoraggio di Azure o insieme a esso.

Passaggio 3 (facoltativo): inoltrare i log a Monitoraggio di Azure per l'archiviazione permanente

Dopo i passaggi 1 e 2, ACNS sta già generando log di flusso in ogni nodo. Questo passaggio è necessario solo se si vogliono inoltrare i log a uno spazio di lavoro di Log Analytics per la conservazione a lungo termine, le query KQL, e i dashboard predefiniti del portale Azure e Grafana. Ignorare questo passaggio se si prevede di usare direttamente i log locali dell'host o di inoltrarli tramite il proprio agente di raccolta OpenTelemetry o il proprio servizio di registrazione.

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

Per inviare i log a un'area di lavoro specifica, aggiungere il --azure-monitor-workspace-resource-id flag :

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

Alternativa: creare un cluster con Log Analytics dall'inizio

Se si vogliono inviare i log a un'area di lavoro Log Analytics dall'inizio, includere --enable-container-network-logs nel comando create:

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-container-network-logs \
  --acns-advanced-networkpolicies L7

Per inviare i log a un'area di lavoro specifica, aggiungere il --azure-monitor-workspace-resource-id flag :

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-container-network-logs \
  --azure-monitor-workspace-resource-id $AZURE_MONITOR_ID \
  --acns-advanced-networkpolicies L7

Con questo approccio, è comunque necessario applicare un ContainerNetworkLog CRD (passaggio 2) per definire il traffico da acquisire. L'integrazione di Log Analytics è pronta, quindi i flussi corrispondenti vengono collezionati e inviati automaticamente allo spazio di lavoro.

Cluster esistente

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

Passaggio 1: Abilitare i log di rete dei contenitori

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

Per inviare i log a un'area di lavoro Log Analytics specifica, aggiungere il flag --azure-monitor-workspace-resource-id:

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

Passaggio 2: Applicare un CRD ContainerNetworkLog per avviare la raccolta dei log

Vedere il modello CRD per la specifica completa.

kubectl apply -f <crd.yaml>

Modello CRD ContainerNetworkLog

La ContainerNetworkLog risorsa personalizzata definisce i flussi di rete da acquisire. È possibile creare più risorse personalizzate in un singolo cluster e ognuna può avere come destinazione spazi dei nomi, pod o protocolli diversi.

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/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/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

Informazioni di riferimento sul campo CRD

Acquisire i flussi di livello 7 e DNS

Il ContainerNetworkLog CRD acquisisce i flussi di livello 3 e 4 per il traffico selezionato in includeFilters. Il livello 7 (HTTP, gRPC, Kafka) e i record DNS vengono visualizzati solo quando il traffico corrispondente è coperto anche da un criterio di rete Cilium che opta per l'ispezione L7 o la visibilità DNS. Senza tale criterio, i campi L7 e DNS rimangono vuoti nei log dei flussi.

Sono necessari entrambi i componenti:

• Supporto L7 a livello di cluster. Il supporto dei criteri L7 deve essere abilitato nel cluster. Per informazioni dettagliate, vedere Configurare un criterio di livello 7.
• Un criterio di rete Cilium che definisce l'ambito di applicazione delle regole L7 o DNS. Applicare un CiliumNetworkPolicy con rules.http, rules.kafka, o rules.dns per i carichi di lavoro per il quale si desidera esaminare il traffico. Per l'uscita compatibile con DNS, combinare rules.dns con toFQDNs. Per altre informazioni, vedere Configurare un criterio FQDN.

L'esempio seguente abilita l'ispezione DNS per le ricerche kube-dns e l'ispezione HTTP L7 per l'uscita a *.example.com:

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"

Applicarlo:

kubectl apply -f l7-dns-policy.yaml

Dopo l'applicazione dei criteri, i flussi di corrispondenza in ContainerNetworkLogs vengono popolati nel campo Layer7 e le ricerche DNS vengono visualizzate con dns.rcode e i metadati correlati.

Verificare l'installazione

Questi passaggi si applicano sia alle configurazioni di cluster nuove che esistenti.

Ottenere le credenziali del cluster

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

Verificare che i log di rete dei contenitori siano abilitati

az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

Cerca queste sezioni nel risultato:

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

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

Controllare lo stato della risorsa personalizzata

Elencare tutte le ContainerNetworkLog risorse nel cluster:

kubectl get containernetworklog

Verrà assegnato il nome della risorsa containernetworklog appena creata. Usare tale nome nel comando seguente per verificarne lo stato:

Controllare lo stato di una risorsa specifica:

kubectl describe containernetworklog <cr-name>

Il Status>State campo deve visualizzare CONFIGURED. Se viene visualizzato FAILED, verificare che la specifica di filtro sia valida.

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

È possibile applicare più ContainerNetworkLog risorse personalizzate. Ognuno ha il proprio stato.

Log delle query in Analisi dei log:

Quando Log Analytics è configurato, è possibile eseguire query sui log dei flussi cronologici usando la tabella ContainerNetworkLogs nell'area di lavoro Log Analytics. Usare Il linguaggio di query Kusto (KQL) per analizzare i modelli di rete, identificare gli eventi imprevisti di sicurezza, risolvere i problemi di connettività ed eseguire l'analisi della causa radice.

Per le query di esempio, vedere Diagnosi progressiva usando i log di flusso nella documentazione di AKS Labs.

Visualizzare con le dashboard di Grafana

È possibile accedere ai dashboard predefiniti di Grafana tramite il portale di Azure. Prima di iniziare, assicurarsi che siano in esecuzione i pod log di Monitoraggio di Azure.

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

Output previsto:

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

Concedere a Grafana l'accesso ai dati di monitoraggio

L'area di lavoro Grafana gestita necessita del ruolo Monitoring Reader nella sottoscrizione che contiene l'area di lavoro Log Analytics.

Se sei un titolare dell'abbonamento o un amministratore dell'accesso utenti, l'area di lavoro Grafana gestita ottiene automaticamente questo ruolo quando viene creato.

Se non fosse così, o se le aree di lavoro Log Analytics e Grafana si trovano in sottoscrizioni diverse, concedere il ruolo manualmente:

1. Nell'area di lavoro Grafana gestita passare a Impostazioni>Identità.

   

2. Seleziona assegnazioni di ruoli di Azure>Aggiungi assegnazioni di ruoli.

   

3. Impostare Ambito su Sottoscrizione, selezionare la sottoscrizione, impostare Ruolo su Lettore di monitoraggio e selezionare Salva.

   

4. Verificare l'origine dati nella scheda Origine dati dell'istanza di Grafana gestita:

   

Accedere ai dashboard

Per aprire i dashboard dal portale di Azure:

1. Nel portale di Azure andare al cluster AKS.
2. Selezionare Dashboard con Grafana (anteprima).
3. Sfoglia i dashboard disponibili in Monitoraggio di Azure o in Azure Managed Prometheus.

Cerca le dashboard in Monitoraggio di Azure>Insights>Containers>Networking. Esistono due opzioni a seconda del livello scelto per la tabella ContainerNetworkLogs in Log Analytics:

Entrambi i dashboard mostrano quali carichi di lavoro di AKS (Azure Kubernetes Service) comunicano tra loro, inclusi richieste, risposte, interruzioni ed errori. Usare quello che corrisponde al livello configurato per la ContainerNetworkLogs tabella.

Per altre informazioni sui componenti del dashboard, vedere la panoramica dei log di rete dei contenitori.

Configurare la modalità di log a richiesta

I log su richiesta consentono di acquisire i dati del flusso in tempo reale senza l'archiviazione permanente. Questa modalità funziona sia con i piani dati Cilium che con i piani dati non Cilium.

Il cluster richiede l'abilitazione di Advanced Container Networking Services . Se non si dispone ancora di un cluster abilitato per ACNS, crearne uno:

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

Abilitare ACNS in un cluster esistente

Per abilitare ACNS in un cluster già disponibile:

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

Ottenere le credenziali del cluster:

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

Installare la CLI di Hubble

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}

Usare la CLI di Hubble

1. Verificare che il pod Hubble Relay sia in esecuzione.

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

   Output previsto:

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

2. Inoltrare la porta dell'Hubble Relay

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

3. Configurare i certificati mTLS per il client Hubble:

   #!/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. Verificare che i segreti esistano:

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

   Output previsto:

   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. Osservare i flussi da un pod specifico:

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

Configurare l'interfaccia utente di Hubble

1. Salvare il manifesto seguente come 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. Applicare il manifesto:

   kubectl apply -f hubble-ui.yaml
   

3. Configurare il port forwarding:

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

4. Aprire http://localhost:12000/ nel browser per accedere all'interfaccia utente di Hubble.

Troubleshooting

• ACNS non abilitato. L'esecuzione di --enable-container-network-logs senza l'ACNS produce:

  I log di flusso richiedono l'abilitazione della rete avanzata --enable-acns.

• Versione di Kubernetes troppo vecchia. L'esecuzione --enable-container-network-logs in un cluster precedente alla 1.33.0 produce:

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

• CRD non riconosciuto. L'applicazione di ContainerNetworkLog in un cluster senza ACNS produce:

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

  Assicurarsi che ACNS sia abilitato nel cluster.

Disabilitare la modalità log archiviati

I log archiviati hanno due livelli, ovvero la generazione dei log nel nodo e l'inoltro facoltativo a Monitoraggio di Azure. È possibile disattivare entrambi i livelli in modo indipendente.

Interrompere la generazione di log

La generazione dei log è basata su ContainerNetworkLog risorse personalizzate. L'eliminazione di tutti loro impedisce la scrittura di nuovi record di flusso su /var/log/acns/hubble/events.log in ogni nodo.

kubectl delete containernetworklog --all

Per rimuovere una risorsa specifica anziché tutte, eseguire kubectl delete containernetworklog <cr-name>.

Arrestare l'inoltro dei log a Monitoraggio di Azure

Se si vogliono interrompere solo l'invio di log all'area di lavoro Log Analytics ma continuare a generarli nel nodo, disabilitare l'integrazione Monitoraggio di Azure:

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

Le risorse esistenti ContainerNetworkLog rimangono effettive, quindi i flussi continuano a raggiungere ogni nodo su /var/log/acns/hubble/events.log finché non si rimuovono tali risorse.

Pulire le risorse

Se le risorse non sono più necessarie, eliminare il gruppo di risorse:

az group delete --name $RESOURCE_GROUP

Limitazioni

Piano dati e versione di Kubernetes

• La modalità log memorizzati richiede il piano dati Cilium e Kubernetes 1.33 o versione successiva.
• I log su richiesta (Hubble CLI e Hubble UI) funzionano con piani dati sia Cilium che non Cilium.

Livello 7 e visibilità DNS

• I record di flusso di livello 7 vengono popolati solo quando il supporto dei criteri L7 è abilitato nel cluster e un CiliumNetworkPolicy oggetto con regole L7 copre il traffico. Per informazioni dettagliate, vedere Configurare un criterio di livello 7.
• I record DNS vengono popolati solo quando un criterio FQDN Cilium (rules.dns più toFQDNs) copre il traffico. I criteri basati su FQDN non sono compatibili con il DNS locale del nodo, incluso AKS Local DNS. Per informazioni dettagliate, vedere Configurare un criterio FQDN.

Archiviazione locale dell'host

• Senza Monitoraggio di Azure o un agente di raccolta esterno, i log dei flussi vengono archiviati in ogni nodo in /var/log/acns/hubble/events.log e sono limitati a 50 MB. Quando viene raggiunto il limite, le voci precedenti vengono sovrascritte.
• I log dei flussi vengono scritti nei nodi host e raccolti dall'agente Monitoraggio di Azure. Se si abilita l'integrazione di Log Analytics dopo l'applicazione di un CRD ContainerNetworkLog, vengono inseriti solo i nuovi log da quel punto in avanti. I log cronologici nell'host non vengono raccolti.

Log Analytics

• Il passaggio dell'area di lavoro Log Analytics dopo l'abilitazione dei log di rete dei contenitori può causare l'arresto del flusso dei log nella nuova area di lavoro. Ciò si verifica perché la configurazione della raccolta dati Monitoraggio di Azure esistente non viene aggiornata automaticamente. Per evitare questo problema, configurare l'area di lavoro desiderata quando si abilitano prima i log di rete contenitori o aggiornare manualmente la regola di raccolta dati associata quando si modificano le aree di lavoro. Vedere Configurare la raccolta dati in Informazioni dettagliate sui contenitori.
• La ContainerNetworkLogs tabella supporta i livelli Analytics (impostazione predefinita) e Basic . Il livello ausiliario non è supportato.

Compromessi nelle aggregazioni

• L'aggregazione dei log di flusso non conserva i singoli timestamp del flusso, gli indirizzi IP per pod o i campi ad alta cardinalità come URL HTTP e nomi di query DNS. Usare i log su richiesta per l'analisi per flusso.

Contenuti correlati

• Che cosa sono i log di rete dei contenitori?
• Servizi di rete avanzati per AKS
• Osservabilità della rete dei container in servizi di rete avanzati dei container