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

Каждый под, служба и узел в кластере Kubernetes постоянно создают сетевую активность: открытие подключений, пересылка или отбрасывание пакетов, разрешение или сбой запросов DNS. Понимание того, что активность важна для отладки, планирования емкости и поддержания здоровья служб. Большинство настроек мониторинга могут иметь два недостатка:

• Недостаточно видимости. Агрегаты на уровне узла говорят, что что-то не так, но не где. Без разбивки на уровне pod, которая включает исходный и конечный контекст, изоляция неработоспособных рабочих нагрузок означает угадывание.
• Слишком много данных в большом объёме. Кластер под управлением сотен микрослужб может создавать тысячи временных рядов метрик на узел. Сбор всех данных увеличивает затраты на хранение и замедляет работу панелей мониторинга.

Метрики сети контейнеров в Advanced Container Networking Services для Azure Kubernetes Service (AKS) решают обе задачи. Функция собирает сетевые метрики на уровне узлов и подов в поддерживаемых плоскостях данных Cilium и других на платформах Linux и Windows.

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

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

Результат: эффективная сетевая наблюдаемость на любом поддерживаемом уровне данных с необязательной экономичной фильтрацией на базе Cilium.

Метрики сети контейнеров обеспечивают глубокую видимость на уровне рабочей нагрузки, что способствует устранению неполадок и планированию. Фильтрация на уровне источника с использованием Cilium помогает поддерживать затраты на наблюдаемость в пропорции к рабочим нагрузкам, критически важным для бизнеса.

Сбор и фильтрация на первый взгляд

Используйте эту таблицу, чтобы быстро понять, где доступна широкая коллекция и где доступна детальная фильтрация:

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

• Степень детализации на уровне узла и pod. Отслеживайте объем трафика, уровень потерь и состояния подключения на уровне узла для оценки состояния инфраструктуры. Углубитесь в отдельные поды с метками источника и назначения, чтобы точно определить рабочую нагрузку, вызывающую проблему.

• Быстрое устранение неполадок. Если служба начинает сбрасывать пакеты или DNS-запросы не удаются, Pod-уровневые метрики дают возможность изолировать проблему до конкретного pod, пространства имен или протокола в течение секунд, а не часов.

• Гибкая визуализация. Храните метрики в Azure Managed Prometheus и визуализируйте в Управление Azure для Grafana (полностью управляемой), или используйте собственную инфраструктуру Prometheus и Grafana.

• Изначально масштабируемый. Конвейер обрабатывает большие динамические кластеры с сотнями узлов и тысячами pod'ов, не заставляя выбирать между комплексным охватом и объемом данных, с которым можно эффективно работать.

• Целевая наблюдаемость (кластеры Cilium). В кластерах Cilium фильтрация на уровне источника позволяет определять нужные пространства имен, метки подов или типы метрик и собирать только их. Нет необходимости в постобработке данных после их сбора.

• Более низкие затраты на прием метрик (кластеры Cilium). Так как фильтрация выполняется в источнике на каждом узле, нежелательные временные ряды метрик никогда не извлекаются, не передаются и не поступают в серверную часть Prometheus. Вы оплачиваете только те метрики, которые вам действительно нужны. В больших кластерах, где нефильтрованная коллекция может создавать тысячи временных рядов на узел, фильтрация на уровне источника может значительно сократить затраты Azure на прием и хранение управляемой службы Prometheus в Azure.

Принцип работы

Стек агента на каждом узле зависит от плоскости данных, как показано на схеме.

Узлы Linux Cilium используют многоуровневый стек на основе eBPF: хуки ядра eBPF захватывают необработанные данные трафика, Cilium их обрабатывает, и Hubble предоставляет в виде метрик формата Prometheus. Так как Hubble находится между узлом и конечной точкой сбора, фильтрация на уровне источника выполняется здесь — вы выбираете пространства имен, метки pod и типы метрик перед выходом из узла.

Linux не-Cilium nodes использовать перехватчики ядра eBPF в Microsoft Retina с слоем Hubble сверху для проверки потока. Microsoft Retina обрабатывает сбор метрик и экспортирует метрики уровня узла и pod в формате Prometheus.

Из всех путей метрики собираются в формате Prometheus и передаются в Azure Управляемый Prometheus или собственную серверную часть Prometheus, а затем визуализируются в Azure Управляемый Grafana или собственном стеке Grafana.

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

Когда следует использовать метрики сети контейнеров

