Настройка журналов сети контейнеров с помощью расширенных сетевых служб контейнеров (предварительная версия)

В этой статье описаны действия по настройке и использованию функции журналов сети контейнеров в расширенных сетевых службах контейнеров для службы Azure Kubernetes (AKS). Эти журналы обеспечивают постоянный мониторинг потока сети, адаптированный для повышения видимости в контейнерных средах.

Записывая журналы сети контейнеров, вы можете эффективно отслеживать сетевой трафик, обнаруживать аномалии, оптимизировать производительность и обеспечить соответствие установленным политикам. Следуйте подробным инструкциям по настройке и интеграции журналов сети контейнеров для системы. Дополнительные сведения о функции журналов сети контейнеров см. в разделе "Обзор журналов сети контейнеров".

Предпосылки

• Учетная запись Azure с активной подпиской. Если у вас еще нет аккаунта, создайте бесплатную учетную запись, прежде чем начать.

• Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье "Начало работы с Azure Cloud Shell".

  

• Если вы предпочитаете запускать справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, подумайте о запуске Azure CLI в контейнере Docker. Дополнительные сведения см. в статье Как запустить Azure CLI в контейнере Docker.

  • Если вы используете локальную установку, войдите в Azure CLI с помощью команды az login . Чтобы завершить процесс аутентификации, следуйте шагам, отображаемым в вашем терминале. Сведения о других параметрах входа см. в статье "Проверка подлинности в Azure с помощью Azure CLI".

  • Когда вас попросят, установите расширение Azure CLI при первом использовании. Дополнительные сведения о расширениях см. в статье Использование расширений и управление ими с помощью Azure CLI.

  • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

• Минимальная версия Azure CLI, необходимая для выполнения действий, описанных в этой статье, — 2.75.0. Чтобы найти версию, выполните команду az --version в Azure CLI. Чтобы выполнить установку или обновление, см. сведения в статье Установка Azure CLI.

• Сетевые журналы контейнеров в режиме хранимых журналов работают только для плоскостей данных Cilium.

• Сетевые журналы контейнеров в режиме по запросу работают как для плоскостей данных Cilium, так и для плоскостей данных не Cilium.

• Если существующий кластер имеет версию 1.33 или более раннюю, обновите кластер до последней доступной версии Kubernetes.

• Минимальная версия aks-preview расширения Azure CLI для выполнения действий, описанных в этой статье 19.0.07.

Установите расширение Azure CLI aks-preview

Установите или обновите расширение предварительной версии Azure CLI с помощью az extension add команды или az extension update команды.

# 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

Регистрация флага функции AdvancedNetworkingFlowLogsPreview

Сначала зарегистрируйте флаг функции AdvancedNetworkingFlowLogsPreview с помощью az feature register команды:

az feature register --namespace "Microsoft.ContainerService" --name "AdvancedNetworkingFlowLogsPreview"

Проверьте успешную регистрацию с помощью команды az feature show. Для завершения регистрации потребуется несколько минут.

az feature show --namespace "Microsoft.ContainerService" --name "AdvancedNetworkingFlowLogsPreview"

Когда функция отображается "Зарегистрировано", обновите регистрацию Microsoft.ContainerService поставщика ресурсов с помощью az provider register команды.

Ограничения

• Данные потока уровня 7 записываются только в том случае, если включена поддержка политики уровня 7. Дополнительные сведения см. в разделе "Настройка политики уровня 7".
• Потоки системы доменных имен (DNS) и связанные метрики записываются только в случае применения сетевой политики Cilium с использованием полностью квалифицированного доменного имени (FQDN). Дополнительные сведения см. в разделе "Настройка политики полного доменного имени".
• Подключение с помощью Terraform в настоящее время не поддерживается.
• Если Log Analytics не настроен для хранилища журналов, сетевые журналы контейнеров ограничены не более 50 МБ хранилища. По достижении этого ограничения новые записи перезаписывают старые журналы.
• Если для плана таблицы журнала задано значение "Базовые журналы," предварительно созданные панели мониторинга Grafana не функционируют как ожидалось.
• План таблицы вспомогательных журналов не поддерживается.

