Configurar registros de red de contenedor

Esta guía le guía a través de la configuración de registros de red de contenedor en Servicios de red de contenedor avanzada para Azure Kubernetes Service (AKS). Puede configurar registros almacenados para la recopilación continua con almacenamiento persistente o registros a petición para la solución de problemas en tiempo real.

Para obtener información general sobre qué registros de red de contenedor capturan y cuándo usar cada modo, consulte ¿Qué son los registros de red de contenedor?.

Importante

ACNS genera los registros de red de los contenedores, por lo que la generación de registros no depende fuertemente de Azure Monitor. Una vez que ACNS está habilitado y se aplica una ContainerNetworkLog CRD, los registros de flujo se escriben en cada nodo en /var/log/acns/hubble/events.log.

Para obtener una experiencia completa de observabilidad de nivel de producción, se recomienda habilitar el complemento Azure Monitor. Recopila registros locales de host en un área de trabajo de Log Analytics y desbloquea la retención a largo plazo, KQL, los paneles del portal de Azure integrados y los paneles de Grafana administrados.

Si no habilita Azure Monitor, todavía puede consumir registros locales de host directamente o reenviarlos a cualquier recopilador o servicio de registro compatible con OpenTelemetry.

Prerrequisitos

  • Cli de Azure versión 2.85.0 o posterior. Ejecute az --version para comprobarlo. Para instalar o actualizar, consulte Install CLI de Azure.

  • La versión de la extensión aks-preview CLI de Azure 20.0.0b4 o 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

  • El modo de registros almacenados requiere el plano de datos de Cilium.

  • El modo de registros a petición funciona con planos de datos de Cilium y otros planos de datos.

  • El clúster debe ejecutar kubernetes versión 1.33 o posterior.

  • Los datos de flujo de capa 7 solo se capturan cuando la compatibilidad con directivas de nivel 7 está habilitada. Para obtener más información, consulte Configuración de una directiva de nivel 7.

  • Los flujos DNS y las métricas solo se capturan cuando se aplica una directiva de red FQDN de Cilium. Para obtener más información, consulte Configuración de una directiva de FQDN.

Configurar el modo de registros almacenados

El modo de registros almacenados permite a ACNS capturar continuamente los registros de flujo de red en cada nodo. Se requieren dos cosas para que los registros empiecen a fluir:

  1. ACNS debe estar habilitado en el clúster. Esto aprovisiona los componentes del agente de Cilium que capturan flujos.
  2. Se debe aplicar al menos un ContainerNetworkLog CRD. Esto define qué tráfico se captura. Sin un CRD, no se generan registros.

Una vez colocados ambos, los registros de flujo se escriben en /var/log/acns/hubble/events.log en cada nodo. Los flujos similares se agrupan automáticamente en registros resumidos a través de la agregación del registro de flujo, lo que reduce el volumen de datos al tiempo que conserva los patrones que necesita.

Habilitar el complemento de Azure Monitor es un paso opcional independiente que incluye esos registros en un área de trabajo de Log Analytics. No afecta a la generación de registros.

Puede configurarlo en un nuevo clúster o habilitarlo en uno existente.

Cómo fluyen los registros almacenados de un extremo a otro

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

Opciones de implementación

Siga la configuración de un extremo a otro a continuación. Los mismos tres pasos funcionan para clústeres nuevos y existentes.

Configuración integral

Siga estos pasos en orden. Se requieren los pasos 1 y 2. El paso 3 es opcional y solo es necesario si desea que los registros se reenvíen a Azure Monitor.

Step Qué haces ¿Obligatorio?
1 Asegúrese de que el clúster tiene ACNS habilitado (nuevo o existente) Sí
2 Aplicar un CRD para iniciar la ContainerNetworkLog recopilación de registros Sí
3 Reenviar registros a Azure Monitor para el almacenamiento persistente Opcional

Establezca las variables de entorno una vez y reutilícelas a lo largo de:

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

Paso 1: Asegúrese de que ACNS está habilitado en el clúster

Use la opción que coincida con su situación.