Метрики сети контейнеров предназначены для команд, которым нужны ориентированные, практические сетевые данные, а не необработанные данные телеметрии. Ниже приведены распространенные сценарии.

• Отладка определенной рабочей нагрузки. Используйте метрики уровня pod для изоляции удаления пакетов, сброса TCP или сбоев DNS для определенной службы. В кластерах Cilium фильтрация может сузить сбор данных только для указанного пространства имен или метки pod, уменьшая шум, присутствующий в кластере.
• Мониторинг кластеров с несколькими клиентами. Отслеживайте состояние сети для каждого пространства имен, чтобы каждая команда имела возможность видеть свои собственные шаблоны трафика. В кластерах Cilium фильтрация, основанная на области, ограничивает сбор пространства имен, специфичного для арендатора.
• Планирование мощностей. Отслеживайте перенаправленные и удаленные числа байтов на узел, чтобы определить насыщенные связи или несбалансированное размещение рабочей нагрузки.
• Мониторинг работоспособности DNS. Выявляйте сбои запросов DNS и медленное время разрешения, чтобы перехватывать проблемы, прежде чем они перерастут в ошибки приложения.
• Сокращение затрат на наблюдаемость в больших масштабах. В больших кластерах нефильтрованная коллекция может создавать тысячи временных рядов на узел. В кластерах Cilium фильтрация на уровне источника удаляет нежелательные серии данных перед приемом, чтобы затраты соответствовали выбранным рабочим нагрузкам и типам метрик.

Как выбрать, что собирать (кластеры Cilium)

Используйте эту модель развертывания для балансировки видимости и затрат:

1. Начните с общей коллекции в непроизводственном пространстве имен, чтобы установить исходную точку.
2. Сохраняйте метрики потерь пакетов, DNS и состояния TCP для критически важных пространств имен.
3. Ограничьте метрики потока высокой уникальности только критически важными для бизнеса рабочими нагрузками.
4. Просмотрите тенденции приема Prometheus и уточняйте фильтры еженедельно.

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

Перед просмотром таблиц метрик

Помните следующее:

• Метрики уровня узла доступны в поддерживаемых плоскостях данных Cilium и не Cilium.
• Метрики уровня pod доступны в Linux.
• Фильтрация на уровне источника доступна только в кластерах Cilium.
• В кластерах Cilium метрики DNS требуют политики сети Cilium FQDN.

Справочник по метрикам

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

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

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

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

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

Метрики уровня подов включают сведения об исходных и целевых подах, чтобы определить проблемы с сетью на уровне отдельного рабочего процесса. Эти метрики охватывают объем трафика, потерянные пакеты, сбросы TCP и потоки уровней 4 и 7.

Метрики DNS (счетчики запросов, коды ответов и ошибки) собираются по умолчанию на плоскостях данных, отличных от Cilium. На плоскостях данных Cilium для метрик DNS требуется сетевая политика Cilium FQDN. Вы также можете устранить неполадки с DNS в режиме реального времени с помощью интерфейса командной строки Hubble.

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

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

• cluster

• instance (имя узла)

• source или destination

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

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

Limitations

Платформа и плоскость данных:

• Метрики уровня pod доступны только в Linux.
• Плоскость данных Cilium поддерживается начиная с Kubernetes версии 1.29.
• Фильтрация метрик уровня источника доступна только в кластерах Cilium.
• Метки имеют тонкие различия между кластерами Cilium и не-Cilium.

Метрики DNS:

• В кластерах Cilium метрики DNS требуют сетевой политики Cilium FQDN, или можно использовать Hubble CLI для диагностики DNS в реальном времени.

Известные проблемы :

• Если агент узла Hubble вышел из строя, узел-релей Hubble может завершиться сбоем, что может прервать сеансы Hubble CLI.

Поддержка FIPS (только плоскостей данных, отличных от Cilium):

• FIPS недоступен на узлах Ubuntu 20.04 из-за ограничений ядра. Вместо этого используйте пул узлов Azure Linux или Ubuntu 22.04. Это ограничение не применяется к плоскостям данных Cilium.

Масштаб:

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

Pricing

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

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

• Настройка метрик сети контейнеров
• Настройка фильтрации метрик сети контейнеров
• Расширенные сетевые службы контейнеров для AKS
• Наблюдаемость сети контейнеров в расширенных сетевых службах контейнеров
• Безопасность сети контейнеров в расширенных сетевых службах контейнеров