Настройка режима хранимых журналов для журналов сети контейнеров

Методы развертывания

Вы можете получить доступ к логам контейнерной сети, используя разные методы развертывания.

Новые кластеры

В этом разделе описано, как настроить журналы сети контейнеров в новом кластере AKS с начала до конца.

Создайте новый кластер AKS с расширенными средствами сетевого взаимодействия контейнеров

az aks create Используйте команду с флагом--enable-acns, чтобы создать новый кластер AKS с всеми функциями расширенных сетевых служб контейнеров. К этим функциям относятся:

• Наблюдаемость сети контейнеров: Предоставляет аналитические сведения о сетевом трафике. Дополнительные сведения см. в разделе "Наблюдаемость сети контейнеров".

• Безопасность сети контейнеров: предлагает такие функции безопасности, как фильтрация полного доменного имени. Дополнительные сведения см. в разделе "Безопасность сети контейнеров".

# Set an environment variable for the AKS cluster name. Make sure you replace the placeholder with your own value.
export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"
export LOCATION="<location>"

# Create the resource group if it doesn't already exist
az group create --name $RESOURCE_GROUP --location $LOCATION

# Create an AKS cluster
az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --generate-ssh-keys \
    --location $LOCATION \
    --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 or later \
    --enable-acns

Настройка настраиваемых ресурсов для фильтрации журналов

Чтобы настроить сетевые журналы контейнеров в режиме хранимых журналов, необходимо определить определенные пользовательские ресурсы, чтобы задать фильтры для сбора журналов. Если определен хотя бы один пользовательский ресурс, журналы собираются и хранятся на узле /var/log/acns/hubble/events.log.

Чтобы настроить ведение журнала, необходимо определить и применить ContainerNetworkLog тип настраиваемого ресурса. Вы устанавливаете фильтры, такие как пространство имен, pod, служба, порт, протокол и вердикт. Одновременно в кластере может существовать несколько пользовательских ресурсов. Если настраиваемый ресурс не определен с ненулевыми фильтрами, журналы не сохраняются в указанном расположении.

На следующем примере конфигурации показано, как настроить тип пользовательского ресурса ContainerNetworkLog.

Шаблон CRD ContainerNetworkLog

apiVersion: acn.azure.com/v1alpha1
kind: ContainerNetworkLog
metadata:
  name: sample-containernetworklog # Cluster scoped
spec:
  includefilters: # List of filters
    - name: sample-filter # Filter name
      from:
        namespacedPod: # List of source namespace/pods. Prepend namespace with /
          - sample-namespace/sample-pod
        labelSelector: # Standard k8s label selector
          matchLabels:
            app: frontend
            k8s.io/namespace: sample-namespace
          matchExpressions:
            - key: environment
              operator: In
              values:
                - production
                - staging
        ip: # List of source IPs; can be 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: # List of protocols; can be tcp, udp, dns
        - tcp
        - udp
        - dns
      verdict: # List of verdicts; can be forwarded, dropped
        - forwarded
        - dropped

В следующей таблице описаны поля в определении настраиваемого ресурса:

• Примените пользовательский ресурс ContainerNetworkLog, чтобы настроить сбор журналов в кластере.

  kubectl apply -f <crd.yaml>
  

  Подсказка

  Практический пример настраиваемой конфигурации ресурсов ContainerNetworkLog см. в примере CRD в документации ПО AKS Labs.

Журналы, хранящиеся локально на узлах хоста, являются временными, так как сам хост или узел не является постоянным хранилищем. Журналы на узлах также поворачиваются, когда их размер достигает 50 МБ. Для долгосрочного хранения и анализа рекомендуется настроить агент Azure Monitor в кластере для сбора и хранения журналов в рабочей области Log Analytics.