Opción A: Creación de un nuevo clúster 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

Sugerencia

Si el tamaño de máquina virtual predeterminado no está disponible en la suscripción, agregue --node-vm-size Standard_D4ads_v5.

Si ya sabe que desea que los registros se reenvíen a Azure Monitor, puede hacer todo en un solo comando. Consulte Shortcut: Creación de un clúster con Log Analytics desde el inicio.

Obtenga las credenciales del clúster para que pueda ejecutar kubectl comandos:

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

Opción B: Uso de un clúster existente

Si el clúster ya tiene ACNS habilitado, puede ir directamente al paso 2. De lo contrario, obtenga las credenciales para que pueda ejecutar kubectl comandos:

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

Paso 2: Aplicar un CRD ContainerNetworkLog para iniciar la recopilación de registros

El modo de registros almacenados no recopila nada hasta que se aplica al menos un ContainerNetworkLog recurso personalizado. Este recurso especifica el tráfico que se va a capturar: por espacio de nombres, pod, servicio, protocolo o veredicto.

Una vez que se aplica un CRD, los flujos coincidentes se registran en /var/log/acns/hubble/events.log de cada nodo.

kubectl apply -f <crd.yaml>

Consulte la plantilla completa containerNetworkLog CRD siguiente para ver todos los campos disponibles.

Sugerencia

Para obtener un ejemplo práctico, consulte el CRD de ejemplo en la documentación de AKS Labs.

Nota:

Los registros en los nodos host son temporales. Los archivos se rotan automáticamente al alcanzar 50 MB y se sobrescriben los archivos anteriores. Para el almacenamiento persistente, complete el paso 3. También puede reenviar registros a un sistema back-end de SIEM o de observabilidad mediante cualquier recopilador o servicio de registro compatible con OpenTelemetry, tanto en lugar de como junto con Azure Monitor.

En este momento, cada nodo tiene registros de flujo en /var/log/acns/hubble/events.log formato JSON. Si eso es todo lo que necesitas, has terminado.

Paso 3 (opcional): reenvío de registros a Azure Monitor para el almacenamiento persistente

Complete este paso si desea que los registros se reenvíen a un área de trabajo de Log Analytics para la retención a largo plazo, las consultas KQL y los paneles integrados Azure portal y Grafana. Omita esta acción si planea consumir los registros locales del host directamente o reenviarlos a través de su propio recopilador o servicio de registros de OpenTelemetry.

3a. Habilite el 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 el indicador de registros de la red del contenedor:

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

Para enviar registros a un área de trabajo de Azure Monitor específica, agregue la marca --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

Nota:

Los registros de flujo se escriben en el host cuando se aplica el ContainerNetworkLog CRD. Si habilita la integración de Log Analytics más adelante, el agente de Azure Monitor comienza a recopilar desde ese momento hacia adelante. No se ingieren los registros que tengan más de dos minutos de antigüedad.

Acceso directo: Creación de un clúster con Log Analytics desde el inicio

Si va a crear un nuevo clúster y ya sabe que quiere que los registros se envíen a un área de trabajo de Log Analytics, puede combinar el paso 1 y el paso 3 en un ú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 registros a un área de trabajo específica, agregue la --azure-monitor-workspace-resource-id marca :

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

Todavía tiene que completar el Paso 2 (aplicar un ContainerNetworkLog CRD) para definir el tráfico que capturar. Log Analytics integración ya está en vigor, por lo que los flujos coincidentes se recopilan y envían automáticamente al área de trabajo.

Plantilla de CRD de ContainerNetworkLog

El ContainerNetworkLog recurso personalizado define qué flujos de red se van a capturar. Puede crear varios recursos personalizados en un único clúster y cada uno puede tener como destino distintos espacios de nombres, pods o 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

Solo tiene que crear un archivo YAML con la plantilla anterior, personalizar los filtros según sea necesario y aplicarlo con kubectl apply -f <crd.yaml>.

Referencia de campo CRD

