Configurar logs de rede de contêiner

Este guia orienta você pela configuração de logs de rede de contêineres em Advanced Container Networking Services para AKS (Serviço de Kubernetes do Azure). Você pode configurar logs armazenados para coleta contínua com armazenamento persistente ou logs sob demanda para solução de problemas em tempo real.

Para uma visão clara de quais logs de rede de contêiner são capturados e quando usar cada modo, consulte O que são os logs de rede de contêiner?.

Pré-requisitos

• Uma conta Azure com uma assinatura ativa. Se você não tiver uma, crie uma conta gratuita antes de começar.

• Use o ambiente bash em Azure Cloud Shell. Para obter mais informações, consulte Get iniciado com Azure Cloud Shell.

  

• Se você preferir executar comandos de referência da CLI localmente, instalar o CLI do Azure. Se você estiver executando em Windows ou macOS, considere executar CLI do Azure em um contêiner do Docker. Para obter mais informações, consulte Como executar o CLI do Azure em um contêiner do Docker.

  • Se você estiver usando uma instalação local, entre no CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga as etapas exibidas em seu terminal. Para obter outras opções de entrada, consulte Authenticate para Azure usando CLI do Azure.

  • Quando for solicitado, instale a extensão CLI do Azure no primeiro uso. Para obter mais informações sobre extensões, consulte Use e gerencie extensões com o CLI do Azure.

  • Execute o comando az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para atualizar para a versão mais recente, execute az upgrade.

• CLI do Azure versão 2.85.0 ou posterior. Execute az --version para verificar. Para instalar ou atualizar, consulte Instalar CLI do Azure.

• A versão da extensão aks-preview CLI do Azure 20.0.0b4 ou posterior:

  # 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
  

• O modo de logs armazenados requer o plano de dados Cilium.

• O modo de logs sob demanda funciona com planos de dados Cilium e não Cilium.

• Seu cluster deve estar executando o Kubernetes versão 1.33 ou posterior.

• Os dados de fluxo da camada 7 são capturados somente quando o suporte à política de Camada 7 está habilitado. Para obter mais informações, consulte Configurar uma política de Camada 7.

• Fluxos de DNS e métricas são capturados somente quando uma política de rede Cilium FQDN é aplicada. Para obter mais informações, consulte Configurar uma política FQDN.

Configurar o modo de logs armazenados

O modo de armazenamento de logs permite que o ACNS capture de forma contínua os registros de fluxo de rede em cada nó. Duas coisas são necessárias para que os logs comecem a fluir:

1. O ACNS deve estar habilitado no cluster. Isso provisiona os componentes do agente Cilium que capturam fluxos.
2. Pelo menos um ContainerNetworkLog CRD deve ser aplicado. Isso determina qual tráfego é capturado. Sem um CRD, nenhum log é gerado.

Depois que ambos estiverem em funcionamento, os logs de fluxo serão gravados no /var/log/acns/hubble/events.log em cada nó. Fluxos semelhantes são agrupados automaticamente em registros resumidos por meio da agregação de log de fluxo, o que reduz o volume de dados, preservando os padrões necessários.

Habilitar o complemento Azure Monitor é uma etapa opcional separada que envia esses logs para um workspace Log Analytics. Isso não afeta a geração de logs.

Você pode configurar isso em um novo cluster ou habilitá-lo em um existente.

Como os logs armazenados fluem de ponta a ponta

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

Opções de implantação

Configuração de ponta a ponta

Siga estes passos por ordem. As etapas 1 e 2 são necessárias. A etapa 3 é opcional e só será necessária se você quiser que os logs sejam encaminhados para Azure Monitor.

Defina as variáveis de ambiente uma vez e reutilize-as ao longo de:

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

Etapa 1: Verifique se o ACNS está habilitado no cluster

Use a opção que corresponde à sua situação.

Opção A: criar um novo cluster com 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

Obtenha suas credenciais de cluster para que você possa executar kubectl comandos:

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

Opção B: usar um cluster existente

Se o cluster já tiver o ACNS habilitado, você poderá ir para a Etapa 2. Caso contrário, obtenha suas credenciais para que você possa executar kubectl comandos:

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

Etapa 2: Aplicar um CRD ContainerNetworkLog para iniciar a coleta de logs