Кроме того, вы можете интегрировать партнерскую службу ведения журналов, например OpenTelemetry коллектор, для получения дополнительных опций управления журналами.

Настройка Azure Monitor для управляемого хранилища (рекомендуется)

Для постоянного хранения и расширенной аналитики настройте агент Azure Monitor для сбора и хранения журналов в рабочей области Log Analytics:

# Set an environment variable for the AKS cluster name. Make sure you replace the placeholder with your own value.
  export CLUSTER_NAME="<aks-cluster-name>"
  export RESOURCE_GROUP="<aks-resource-group>"

# Enable azure monitor with high log scale mode
    ### To use the default Log Analytics workspace
    az aks enable-addons -a monitoring --enable-high-log-scale-mode -g $RESOURCE_GROUP -n $CLUSTER_NAME

    ### To use an existing Log Analytics workspace
    az aks enable-addons -a monitoring --enable-high-log-scale-mode -g $RESOURCE_GROUP -n $CLUSTER_NAME --workspace-resource-id <workspace-resource-id>

# Update the AKS cluster with the enable-container-network-logs flag
  az aks update --enable-acns \
    --enable-container-network-logs \
    -g $RESOURCE_GROUP \
    -n $CLUSTER_NAME

Существующие кластеры

# Set environment variables for your existing cluster. Make sure you replace the placeholders with your own values.
export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<aks-resource-group>"

Настройка интеграции с Log Analytics в существующем кластере

Чтобы включить журналы сети контейнеров в существующем кластере, выполните приведенные действия.

1. Проверьте, включены ли надстройки мониторинга в этом кластере:

    az aks addon list -g $RESOURCE_GROUP -n $CLUSTER_NAME
   

2. Если включены надстройки мониторинга, отключите надстройки мониторинга:

    az aks disable-addons -a monitoring -g $RESOURCE_GROUP -n $CLUSTER_NAME
   

   Выполните этот шаг, так как мониторинг надстроек уже может быть включен, но не для высокого масштаба. Дополнительные сведения см. в режиме высокой шкалы.

3. Задайте для Azure Monitor значение enable-high-log-scale-mode:

    ### Use default Log Analytics workspace
    az aks enable-addons -a monitoring --enable-high-log-scale-mode -g $RESOURCE_GROUP -n $CLUSTER_NAME 
    ### Use existing Log Analytics workspace
    az aks enable-addons -a monitoring --enable-high-log-scale-mode -g $RESOURCE_GROUP -n $CLUSTER_NAME --workspace-resource-id <workspace-resource-id>
   

4. Обновите кластер AKS с помощью флага enable-container-network-logs :

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

5. Создайте CRD согласно приведенному выше шаблону ContainerNetworkLog и примените его к началу сбора журналов в рабочей области Log Analytics.

   Подсказка

   Практический пример настраиваемой конфигурации ресурсов ContainerNetworkLog см. в примере CRD в документации ПО AKS Labs.

Просмотр потоков L7 и ошибок DNS

Чтобы записать данные потока уровня 7 (L7) и ошибки и потоки DNS в журналах сети контейнеров, необходимо применить политики сети Cilium с включенной фильтрацией FQDN и поддержкой политики L7. Без этих политик данные потока, связанные с L7 и DNS, не будут записаны.

Пример политики сети Cilium с фильтрацией полного доменного имени и поддержкой L7:

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"

Примените политику с помощью:

kubectl apply -f l7-dns-policy.yaml

Для получения дополнительной информации см. раздел "Настройка политики уровня 7" и раздел "Настройка политики полностью квалифицированного доменного имени (FQDN)".

Распространенные действия после установки для проверки конфигурации

Следующие шаги применяются как к новым, так и к существующим настройкам кластера.

Получение учетных данных кластера