Campo Tipo Descripción Obligatorio
includefilters []filtro Filtros que definen qué flujos de red se van a capturar. Debe contener al menos un filtro. Sí
filters.name Cuerda Nombre del filtro. No
filters.protocol []string Protocolos para que coincidan: tcp, udp, dns. Si se omite, se incluyen todos los protocolos. No
filters.verdict []string Resultado de flujo que coincida con: forwarded, dropped. Si se omite, se incluyen todos los veredictos. No
filters.from Punto final Origen del flujo de red. Puede incluir direcciones IP, selectores de etiquetas y pares de espacio de nombres o pod. No
filters.to Punto final Destino del flujo de red. Las mismas opciones que from. No
Endpoint.ip []string Dirección IP única o intervalo CIDR. No
Endpoint.labelSelector Objeto Selector de etiquetas de Kubernetes estándar con matchLabels y matchExpressions. Las condiciones se combinan con AND. Si está vacío, coincide con todos los recursos. No
Endpoint.namespacedPod []string Pares de espacio de nombres/pod en el formato namespace/pod. No

Capturar flujos de nivel 7 y DNS

El ContainerNetworkLog CRD captura los flujos de nivel 3 y 4 para el tráfico que seleccione en includeFilters. La capa 7 (HTTP, gRPC, Kafka) y los registros DNS solo aparecen cuando el tráfico coincidente también está cubierto por una directiva de red de Cilium que opta por la inspección L7 o la visibilidad de DNS. Sin esa directiva, los campos L7 y DNS permanecen vacíos en los registros de flujo.

Necesita ambas piezas:

  • Compatibilidad con L7 de nivel de clúster. La compatibilidad con directivas L7 debe estar habilitada en el clúster. Para obtener más información, consulte Configuración de una directiva de nivel 7.
  • Una directiva de red de Cilium que define el alcance de las reglas L7 o DNS. Aplique un CiliumNetworkPolicy con rules.http, rules.kafka, o rules.dns para las cargas de trabajo cuyo tráfico desea inspeccionar. Para la salida compatible con DNS, combine rules.dns con toFQDNs. Para obtener más información, consulte Configuración de una directiva de FQDN.

En el ejemplo siguiente se habilita la inspección de DNS para las búsquedas kube-dns y la inspección HTTP L7 para la salida 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"

Aplíquelo:

kubectl apply -f l7-dns-policy.yaml

Una vez aplicada la directiva, los flujos coincidentes en ContainerNetworkLogs rellenan el campo Layer7, y las búsquedas DNS aparecen con dns.rcode y metadatos relacionados.

Comprobación de la configuración

Estos pasos se aplican a las configuraciones de clúster nuevas y existentes.

Obtener credenciales del clúster

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

Confirmación de que los registros de red del contenedor están habilitados

az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

Busque estas secciones en la salida:

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

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

Comprobación del estado de los recursos personalizados

Enumere todos los ContainerNetworkLog recursos del clúster:

kubectl get containernetworklog

Le dará el nombre del recurso containernetworklog que acaba de crear. Use ese nombre en el comando siguiente para comprobar su estado:

Compruebe el estado de un recurso específico:

kubectl describe containernetworklog <cr-name>

El Status>State campo debe mostrar CONFIGURED. Si muestra FAILED, compruebe que la especificación de filtro es 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

Puede aplicar varios ContainerNetworkLog recursos personalizados. Cada uno tiene su propio estado.

Consulta de registros en Log Analytics

Cuando se configura Log Analytics, puede consultar registros de flujo históricos mediante la tabla ContainerNetworkLogs del área de trabajo de Log Analytics. Use el lenguaje de consulta Kusto (KQL) para analizar patrones de red, identificar incidentes de seguridad, solucionar problemas de conectividad y realizar análisis de la causa principal.

Para ver consultas de ejemplo, consulte Diagnóstico progresivo mediante registros de flujo en la documentación de AKS Labs.

Visualización con paneles de Grafana

Puede acceder a los paneles de Grafana creados previamente a través del portal de Azure. Antes de empezar, asegúrese de que se ejecutan los pods de registro de Azure Monitor:

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 a Grafana acceso a los datos de supervisión