O modo de logs armazenados não coleta nada até que você aplique pelo menos um ContainerNetworkLog recurso personalizado. Esse recurso especifica qual tráfego capturar: por namespace, pod, serviço, protocolo ou veredito.

Depois que um CRD é aplicado, os fluxos correspondentes são gravados em /var/log/acns/hubble/events.log de cada nó.

kubectl apply -f <crd.yaml>

Consulte o modelo completo de CRD containerNetworkLog abaixo para todos os campos disponíveis.

Neste ponto, cada nó tem registros de fluxo no /var/log/acns/hubble/events.log formato JSON. Se isso é tudo que você precisa, você está pronto.

Etapa 3 (opcional): encaminhar logs para Azure Monitor para armazenamento persistente

Conclua esta etapa se desejar que os logs sejam encaminhados para um espaço de trabalho Log Analytics para retenção de longo prazo, consultas KQL, o portal do Azure e os painéis do Grafana. Pule-o se você planeja consumir logs locais de host diretamente ou encaminhá-los por meio de seu próprio coletor OpenTelemetry ou serviço de logs.

3a. Habilitar o complemento Azure Monitor (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. Habilite o sinalizador de logs de rede de contêiner:

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

Para enviar logs para um workspace específico do Azure Monitor, adicione o sinalizador --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

Atalho: criar um cluster com Log Analytics desde o início

Se você estiver criando um novo cluster e já souber que deseja que os logs sejam enviados para um workspace Log Analytics, você poderá combinar a Etapa 1 e a Etapa 3 em um único comando de criação:

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

Para enviar logs para um workspace específico, adicione o --azure-monitor-workspace-resource-id sinalizador:

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

Você ainda precisa concluir a Etapa 2 (aplicar um ContainerNetworkLog CRD) para definir qual tráfego capturar. Integração do Log Analytics já está em vigor, portanto, fluxos correspondentes são coletados e enviados para seu workspace automaticamente.

Modelo de CRD ContainerNetworkLog

O ContainerNetworkLog recurso personalizado define quais fluxos de rede capturar. Você pode criar vários recursos personalizados em um único cluster e cada um pode direcionar namespaces, pods ou protocolos diferentes.

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

Basta criar um arquivo YAML com o modelo acima, personalizar os filtros conforme necessário e aplicá-lo com kubectl apply -f <crd.yaml>.

Referência do campo CRD

Capturar fluxos de Camada 7 e DNS

O ContainerNetworkLog CRD captura os fluxos das Camadas 3 e 4 relacionados ao tráfego que você seleciona em includeFilters. Os registros de camada 7 (HTTP, gRPC, Kafka) e DNS aparecem somente quando o tráfego correspondente também é coberto por uma política de rede Cilium que aceita a inspeção L7 ou a visibilidade do DNS. Sem essa política, os campos L7 e DNS permanecem vazios em seus logs de fluxo.

Você precisa das duas partes:

• Suporte a L7 no nível do cluster. O suporte à política L7 deve ser habilitado no cluster. Para obter detalhes, consulte Configurar uma política de Camada 7.
• Uma política de rede Cilium que tem como escopo regras L7 ou DNS. Aplique um CiliumNetworkPolicy com rules.http, rules.kafka, ou rules.dns para as cargas de trabalho cujo tráfego você deseja inspecionar. Para saída com reconhecimento de DNS, combine rules.dns com toFQDNs. Para obter mais informações, consulte Configurar uma política FQDN.

O exemplo a seguir permite a inspeção de DNS para consultas kube-dns e inspeção HTTP L7 para envio de tráfego para *.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"

Aplique-o:

kubectl apply -f l7-dns-policy.yaml

Depois que a política é aplicada, os fluxos correspondentes em ContainerNetworkLogs preenchem o campo Layer7, e as pesquisas de DNS aparecem com dns.rcode e metadados relacionados.

Verificar a configuração

Essas etapas se aplicam a configurações de cluster novas e existentes.

Obter credenciais do cluster

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

Confirme se os logs de rede de contêiner estão habilitados

az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

Identifique as seguintes seções na saída:

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

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

Verificar o status do recurso personalizado

Listar todos os ContainerNetworkLog recursos no cluster:

kubectl get containernetworklog

Ele fornecerá o nome do recurso containernetworklog que você acabou de criar. Use esse nome no comando abaixo para verificar seu status:

Verifique o status de um recurso específico:

kubectl describe containernetworklog <cr-name>

O Status>State campo deve mostrar CONFIGURED. Se for exibido FAILED, verifique se a especificação de filtro é válida.

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

Você pode aplicar vários recursos personalizados ContainerNetworkLog . Cada um tem seu próprio status.

Logs de consulta no Log Analytics

Quando o Log Analytics estiver configurado, você poderá consultar logs de fluxo histórico usando a tabela ContainerNetworkLogs em seu Log Analytics workspace. Use a KQL (Linguagem de Consulta kusto) para analisar padrões de rede, identificar incidentes de segurança, solucionar problemas de conectividade e executar a análise de causa raiz.

Para consultas de exemplo, consulte o diagnóstico progressivo usando registros de fluxo na documentação do AKS Labs.

Visualizar com painéis do Grafana

Você pode acessar painéis do Grafana predefinidos por meio do portal do Azure. Antes de começar, verifique se os pods de log Azure Monitor estão em execução:

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

Resultado esperado:

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

Conceder acesso ao Grafana aos dados de monitoramento

O espaço de trabalho do Grafana Managed precisa da função Monitoring Reader na assinatura que contém seu Log Analytics workspace.

Se você for um Proprietário da assinatura ou Administrador de Acesso de Usuário, o workspace do Grafana Gerenciado obterá essa função automaticamente quando é criado.

Caso contrário (ou se os workspaces Log Analytics e Grafana estiverem em assinaturas diferentes), conceda a função manualmente:

1. No workspace do Grafana Gerenciado, vá para Configurações>Identidade.

   

2. Selecione atribuições de função do Azure>Adicionar atribuições de função.

   

3. Defina Escopo como Assinatura, selecione sua assinatura, defina Função como Leitor de Monitoramento e selecione Salvar.

   

4. Verifique a fonte de dados na guia Fonte de dados da instância do Grafana Gerenciado:

   

Acessar os painéis

Para abrir os dashboards do portal Azure:

1. Vá para o seu cluster AKS no portal do Azure.
2. Selecione Painéis com Grafana (Versão prévia).
3. Navegue pelos painéis disponíveis em Azure Monitor ou Azure Managed Prometheus.

Verifique os painéis no Azure Monitor>Insights>Containers>Networking. Há duas opções dependendo da camada que você escolheu para sua tabela ContainerNetworkLogs em Log Analytics:

Ambos os painéis mostram quais cargas de trabalho do AKS se comunicam entre si, incluindo solicitações, respostas, quedas e erros. Use aquele que corresponde ao nível configurado para a tabela ContainerNetworkLogs sua.

Para obter mais informações sobre os componentes do painel, consulte a visão geral dos logs de rede do contêiner.

Configurar o modo de logs sob demanda

Os logs sob demanda permitem capturar dados de fluxo em tempo real sem armazenamento persistente. Este modo funciona tanto com planos de dados Cilium quanto com não Cilium.

Seu cluster precisa de Serviços Avançados de Rede de Contêiner habilitados. Se você ainda não tiver um cluster habilitado para ACNS, crie um:

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

Habilitar o ACNS em um cluster existente

Para habilitar o ACNS em um cluster que você já tem:

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

Obtenha suas credenciais de cluster:

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

Instalar a CLI do 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}