Получите учетные данные кластера с помощью az aks get-credentials команды:

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

Проверка установки

Убедитесь, что функция логирования потока сети Retina включена.

   az aks show -g $RESOURCE_GROUP -n $CLUSTER_NAME

Ожидаемые выходные данные:

"networkProfile":{
 "advancedNetworking": {
  "enabled": true,
  "observability":{
    "enabled": true
     }
 }
}
----------------------------
"osmagent":{
 "config":{
  "enableContainerNetworkLogs": "True"
 }
}

Проверьте, какие пользовательские определения ресурсов установлены для журналов потоков:

  kubectl get containernetworklog 

Эта команда перечисляет все пользовательские ContainerNetworkLog ресурсы, созданные в кластере.

Убедитесь, что настраиваемый ContainerNetworkLog ресурс применяется:

   k describe containernetworklog <cr-name>

Ожидается увидеть узел Spec, который содержит Include filters, и узел Status. Значение для Status>State должно быть CONFIGURED (не FAILED).

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

Пользователи могут применять несколько пользовательских ContainerNetworkLog ресурсов в кластере. Каждый пользовательский ресурс имеет собственное состояние.

Запрос журналов сетевых потоков контейнеров в панели мониторинга Log Analytics

Если журналы сетевых потоков контейнеров включены в рабочую область Log Analytics, у вас есть доступ к историческим данным, которые позволяют анализировать закономерности сетевого трафика с течением времени. Эти журналы можно запросить с помощью ContainerNetworkLog таблицы для выполнения подробного анализа и устранения неполадок.

Клиенты могут использовать язык запросов Kusto (KQL) для анализа сетевых данных в Log Analytics. Эти исторические данные бесценны для понимания шаблонов поведения сети, выявления инцидентов безопасности, устранения проблем с подключением и выполнения анализа первопричин в течение длительных периодов. Возможность корреляции сетевых событий во время помогает обнаруживать периодические проблемы и понимать потоки трафика, которые могут не быть очевидными в режиме реального времени мониторинга.

Чтобы просмотреть примеры запросов, которые можно применить для устранения неполадок с подключением, ознакомьтесь с прогрессивным диагнозом с помощью журналов потоков в документации AKS Labs.

Azure Managed Grafana

Вы можете получить доступ к предварительно созданным панелям мониторинга Grafana на портале Azure. Перейдите к ресурсу Azure Monitor или кластеру Службы Azure Kubernetes (AKS), чтобы просмотреть и взаимодействовать с этими панелями мониторинга. Но до этого:

1. Убедитесь, что поды журналов Azure запущены:

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

   Ваш результат должен выглядеть подобно следующему примеру:

   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
   
   

2. Убедитесь, что ваша рабочая область Managed Grafana может получить доступ ко всем данным мониторинга в соответствующей подписке и выполнить поиск по ним. Этот шаг необходим для доступа к предварительно созданным панелям мониторинга для журналов сетевых потоков.

   Вариант использования 1. Если вы являетесь владельцем подписки или администратором доступа пользователей, при создании управляемой рабочей области Grafana она поставляется с ролью средства чтения мониторинга, предоставленной для всех данных Azure Monitor и ресурсов Log Analytics в подписке. Новая управляемая рабочая область Grafana может получать доступ ко всем данным о мониторинге в подписке и выполнять поиск. Он может просматривать метрики и журналы Azure Monitor со всех ресурсов и просматривать все журналы, хранящиеся в рабочих областях Log Analytics в подписке.

   Вариант использования 2. Если вы не являетесь владельцем подписки или администратором доступа пользователей, или если рабочие области Log Analytics и Managed Grafana находятся в разных подписках, Grafana не может получить доступ к Log Analytics и подписке. Рабочая область Grafana должна иметь роль Monitoring Reader в соответствующей подписке для доступа к предварительно созданным панелям Grafana. В этом сценарии выполните следующие действия, чтобы предоставить доступ:

   1. В рабочей области Managed Grafana перейдите в Параметры>Идентификация.

      

   2. Выберите назначения ролей Azure>Добавить назначения ролей.

      

   3. Для области введите подписку. Выберите подписку. Установите роль на Читатель мониторинга, затем выберите Сохранить.

      

   4. Проверьте источник данных для управляемого экземпляра Grafana. Чтобы проверить подписку на источник данных для панелей мониторинга Grafana, перейдите на вкладку "Источник данных" в экземпляре Управляемой Grafana:

      

