Поделиться через

Что такое метрики сети контейнеров?

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

Сбор этих метрик важен для понимания того, как контейнеры общаются, как трафик течёт между службами и где могут возникнуть узкие места или перебои. Расширенные сетевые службы контейнеров легко интегрируются с такими средствами мониторинга, как Prometheus и Grafana, чтобы обеспечить полное представление сетевых метрик. Используйте метрики для подробного устранения неполадок, оптимизации сети и настройки производительности.

В облачном мире поддержание работоспособной и эффективной сети в динамической контейнерной среде жизненно важно, чтобы обеспечить выполнение приложений должным образом. Без надлежащей видимости сетевого трафика и его шаблонов выявление потенциальных проблем или неэффективности становится сложной задачей.

Important

Начиная с 30 ноября 2025 г. служба Azure Kubernetes (AKS) больше не поддерживает или предоставляет обновления безопасности для Azure Linux 2.0. Образ узла Linux 2.0 Azure заморожен в выпуске 202512.06.0. Начиная с 31 марта 2026 г. образы узлов будут удалены, и вы не сможете масштабировать пулы узлов. Выполните миграцию в поддерживаемую версию Linux Azure, обновив пулы узлов до поддерживаемой версии Kubernetes или переключив ее на osSku AzureLinux3. Дополнительные сведения см. в вопросе о прекращении поддержки на GitHub и объявлении об устаревании обновлений Azure. Чтобы оставаться в курсе объявлений и обновлений, следуйте заметкам о выпуске AKS.

Ключевые преимущества

  • Глубокое представление о производительности сети

  • Улучшенное устранение неполадок и оптимизация

  • Упреждающее обнаружение аномалий

  • Улучшение управления ресурсами и масштабирования

  • Планирование емкости и соответствие требованиям

  • Фильтрация метрик на уровне источника для оптимизации затрат и снижения шума и фильтрация сетевых метрик контейнера

  • Упрощенные параметры хранилища метрик и визуализации. Доступны следующие параметры:

    • Управляемая служба Azure для Prometheus и Azure Managed Grafana: Azure управляет инфраструктурой и обслуживанием, чтобы сосредоточиться на настройке метрик и визуализации метрик.
    • Используйте собственные (BYO) Prometheus и Grafana: развертываете и настраиваете собственные экземпляры Prometheus и Grafana и управляете основной инфраструктурой.

Метрики, захваченные

Метрики уровня узла

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

Следующие метрики агрегируются для каждого узла. Все метрики включают одну из этих меток:

  • cluster
  • instance (имя узла)

В сценариях плоскости данных Cilium наблюдение за сетями контейнеров предоставляет метрики только для Linux. В настоящее время Windows не поддерживается. Cilium предоставляет несколько метрик, включая указанные ниже метрики, используемые при наблюдении за сетями контейнеров.

Имя метрики Description Дополнительные метки Linux Windows
cilium_forward_count_total Общее число пересылаемых пакетов direction ✅ ❌
cilium_forward_bytes_total Общее число перенаправленных байтов direction ✅ ❌
cilium_drop_count_total Общее число потерянных пакетов direction, reason ✅ ❌
cilium_drop_bytes_total Общее число утраченных байтов direction, reason ✅ ❌

Метрики уровня pod (метрики Hubble)

Эти метрики Prometheus включают сведения об исходном и целевом pod, чтобы определить проблемы, связанные с сетью, на детальном уровне. Метрики охватывают такие сведения, как объем трафика, удаленные пакеты, сбросы TCP и потоки пакетов уровня 4/уровня 7. Метрики DNS, такие как ошибки DNS и запросы DNS отсутствующих ответов, собираются по умолчанию для плоскостей данных, отличных от Cilium. Для плоскостей данных Cilium политика полного доменного имени Cilium требуется для сбора метрик DNS, или клиенты также могут устранять неполадки DNS с помощью Интерфейса командной строки Hubble и наблюдения журналов в режиме реального времени.

В следующей таблице описаны метрики, агрегированные для каждого pod (информация об узле сохраняется).