El área de trabajo de Grafana administrada necesita el rol Monitoring Reader en la suscripción que contiene el área de trabajo de Log Analytics.

Si eres propietario de la suscripción o administrador de acceso de usuarios, la zona de trabajo gestionada de Grafana obtiene este rol automáticamente al ser creada.

Si no es así (o si las áreas de trabajo de Log Analytics y Grafana están en distintas suscripciones), conceda el rol manualmente:

  1. En el área de trabajo de Grafana administrada, vaya a Configuración>Identidad.

    Captura de pantalla de la opción de identidad en una instancia de Grafana administrada.

  2. Seleccione asignaciones de roles de Azure>Añadir asignaciones de roles.

    Captura de pantalla de elegir asignaciones de roles de Azure en una instancia de Grafana.

  3. Establezca Ámbito en Suscripción, seleccione la suscripción, establezca Rol en Lector de supervisión y seleccione Guardar.

    Captura de pantalla de la especificación de los detalles de la suscripción en una instancia de Grafana administrada.

  4. Compruebe el origen de datos en la pestaña Origen de datos de la instancia de Grafana administrada:

    Captura de pantalla de la comprobación del origen de datos en una instancia de Grafana administrada.

Acceso a los paneles

Para abrir los paneles desde el portal de Azure:

  1. Vaya al clúster de AKS en Azure Portal.
  2. Seleccione Paneles con Grafana (versión preliminar).
  3. Examine los paneles disponibles en Azure Monitor o Azure Managed Prometheus.

Busque los paneles en Azure Monitor>Insights>Containers>Networking. Hay dos opciones en función del nivel elegido para la tabla ContainerNetworkLogs en Log Analytics:

Panel de información Ruta Nivel de tabla Identificador de Grafana
Registros de flujo: nivel básico Azure>Insights>Containers>Networking>Flow Logs - Nivel básico Basic 23155
Registros de flujo: nivel de análisis Azure>Insights>Containers>Networking>Flow Logs - Analytics Tier Analytics (valor predeterminado) 23156

Ambos paneles muestran qué cargas de trabajo de AKS se comunican entre sí, incluidas las solicitudes, las respuestas, las caídas y los errores. Use el que coincida con el nivel configurado para la tabla ContainerNetworkLogs.

Captura de pantalla de los paneles de Grafana en Azure Monitor.

Para más información sobre los componentes del tablero de control, consulte la visión general de los registros de red del contenedor.

Sugerencia

La ContainerNetworkLogs tabla tiene como valor predeterminado el nivel De análisis . Si desea reducir los costos de ingesta y retención, puede cambiar al nivel Básico y usar el panel correspondiente. Para obtener más información, consulte planes de tabla de Log Analytics.

Configuración del modo de registros a petición

Los registros a petición permiten capturar datos de flujo en tiempo real sin almacenamiento persistente. Este modo funciona con planos de datos Cilium y no-Cilium.

El clúster necesita tener habilitados los Servicios de Redes de Contenedores Avanzados. Si aún no tiene un clúster habilitado para ACNS, cree 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

Habilitación de ACNS en un clúster existente

Para habilitar ACNS en un clúster que ya tiene:

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

Nota:

Las características de seguridad de red de contenedor requieren el plano de datos de Cilium.

Obtenga las credenciales del clúster:

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

Instala la CLI de 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}

Uso de la CLI de Hubble

  1. Confirme que el pod de Hubble Relay está en ejecución.

    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. Redireccionar el puerto del Hubble Relay

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

  3. Configure certificados mTLS para el cliente de 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. Compruebe que existen secretos:

    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 los flujos de un pod específico:

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

Configura la Hubble UI

  1. Guarde el siguiente manifiesto 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 el manifiesto:

    kubectl apply -f hubble-ui.yaml

  3. Configurar el reenvío de puertos:

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

  4. Abra http://localhost:12000/ en el explorador para acceder a la interfaz de usuario de Hubble.