Визуализация на панелях мониторинга Grafana

Панели мониторинга Azure Monitor с Grafana позволяют использовать возможности запроса, преобразования и визуализации Grafana для метрик и журналов, собранных в Azure Monitor. Этот параметр можно использовать в качестве альтернативы визуализации журналов сетевого потока контейнера.

1. Перейдите в левую область кластера Kubernetes на портале Azure.
2. Выберите панели мониторинга с помощью Grafana (предварительная версия).
3. Просмотрите список доступных панелей мониторинга в списках Azure Monitor или Azure Managed Prometheus.
4. Выберите панель мониторинга, например Azure | Аналитика | Контейнеры | Сеть | Журналы потоков.

Вы можете визуализировать журналы сетевых потоков контейнера для анализа с помощью двух предварительно созданных панелей мониторинга Grafana. Вы можете получить доступ к информационным панелям через Azure Managed Grafana или на портале Azure.

Чтобы упростить анализ журналов, мы предоставляем две предварительно настроенные панели мониторинга Azure Managed Grafana:

• Перейдите в Azure>Insights>контейнеры>сетевые>журналы потоков. Эта панель предоставляет визуализации, в которых нагрузки AKS обмениваются данными друг с другом, включая сетевые запросы, ответы, потери и ошибки. В настоящее время для импорта этих панелей мониторинга необходимо использовать идентификатор 23155 .

  

• Перейдите в Azure>Insights>Containers>Networking> журналы потоков (внешний трафик). Эта панель мониторинга предоставляет визуализации, на которых рабочие нагрузки AKS отправляют сообщения и получают их извне кластера AKS, включая сетевые запросы, ответы, сбросы и ошибки. Используйте идентификатор 23156.

  

Дополнительные сведения об использовании этой панели мониторинга см. в обзоре журналов сети контейнеров.

Настройка режима журналов по запросу

Режим журналов по запросу для сетевых потоков работает как с Cilium, так и с плоскостями данных, отличных от Cilium.

Для продолжения необходимо иметь кластер AKS с включенной функцией расширенных сетевых служб контейнеров.

Команда az aks create с флагом --enable-acnsрасширенных сетевых служб контейнеров создает новый кластер AKS со всеми функциями расширенных сетевых служб контейнеров. Доступны следующие функции:

• Наблюдение за сетью контейнеров. Предоставляет аналитические сведения о сетевом трафике. Дополнительные сведения см. в разделе "Наблюдаемость сети контейнеров".

• Безопасность сети контейнеров: предлагает такие функции безопасности, как фильтрация полного доменного имени. Дополнительные сведения см. в статье "Безопасность сети контейнеров".

# Set an environment variable for the AKS cluster name. Make sure you replace the placeholder with your own value.
export CLUSTER_NAME="<aks-cluster-name>"

# Create an AKS cluster
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

# Set an environment variable for the AKS cluster name. Make sure you replace the placeholder with your own value.
export CLUSTER_NAME="<aks-cluster-name>"

# Create an AKS cluster
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

Включение продвинутых сетевых служб для контейнеров в существующем кластере

Команда az aks update с флагом --enable-acns обновляет существующий кластер AKS со всеми функциями расширенных сетевых служб контейнеров. К этим функциям относятся наблюдение за сетями контейнеров и безопасность сети контейнеров.

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