Usar a CLI do Hubble

1. Confirme se o pod de Retransmissão do Hubble está em execução:

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

   Resultado esperado:

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

2. Realize o redirecionamento de porta para a Retransmissão do Hubble:

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

3. Configurar certificados mTLS para o cliente 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. Verifique se os segredos existem:

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

   Resultado esperado:

   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. Observe os fluxos de um pod específico:

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

Configurar a interface do usuário do Hubble

1. Salve o seguinte manifesto como 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. Aplique o manifesto:

   kubectl apply -f hubble-ui.yaml
   

3. Configurar o encaminhamento de porta:

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

4. Abra http://localhost:12000/ no navegador para acessar a interface do usuário do Hubble.

Troubleshooting

• ACNS não habilitado. A execução --enable-container-network-logs sem ACNS produz:

  Logs de fluxo exigem '--enable-acns', rede avançada deve estar habilitada.

• Versão do Kubernetes muito antiga. A execução --enable-container-network-logs em um cluster com mais de 1.33.0 produz:

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

• CRD não reconhecido. Aplicar um ContainerNetworkLog em um cluster sem ACNS produz:

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

  Verifique se o ACNS está habilitado no cluster.

Desabilitar o modo de logs armazenados

Os logs armazenados têm duas camadas: geração de log no nó e encaminhamento opcional para o Azure Monitor. Você pode desativar qualquer camada de forma independente.

