Configurar registos de rede de contentores

Este guia guia-o na configuração dos registos de rede de contentores em Advanced Container Networking Services para Azure Kubernetes Service (AKS). Pode configurar registos armazenados para recolha contínua com armazenamento persistente, ou registos sob demanda para resolução de problemas em tempo real.

Para uma visão geral do que registos de rede de contentores capturam e quando usar cada modo, veja: O que são registos de rede de contentores?.

Pré-requisitos

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

• Usa o ambiente Bash em Azure Cloud Shell. Para mais informações, consulte Comece com Azure Cloud Shell.

  

• Se preferires executar localmente comandos de referência da CLI, instala o CLI do Azure. Se estiveres a correr no Windows ou macOS, considera executar CLI do Azure num contentor Docker. Para mais informações, veja Como executar o CLI do Azure num contentor Docker.

  • Se estiveres a usar uma instalação local, inicia sessão na CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga os passos exibidos no seu terminal. Para outras opções de iniciação de sessão, veja Autenticar para Azure usando CLI do Azure.

  • Quando for solicitado, instale a extensão CLI do Azure na primeira utilização. Para mais informações sobre extensões, veja Usar e gerir extensões com a CLI do Azure.

  • Execute az version para descobrir 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. Executa az --version para verificar. Para instalar ou atualizar, consulte Install 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 registos armazenados requer o plano de dados Cilium.

• O modo de registos a pedido funciona tanto com plataformas de dados Cilium como não-Cilium.

• O teu cluster deve estar a correr Kubernetes versão 1.33 ou posterior.

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

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

Configurar o modo de registos armazenados

O modo de registos armazenados permite ao ACNS capturar continuamente registos de fluxo de rede em cada nó. São necessárias duas coisas para que os registos comecem a ser gerados:

1. O ACNS deve estar ativado no cluster. Isto provisiona os componentes do agente Cilium que capturam os fluxos.
2. Deve ser aplicado pelo menos um ContainerNetworkLog CRD. Este define qual o tráfego que é capturado. Sem um CRD, não são gerados registos.

Assim que ambos estão no lugar, os registos de fluxo são escritos em /var/log/acns/hubble/events.log em cada nó. Fluxos semelhantes são automaticamente agrupados em registos resumidos através da agregação de registos de fluxos, que reduz o volume de dados enquanto preserva os padrões necessários.

Ativar o complemento Azure Monitor é um passo separado e opcional que encaminha esses logs para um espaço de trabalho do Log Analytics. Não afeta a geração de logs.

Podes configurar isto num novo cluster ou ativar num já existente.

Como os registos 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. São necessários os passos 1 e 2. O Passo 3 é opcional e só necessário se quiser que os logs sejam encaminhados para o Azure Monitor.

Define as variáveis do ambiente uma vez e reutiliza-as ao longo do processo:

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

Passo 1: Certifique-se de que o ACNS está ativado no seu cluster

Use a opção que se adapte à sua situação.

Opção A: Criar um novo cluster com o 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 as credenciais do seu cluster para poder executar kubectl comandos:

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

Opção B: Usar um cluster já existente

Se o seu cluster já tiver o ACNS ativado, pode avançar para o Passo 2. Caso contrário, obtenha as suas credenciais para poder executar kubectl comandos:

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

Passo 2: Aplicar um CRD de ContainerNetworkLog para começar a recolha de logs

O modo de registos armazenados não recolhe nada até aplicar pelo menos um ContainerNetworkLog recurso personalizado. Este recurso especifica qual o tráfego a capturar: por namespace, pod, serviço, protocolo ou veredicto.

Uma vez que um CRD é aplicado, os fluxos correspondentes são escritos /var/log/acns/hubble/events.log em cada nó.

kubectl apply -f <crd.yaml>

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

Neste ponto, cada nó possui registos de fluxo em formato JSON em /var/log/acns/hubble/events.log. Se é só isso que precisas, já está.

Passo 3 (opcional): Encaminhar os logs para o Azure Monitor para armazenamento persistente

Complete este passo se quiser que os logs sejam encaminhados para um Espaço de Trabalho do Log Analytics para retenção a longo prazo, consultas KQL e os painéis integrados do portal do Azure e do Grafana. Omita se planeia consumir diretamente os logs locais do sistema anfitrião ou encaminhá-los através do seu próprio coletor OpenTelemetry ou serviço de logs.

3a. Ativar o complemento do 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. Ativar o indicador de registos da rede de contentores.

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

Para enviar registos para um espaço de trabalho Azure Monitor específico, adicione a 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

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

Se estiver a criar um novo cluster e já souber que quer que os logs sejam enviados para um espaço de trabalho do Log Analytics, pode combinar o Step 1 e o Step 3 num único 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-addons monitoring \
  --enable-container-network-logs \
  --acns-advanced-networkpolicies L7

Para enviar registos para um espaço de trabalho específico, adicione a --azure-monitor-workspace-resource-id bandeira:

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