Затем получите учетные данные кластера с помощью az aks get-credentials команды:

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

Установка интерфейса командной строки Hubble

Установите CLI Hubble для доступа к собранным данным. Выполните следующие команды:

# Set environment variables
export HUBBLE_VERSION=v1.16.3
export HUBBLE_ARCH=amd64

#Install the Hubble CLI
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}

Визуализация потоков Hubble

1. Убедитесь, что поды Hubble запущены.

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

   Ваш результат должен выглядеть подобно следующему примеру:

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

2. Перенаправьте сервер ретрансляции Hubble:

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

3. Протокол взаимной аутентификации TLS (mTLS) обеспечивает безопасность сервера Hubble Relay. Чтобы клиент Hubble мог получать потоки, необходимо получить соответствующие сертификаты и настроить его вместе с ними. Примените сертификаты с помощью следующих команд:

   #!/usr/bin/env bash
       set -euo pipefail
   set -x
   
   # Directory where certificates will be stored
   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//./\\.}']}"
   
     # Retrieve the secret and decode it
     kubectl get secret hubble-relay-client-certs -n kube-system \
       -o jsonpath="${JSONPATH}" | \
       base64 -d > "$CERT_DIR/$FILE"
   
     # Set the appropriate hubble CLI config
     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. Убедитесь, что секреты были созданы:

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

   Ваш результат должен выглядеть подобно следующему примеру:

   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. Убедитесь, что модуль Hubble Relay работает.

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

Визуализация с помощью пользовательского интерфейса Hubble

1. Чтобы использовать пользовательский интерфейс Hubble, сохраните следующий сценарий в 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. Примените манифест к кластеру hubble-ui.yaml :

   kubectl apply -f hubble-ui.yaml
   

3. Настройте перенаправление портов для пользовательского интерфейса Hubble:

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

4. В веб-браузере введите http://localhost:12000/, чтобы получить доступ к пользовательскому интерфейсу Hubble.

Основы устранения неполадок

• Расширенные сетевые службы контейнеров являются необходимым условием для включения функции сбора журналов агента Azure Monitor.

  Попробуйте включить возможности журналов потоков сети контейнеров в кластере без включения расширенных сетевых служб контейнеров, например:

  az aks update -g test-rg -n test-cluster --enable-container-network-logs

  Приводит к возникновению сообщения об ошибке:

  Flow logs requires '--enable-acns', advanced networking to be enabled, and the monitoring addon to be enabled.

• Если версия Kubernetes кластера более ранняя, чем версия 1.33.0, попытка выполнить --enable-container-network-logs приводит к сообщению об ошибке.

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

  где %s находится ваша версия Kubernetes.

• Если вы пытаетесь запустить --enable-container-network-logs в подписке, где не включен флаг управления доступностью функций Azure (AFEC), появится сообщение об ошибке.

  Feature Microsoft.ContainerService/AdvancedNetworkingFlowLogsPreview is not enabled. Please see https://aka.ms/aks/previews for how to enable features.

• Если вы пытаетесь применить ContainerNetworkLog пользовательский ресурс в кластере, где не включены расширенные сетевые службы контейнеров, появится сообщение об ошибке:

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

  Сначала установите пользовательские ресурсы.

Отключение сетевых журналов контейнера: режим хранимых журналов в существующем кластере

Если все пользовательские ресурсы удалены, сбор журналов потоков прекращается, так как фильтры не определены для сбора.

Чтобы отключить сбор журналов сети контейнеров агентом Azure Monitor, выполните следующую команду:

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

Очистите ресурсы

Если вы не планируете использовать это приложение, удалите ресурсы, созданные в этой статье, с помощью az group delete команды.

  az group delete --name $RESOURCE_GROUP

Связанный контент

• Дополнительные сведения об услугах расширенной настройки сетей контейнеров для AKS.
• Изучите функцию наблюдения за сетями контейнеров в расширенных сетевых службах контейнеров.