Все метрики включают метки:

  • cluster

  • instance (имя узла)

  • source или destination

    • Для исходящего трафика применяется метка, source указывающая исходное пространство имен pod и имя.

    • Для входящего трафика применяется метка, destination указывающая пространство имен и имя целевого модуля pod.

Имя метрики Description Дополнительные метки Linux Windows
hubble_dns_queries_total Общий объем ЗАПРОСОВ DNS по запросу source или destination, query, qtypes тип запроса ✅ ❌
hubble_dns_responses_total Общее количество ответов DNS по запросу и ответу sourceor destination, queryqtypes (тип запроса), rcode (возвращаемый код), ips_returned (число IP-адресов) ✅ ❌
hubble_drop_total Общее число потерянных пакетов sourceили destination, protocolreason ✅ ❌
hubble_tcp_flags_total Общее число tcp-пакетов по флагу source или destination, flag ✅ ❌
hubble_flows_processed_total Общий объем обработанных сетевых потоков (трафик уровня 4/7) source или destination, protocol, verdict, type, subtype ✅ ❌

Фильтрация сетевых метрик контейнера (предварительная версия)

Теперь, когда у вас есть возможность собирать комплексные метрики на уровнях узлов и модулей pod, вы можете столкнуться со значительным объемом данных. Чтобы снизить шум и оптимизировать затраты на хранение, наблюдение за сетями контейнеров предоставляет фильтрацию сетевых метрик контейнера. Эта функция позволяет фильтровать метрики в источнике перед их сбором и хранением, что позволяет контролировать, какие метрики наиболее важны для конкретных потребностей в мониторинге и устранении неполадок. Эта функция доступна только для кластеров Cilium.

Фильтрация сетевых метрик контейнера особенно важна в крупномасштабных рабочих средах, где объем метрик может повлиять на затраты на хранение и производительность запросов. Отфильтровав ненужные метрики в начале процесса сбора, вы можете сосредоточиться на данных, наиболее важных для ваших операций, сохраняя видимость, необходимую для эффективного мониторинга сети.

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

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

Limitations

  • Метрики уровня pod доступны только в Linux.
  • Плоскость данных Cilium поддерживается начиная с Kubernetes версии 1.29.
  • Метки имеют тонкие различия между кластерами Cilium и не-Cilium.
  • Для кластеров на основе Cilium метрики DNS доступны только для модулей pod, имеющих политики сети Cilium (CNP), настроенные в своих кластерах, или клиенты также могут устранять неполадки DNS с помощью интерфейса командной строки Hubble и наблюдения журналов в режиме реального времени.
  • Журналы потоков в настоящее время недоступны в облаке с воздушным зазором.
  • Ретранслятор Hubble может завершиться сбоем, если один из агентов узла Hubble выходит из строя, и это может вызвать перебои в работе интерфейса командной строки Hubble.
  • При использовании расширенных сетевых служб контейнеров (ACNS) в плоскостях данных, отличных от Cilium, поддержка FIPS недоступна на узлах Ubuntu 20.04 из-за ограничений ядра. Чтобы включить FIPS в этом сценарии, необходимо использовать пул узлов Linux Azure. Ожидается, что это ограничение будет разрешено с помощью выпуска Ubuntu 22 FIPS. Информацию об обновлениях см. в трекере проблем AKS.
  • Фильтрация метрик сети контейнеров доступна только для кластеров Cilium.

См. матрицу поддержки FIPS ниже:

Операционная система Поддержка FIPS
Azure Linux 3.0 Yes
Azure Linux 2.0 Yes
Ubuntu 20.04 No

Это ограничение не применяется при запуске ACNS на плоскостях данных Cilium.

Scale

Управляемая служба для Prometheus в Azure Monitor и Azure Managed Grafana накладывает ограничения на масштабирование, специфичные для услуг. Дополнительные сведения см. в разделе "Сбор метрик Prometheus в большом масштабе в Azure Monitor".

Pricing

Important

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

Дополнительные сведения о ценах см. в разделе "Расширенные сетевые службы контейнеров" — цены.

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

  • Last updated on