Parar de gerar logs

A geração de log é orientada por ContainerNetworkLog recursos personalizados. Excluir todos eles impede que novos registros de fluxo sejam gravados para /var/log/acns/hubble/events.log em cada nó.

kubectl delete containernetworklog --all

Para remover um recurso específico em vez de todos eles, execute kubectl delete containernetworklog <cr-name>.

Parar de encaminhar logs para Azure Monitor

Se você quiser apenas parar de enviar logs para o seu workspace do Log Analytics mas mantê-los gerados no nó, desabilite a integração com o Azure Monitor:

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

Os recursos existentes ContainerNetworkLog permanecem em vigor, portanto, os fluxos continuam a chegar em cada nó /var/log/acns/hubble/events.log até que você remova esses recursos.

Limpar os recursos

Se você não precisar mais dos recursos, exclua o grupo de recursos:

az group delete --name $RESOURCE_GROUP

Limitações

Plano de dados e versão do Kubernetes

• O modo de logs armazenados requer o plano de dados do Cilium e o Kubernetes 1.33 ou posterior.
• Os logs sob demanda (CLI do Hubble e interface do usuário do Hubble) funcionam com planos de dados Cilium e não-Cilium.

Visibilidade da camada 7 e DNS

• Os registros de fluxo de camada 7 são preenchidos somente quando o suporte à política L7 está habilitado no cluster e uma CiliumNetworkPolicy com regras L7 abrange o tráfego. Para obter detalhes, consulte Configurar uma política de Camada 7.
• Os registros DNS são preenchidos somente quando uma política Cilium FQDN (rules.dns mais toFQDNs) cobre o tráfego. As políticas baseadas em FQDN são incompatíveis com o DNS local do nó, incluindo o DNS local do AKS. Para obter detalhes, consulte Configurar uma política FQDN.

Armazenamento local do host

• Sem Azure Monitor ou um coletor externo, os logs de fluxo são armazenados em cada nó em /var/log/acns/hubble/events.log e limitados a 50 MB. Quando o limite é atingido, as entradas mais antigas são substituídas.
• Os logs de fluxo são gravados em nós de hospedagem e coletados pelo agente do Azure Monitor. Se você habilitar a integração com Log Analytics depois de aplicar ContainerNetworkLog CRD, somente novos logs desse ponto em diante serão ingeridos. Os logs históricos do host não são coletados.

Log Analytics

• Alternar a área de trabalho do Log Analytics após habilitar os logs da rede de contêiner pode fazer com que os logs parem de fluir para a nova área de trabalho. Isso acontece porque a configuração de coleta de dados Azure Monitor existente não é atualizada automaticamente. Para evitar esse problema, configure o espaço de trabalho desejado ao habilitar inicialmente os Logs de Rede de Contêiner, ou atualize manualmente a regra de coleta de dados associada ao alterar os espaços de trabalho. Consulte Configuração da coleta de dados em Insights de Contêiner.
• A ContainerNetworkLogs tabela dá suporte às camadas Analytics (padrão) e Basic . Não há suporte para a camada Auxiliar .

Compensações de agregação

• A agregação de log de fluxo não preserva carimbos de data/hora individuais dos fluxos, endereços IP específicos por pod ou campos de alta cardinalidade, como URLs HTTP e nomes de consulta DNS. Use logs sob demanda para investigação por fluxo.

Conteúdo relacionado

• O que são logs de rede de contêineres?
• Serviços avançados de rede de contêiner para AKS
• Observabilidade de rede de contêiner em serviços avançados de rede de contêiner