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?.

Importante

I log di rete dei contenitori vengono generati da ACNS stesso, quindi la generazione dei log non ha una dipendenza rigida da Monitoraggio di Azure. Dopo l'abilitazione di ACNS e l'applicazione di un CRD ContainerNetworkLog, i log dei flussi vengono scritti in ogni nodo in /var/log/acns/hubble/events.log.

Per un'esperienza di osservabilità completa e di livello di produzione, è consigliabile abilitare il componente aggiuntivo Monitoraggio di Azure. Raccoglie i log locali dell'host in un'area di lavoro di Log Analytics e consente la conservazione a lungo termine, l'uso di KQL, i dashboard integrati del portale di Azure e i dashboard di Grafana gestiti.

Se non si abilita Monitoraggio di Azure, è comunque possibile utilizzare i log locali dell'host direttamente o inoltrarli a qualsiasi agente di raccolta o registrazione compatibile con OpenTelemetry.

Prerequisiti

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

  • 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

Seguire la configurazione end-to-end seguente. Gli stessi tre passaggi funzionano sia per i cluster nuovi che per i cluster esistenti.

Configurazione end-to-end

Seguire questi passaggi nell'ordine indicato. Sono necessari i passaggi 1 e 2. Il passaggio 3 è facoltativo e necessario solo se si desidera che i log vengano inoltrati a Monitoraggio di Azure.

Step Cosa fai Obbligatorio?
1 Assicurarsi che il cluster disponga di ACNS abilitato (nuovo o esistente) Yes
2 Applicare un ContainerNetworkLog CRD per avviare la raccolta di log Yes
3 Inoltrare i log a Monitoraggio di Azure per l'archiviazione permanente Opzionale

Impostare le variabili di ambiente una sola volta e riutilizzarle in tutto:

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

Passaggio 1: Assicurarsi che ACNS sia abilitato nel cluster

Usare l'opzione corrispondente alla situazione.

Opzione A: Creare un nuovo cluster con 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

Suggerimento

Se le dimensioni predefinite della macchina virtuale non sono disponibili nella sottoscrizione, aggiungere --node-vm-size Standard_D4ads_v5.

Se si è già certi di voler inoltrare i log a Monitoraggio di Azure, è possibile eseguire tutte le operazioni in un unico comando. Vedere Shortcut: Creare un cluster con Log Analytics dall'inizio.

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

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

Opzione B: Usare un cluster esistente

Se il cluster dispone già di ACNS abilitato, è possibile passare al passaggio 2. In caso contrario, ottieni le credenziali in modo da poter eseguire kubectl i comandi:

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

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

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

Dopo l'applicazione di un CRD, i flussi corrispondenti vengono scritti verso /var/log/acns/hubble/events.log su ogni nodo.

kubectl apply -f <crd.yaml>

Per tutti i campi disponibili, vedere il modello CRD ContainerNetworkLog completo riportato di seguito.

Suggerimento

Per un esempio pratico, vedere l'esempio CRD nella documentazione di AKS Labs.

Annotazioni

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, completare il passaggio 3. È anche possibile inoltrare i log a un back-end SIEM o di osservabilità usando qualsiasi agente di raccolta o servizio di registrazione compatibile con OpenTelemetry, anziché o insieme a Monitoraggio di Azure.

A questo punto, ogni nodo ha record di flusso in /var/log/acns/hubble/events.log formato JSON. Se è tutto quello che serve, hai finito.

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

Completare questo passaggio se si desidera che i log vengano inoltrati a un'area di lavoro Log Analytics per la conservazione a lungo termine, le query KQL e per il portale di Azure e i dashboard predefiniti di Grafana. Ignorare se si prevede di usare i log locali dell'host direttamente o di inoltrarli tramite il proprio agente di raccolta OpenTelemetry o il servizio di registrazione.

3a. Abilitare il componente aggiuntivo Monitoraggio di Azure (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. Abilitare il flag dei log di rete del contenitore:

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

Per inviare i log a un'area di lavoro Monitoraggio di Azure 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

Annotazioni

I log dei flussi vengono scritti nell'host quando viene applicato il CRD ContainerNetworkLog. Se si abilita l'integrazione Log Analytics in un secondo momento, l'agente Monitoraggio di Azure inizia a raccogliere da quel punto in avanti. I log più vecchi di due minuti non vengono inseriti.

Scelta rapida: creare un cluster con Log Analytics fin dall'inizio

Se si sta creando un nuovo cluster e si sa già che si desidera inviare i log a un'area di lavoro Log Analytics, è possibile combinare i passaggi 1 e 3 in un unico comando di creazione.

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

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

È comunque necessario completare il passaggio 2 (applicare un ContainerNetworkLog CRD) per definire il traffico da acquisire. L'integrazione di Log Analytics è già attiva, quindi i flussi abbinati vengono raccolti e inviati automaticamente al tuo spazio di lavoro.

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

È sufficiente creare un file YAML con il modello precedente, personalizzare i filtri in base alle esigenze e applicarlo con kubectl apply -f <crd.yaml>.

Informazioni di riferimento sul campo CRD

Campo TIPO Descrizione Obbligatorio
includefilters []filtro Filtri che definiscono i flussi di rete da acquisire. Deve contenere almeno un filtro. Yes
filters.name string Nome del filtro. No
filters.protocol []string Protocolli da associare: tcp, udp, dns. Se omesso, vengono inclusi tutti i protocolli. No
filters.verdict []string Verdetto del flusso in base alla corrispondenza: forwarded, dropped. Se omesso, vengono inclusi tutti i verdetti. No
filters.from Punto finale Origine del flusso di rete. Può includere indirizzi IP, selettori di etichette e coppie spazio dei nomi/pod. No
filters.to Punto finale Destinazione del flusso di rete. Stesse opzioni di from. No
Endpoint.ip []string Singolo indirizzo IP o intervallo CIDR. No
Endpoint.labelSelector Oggetto Selettore di etichette Kubernetes standard con matchLabels e matchExpressions. Le condizioni vengono combinate con AND. Se vuoto, corrisponde a tutte le risorse. No
Endpoint.namespacedPod []string Coppie spazio dei nomi/pod nel formato namespace/pod. No

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à.

    Screenshot dell'opzione di identità in un'istanza di Managed Grafana.

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

    Screenshot della selezione delle assegnazioni di ruolo di Azure in un'istanza di Grafana.

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

    Screenshot dell'inserimento dei dettagli della sottoscrizione in un'istanza di Managed Grafana.

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

    Screenshot del controllo dell'origine dati in un'istanza di Managed Grafana.

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:

Pannello di controllo Percorso Livello di tabella ID Grafana
Log di flusso - Livello Base Azure>Insights>Containers>Networking>Log di Flusso - Livello Base Basic 23155
Log dei flussi - Livello di analisi Azure>Insights>Containers>Networking>Flow Logs - Analytics Tier Analisi (impostazione predefinita) 23156

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.

Screenshot dei dashboard di Grafana in Monitoraggio di Azure.

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

Suggerimento

Per impostazione predefinita, la ContainerNetworkLogs tabella usa il livello Analytics. Per ridurre i costi di inserimento e conservazione, è possibile passare al livello Basic e usare il dashboard corrispondente. Per altre informazioni, vedere piani delle tabelle di Log Analytics.

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

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

Annotazioni

Le funzionalità di sicurezza di rete dei contenitori richiedono il piano dati Cilium.

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.

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

  • Last updated on