Troubleshooting

  • ACNS no habilitado. La ejecución de --enable-container-network-logs sin ACNS genera:

    "Los registros de flujo requieren que se habiliten las redes avanzadas"--enable-acns.

  • Versión de Kubernetes demasiado antigua. La ejecución --enable-container-network-logs en un clúster anterior a la 1.33.0 genera:

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

  • CRD no reconocido. La aplicación de un ContainerNetworkLog en un clúster sin ACNS produce:

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

    Asegúrese de que ACNS está habilitado en el clúster.

Deshabilitar el modo de registros almacenados

Los registros almacenados tienen dos capas: generación de registros en el nodo y reenvío opcional a Azure Monitor. Puede desactivar cualquiera de las capas de forma independiente.

Detención de la generación de registros

La generación de registros está controlada por ContainerNetworkLog recursos personalizados. Al eliminar todos ellos, se impide que se escriban nuevos registros de flujo en /var/log/acns/hubble/events.log en cada nodo.

kubectl delete containernetworklog --all

Para quitar un recurso específico en lugar de todos ellos, ejecute kubectl delete containernetworklog <cr-name>.

Detener el reenvío de registros a Azure Monitor

Si solo quiere dejar de enviar registros al área de trabajo de Log Analytics, pero sigue generandolos en el nodo, deshabilite la integración de Azure Monitor:

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

Los recursos existentes ContainerNetworkLog permanecen en vigor, por lo que los flujos continúan dirigiéndose a cada nodo /var/log/acns/hubble/events.log hasta que se retiran esos recursos.

Limpieza de recursos

Si ya no necesita los recursos, elimine el grupo de recursos:

az group delete --name $RESOURCE_GROUP

Limitaciones

Plano de datos y versión de Kubernetes

  • El modo de registros almacenados requiere el plano de datos de Cilium y Kubernetes 1.33 o posterior.
  • Los registros a petición (Hubble CLI y Hubble UI) funcionan con planos de datos tanto de Cilium como de no Cilium.

Visibilidad de nivel 7 y DNS

  • Los registros de flujo de nivel 7 se rellenan solo cuando la compatibilidad con directivas L7 está habilitada en el clúster y una CiliumNetworkPolicy con reglas L7 cubre el tráfico. Para obtener más información, consulte Configuración de una directiva de nivel 7.
  • Los registros DNS se rellenan solo cuando una directiva FQDN de Cilium (rules.dns más toFQDNs) cubre el tráfico. Las directivas basadas en FQDN no son compatibles con el DNS local del nodo, incluido EL DNS local de AKS. Para obtener más información, consulte Configuración de una directiva de FQDN.

Almacenamiento local de host

  • Sin Azure Monitor o un recopilador externo, los registros de flujo se almacenan en cada nodo en /var/log/acns/hubble/events.log y se limitan a 50 MB. Cuando se alcanza el límite, se sobrescriben las entradas anteriores.
  • Los registros de flujo se escriben en nodos host y los recopila el agente de Azure Monitor. Si habilita la integración de Log Analytics después de aplicar un ContainerNetworkLog CRD, solo se procesarán nuevos registros a partir de ese momento. Los registros históricos del host no se recopilan.

Log Analytics

  • Si cambia el área de trabajo de Log Analytics después de habilitar los registros de red de contenedor, es posible que los registros dejen de fluir al área de trabajo nueva. Esto sucede porque la configuración de recopilación de datos Azure Monitor existente no se actualiza automáticamente. Para evitar este problema, configure el área de trabajo deseada al habilitar primero los registros de red de contenedor o actualice manualmente la regla de recopilación de datos asociada al cambiar las áreas de trabajo. Consulte Configuración de la recopilación de datos en Container Insights.
  • La ContainerNetworkLogs tabla admite los niveles Analytics (valor predeterminado) y Básico . No se admite el nivel auxiliar .

Ventajas y desventajas de agregación

  • La agregación de registros de flujo no conserva marcas de tiempo de flujo individuales, direcciones IP por pod ni campos de cardinalidad alta, como direcciones URL HTTP y nombres de consulta DNS. Use registros a petición para la investigación por flujo.

Contenido relacionado

  • Last updated on