Ainda precisas de completar o Passo 2 (aplicar um ContainerNetworkLog CRD) para definir qual o tráfego a capturar. A integração com Log Analytics já está implementada, por isso os fluxos correspondentes são recolhidos e enviados automaticamente para o seu espaço de trabalho.

Modelo CRD ContainerNetworkLog

O ContainerNetworkLog recurso personalizado define que fluxos de rede capturar. Pode criar múltiplos recursos personalizados num único cluster, e cada um pode direcionar diferentes namespaces, pods ou protocolos.

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 ficheiro YAML com o modelo acima, personalizar os filtros conforme necessário e aplicá-lo com kubectl apply -f <crd.yaml>.

Referência de campo CRD

Camada 7 de captura e fluxos DNS

O ContainerNetworkLog CRD capta os fluxos da Camada 3 e da Camada 4 para o tráfego selecionado por si em includeFilters. Os registos da Camada 7 (HTTP, gRPC, Kafka) e DNS só aparecem quando o tráfego correspondente também é coberto por uma política de rede Cilium que opta por inspeção L7 ou visibilidade DNS. Sem essa política, os campos L7 e DNS ficam vazios nos teus registos de fluxo.

Precisas de ambas as peças:

• Suporte L7 ao nível do cluster. O suporte à política L7 deve estar ativado no cluster. Para mais detalhes, consulte Configurar uma política de Camada 7.
• Uma política de rede Cilium que abrange regras L7 ou DNS. Aplique um CiliumNetworkPolicy com rules.http, rules.kafka, ou rules.dns para as cargas de trabalho cujo tráfego pretende inspecionar. Para saída consciente do DNS, combine rules.dns com toFQDNs. Para obter mais informações, consulte Configurar uma política FQDN.

O exemplo seguinte permite a inspeção DNS para consultas kube-dns e a inspeção HTTP L7 para saída 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"

Aplica-o:

kubectl apply -f l7-dns-policy.yaml

Após a aplicação da política, os fluxos correspondentes ContainerNetworkLogs preenchem o campo Layer7, e as consultas DNS aparecem no campo dns.rcode com metadados relacionados.

Verifica a configuração

Estes passos aplicam-se tanto a configurações de cluster novas como existentes.

Obter credenciais de cluster

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

Confirme que os registos da rede de contentores estão ativados

az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

Procure estas secções na saída:

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

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

Verificar o estado dos recursos personalizados

Liste todos ContainerNetworkLog os recursos do cluster:

kubectl get containernetworklog

Vai dar-te o nome do recurso containernetworklog que acabaste de criar. Use esse nome no comando abaixo para verificar o seu estado:

Verifique o estado de um recurso específico:

kubectl describe containernetworklog <cr-name>

O campo Status>State deve mostrar CONFIGURED. Se FAILED aparecer, verifica se as especificações do filtro são válidas.

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

Podes aplicar vários ContainerNetworkLog recursos personalizados. Cada um tem o seu próprio estatuto.

Consultar registos no Log Analytics

Quando Log Analytics estiver configurado, pode consultar registos históricos de fluxo usando a tabela ContainerNetworkLogs no seu espaço de trabalho Log Analytics. Use a Linguagem de Consulta Kusto (KQL) para analisar padrões de rede, identificar incidentes de segurança, resolver problemas de conectividade e realizar análises de causa raiz.

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

Visualize com painéis de controlo do Grafana

Pode aceder a painéis Grafana pré-construídos através do portal do Azure. Antes de começar, certifique-se de que os pods de log do Azure Monitor estão a funcionar:

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

Resultados esperados:

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

Grant Grafana acesso a dados de monitorização

O seu espaço de trabalho Grafana Gerido precisa do papel Leitor de Monitorização na subscrição que contém o seu espaço de trabalho Log Analytics.

Se for Proprietário de Subscrição ou Administrador de Acesso ao Utilizador, o espaço de trabalho Managed Grafana recebe automaticamente esta função quando é criado.

Se não for (ou se os seus espaços de trabalho Log Analytics e Grafana estiverem em subscrições diferentes), conceda a função manualmente:

1. No espaço de trabalho do Managed Grafana, vá para Configurações>Identidade.

   

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

   

3. Definir Âmbito como Subscrição, selecione a sua subscrição, definir Papel como Leitor de Monitorização e selecione Guardar.

   

4. Verifique a fonte de dados no separador Fonte de dados da sua instância de Grafana Gerido:

   

Aceder aos dashboards

Para abrir os dashboards a partir do portal Azure:

1. Aceda ao cluster do AKS no portal do Azure.
2. Selecione Painéis com Grafana (Pré-visualização).
3. Navegue pelos dashboards disponíveis no Azure Monitor ou Azure Managed Prometheus.

Procure os painéis de controlo em Azure Monitor>Insights>Containers>Networking. Existem duas opções dependendo do nível que escolheste para a tua tabela de ContainerNetworkLogs em Log Analytics:

Ambos os dashboards mostram que cargas de trabalho AKS comunicam entre si, incluindo pedidos, respostas, quedas e erros. Utiliza o que corresponde ao nível configurado para a tua ContainerNetworkLogs tabela.

Para mais informações sobre os componentes do dashboard, consulte a visão geral dos registos da rede de contentores.

Configurar o modo de registos sob demanda

Os registos on-demand permitem capturar dados de fluxo em tempo real sem armazenamento persistente. Este modo funciona tanto com planos de dados Cilium como não-Cilium.

O seu cluster precisa de ter os Serviços Avançados de Rede de Contentores ativados. Se ainda não tem um cluster compatível com 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

Ativar o ACNS num cluster existente

Para ativar o ACNS num cluster que já tem:

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

Obtenha as 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}

Use o CLI do Hubble

1. Confirme que o pod Hubble Relay está a funcionar:

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

   Resultados esperados:

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

2. Encaminhe a porta do Relé Hubble:

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

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

   Resultados esperados:

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

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

Configurar a interface do Hubble

1. Guardar 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 portas:

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

4. Abra http://localhost:12000/ no seu navegador para aceder à interface do Hubble.

Troubleshooting

• ACNS não ativado. Executar --enable-container-network-logs sem ACNS produz:

  Os registos de fluxo requerem --enable-acns e a ativação de rede avançada.

• Versão do Kubernetes demasiado antiga. Executar --enable-container-network-logs num cluster anterior à 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. A aplicação de ContainerNetworkLog em um cluster sem ACNS produz:

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

  Certifica-te de que o ACNS está ativado no cluster.

Desativar o modo de registos armazenados

Os registos armazenados são compostos por duas camadas — geração de registos no nó e, opcionalmente, encaminhamento para o Azure Monitor. Podes desligar qualquer uma das camadas de forma independente.

Parar de gerar registos

A geração de logs é impulsionada por ContainerNetworkLog recursos personalizados. Eliminar todas impede que novos registos de fluxo sejam gravados /var/log/acns/hubble/events.log em cada nó.

kubectl delete containernetworklog --all

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

Pare de encaminhar logs para Azure Monitor

Se só quiser deixar de enviar logs para o seu espaço de trabalho Log Analytics e continuar a gerá-los no nó, desative a integração com Azure Monitor:

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

Os recursos existentes ContainerNetworkLog mantêm-se em vigor, por isso os fluxos continuam a chegar a cada nó /var/log/acns/hubble/events.log até remover esses recursos.

Limpeza de recursos

Se já não precisares dos recursos, elimina o grupo de recursos:

az group delete --name $RESOURCE_GROUP

Limitações

Plano de dados e versão Kubernetes

• O modo de registos armazenados requer o plano de dados Cilium e o Kubernetes 1.33 ou posterior.
• Os logs on-demand (Hubble CLI e Hubble UI) funcionam tanto para planos de dados Cilium como para planos de dados sem Cilium.

Camada 7 e visibilidade DNS

• Os registos de fluxo da Camada 7 são preenchidos apenas quando o suporte à política L7 está ativado no cluster e um CiliumNetworkPolicy com regras L7 cobre o tráfego. Para mais detalhes, consulte Configurar uma política de Camada 7.
• Os registos DNS só são preenchidos quando uma política Cilium FQDN (rules.dns plus 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 mais detalhes, consulte Configurar uma política FQDN.

Armazenamento local do host

• Sem Azure Monitor ou um coletor externo, os registos de fluxo são armazenados em cada nó a /var/log/acns/hubble/events.log e limitados a 50 MB. Quando o limite é atingido, as entradas mais antigas são substituídas.
• Os registos de fluxo são escritos nos nós anfitriões e recolhidos pelo Azure Monitor Agent. Se ativares a integração do Log Analytics depois de aplicares um CRD ContainerNetworkLog, apenas novos registos a partir desse momento serão ingeridos. Os registos históricos do host não são recolhidos.

Análise de logs

• Mudar o espaço de trabalho Log Analytics após ativar os Container Network Logs pode fazer com que os logs deixem de fluir para o novo espaço de trabalho. Isto acontece porque a configuração existente de recolha de dados do Azure Monitor não é atualizada automaticamente. Para evitar este problema, configure o espaço de trabalho desejado ao ativar os Registos de Rede de Contentores pela primeira vez, ou atualize manualmente a regra associada de recolha de dados ao mudar de espaço de trabalho. Veja Configurar a coleta de dados no Container insights.
• A ContainerNetworkLogs tabela suporta os níveis de Análise (padrão) e Básico . O nível Auxiliar não é suportado.

Compensações de agregação

• A agregação de registos de fluxo não preserva carimbos temporais individuais de fluxo, endereços IP de cada pod ou campos com alta cardinalidade, como URLs HTTP e nomes de consultas DNS. Use registos a pedido para investigação por fluxo.

Conteúdo relacionado

• O que são registos de rede de contentores?
• Serviços Avançados de Rede de Contentores para AKS
• Observabilidade de Redes de Contentores em Serviços Avançados de Redes de Contentores