Использование VPC Flow Logs для устранения неполадок в рабочих нагрузках GKE

Наличие информации о сетевом трафике имеет решающее значение для эффективной работы сред Kubernetes. Когда сервис замедляется или теряет подключение, знание того, кто с кем взаимодействует, позволяет быстро сузить круг поиска проблемы. В стандартной облачной сети журналы потоков обеспечивают такой обзор, фиксируя соединения между IP-адресами, портами и протоколами. Однако в Kubernetes поды являются временными. Их IP-адреса постоянно меняются по мере масштабирования, сбоев или перемещения подов между нодами, поэтому запись в сыром логе о том, что адрес 10.4.2.18 связывается с 10.4.8.44, мало что говорит о том, какая рабочая нагрузка (и под) владела этим адресом, в каком пространстве имен она находилась или к какому приложению пыталась обратиться. К тому моменту, когда вы найдете нужную информацию в кластере, под уже может исчезнуть!

В среде Google Cloud функция VPC Flow Logs устраняет этот пробел на сетевом уровне. Виртуальная сеть Google Cloud уже видит каждое соединение, создаваемое подом, поэтому каждый выбранный для анализа потоковый лог записывается с метаданными Google Kubernetes Engine (GKE), стоящими за IP-адресом: под, рабочая нагрузка, пространство имен и сервис. Вы получаете привязку трафика L3/L4 к рабочим нагрузкам без развертывания дополнительных агентов или сайдкаров, что дополняет инструменты наблюдаемости интерфейса сетевых контейнеров (CNI) и плоскости данных внутри кластера, которые вы уже можете использовать для более детального анализа. Давайте подробнее рассмотрим, как VPC Flow Logs и GKE работают вместе и как начать работу с ними.

Как метаданные GKE обогащают VPC Flow Logs

VPC Flow Logs выполняет выборку трафика непосредственно внутри виртуальной сети Google Cloud. Когда журналы потоков включены для подсети, в которой размещен кластер GKE, каждая запись о трафике пода, проходящая через сеть VPC, аннотируется контекстом Kubernetes, которому принадлежал IP-адрес на момент выборки. Это помогает гарантировать, что контекст сохраняется даже после удаления пода:

• Кластер: Имя и расположение кластера.

Кластер: Имя и расположение кластера.

• Рабочая нагрузка: Имя и пространство имен пода, а также контроллер, которому принадлежит под, например Deployment, StatefulSet или DaemonSet.

Рабочая нагрузка: Имя и пространство имен пода, а также контроллер, которому принадлежит под, например Deployment, StatefulSet или DaemonSet.

• Имя сервиса: Сервис Kubernetes, который принял трафик.

Имя сервиса: Сервис Kubernetes, который принял трафик.

• Нода и зона: Стандартные поля VPC, включая виртуальную машину ноды и ее зону на обоих концах потока.

Нода и зона: Стандартные поля VPC, включая виртуальную машину ноды и ее зону на обоих концах потока.

Если вы зарегистрируете свои рабочие нагрузки GKE в App Hub, каждая запись также будет содержать метки уровня приложения (apphubSource и apphubDestination), которые определяют бизнес-приложение, среду и критичность каждой конечной точки. Это особенно полезно, когда микросервисы GKE взаимодействуют с зарегистрированными в App Hub ресурсами вне кластера, такими как сервисы Cloud Run.

Прежде чем начать

Обновите бакет логов до Observability Analytics (ранее Log Analytics): Flow Analyzer считывает данные только из обновленного бакета, обычно _Default.Примечание: Это обновление является необратимым.gcloud logging buckets update _Default \ --location=global \ --enable-analytics

Включите VPC Flow Logs на уровне организации: Одна конфигурация на уровне организации охватывает каждую подсеть в каждой сети VPC, включая будущие кластеры (требуется роль администратора управления сетями). Оставьте включенным параметр include-all-metadata, чтобы каждая запись содержала сведения о пространстве имен и поде. Чтобы сбалансировать детализацию и стоимость, вы можете добавить вспомогательную частоту выборки (--flow-sampling), интервал агрегации (--aggregation-interval) или выражение фильтра (--filter-expr) для просмотра только интересующего трафика.gcloud network-management vpc-flow-logs-configs create CONFIG_NAME \ --location=global \ --organization=ORGANIZATION_ID \ --metadata=include-all-metadata

Включите видимость внутри ноды (intranode visibility): В кластерах Autopilot она уже включена, но в кластерах Standard ее необходимо включить. Примечание: Включение этой функции перезапускает компоненты плоскости управления и нод и увеличивает нагрузку на каждую ноду, поэтому сначала протестируйте ее на непроизводственном кластере.gcloud container clusters update CLUSTER_NAME \ --location=LOCATION \ --enable-intra-node-visibility

Теперь вы готовы к работе.

Визуальный анализ трафика в Flow Analyzer

VPC Flow Logs записывают каждую запись в Cloud Logging, вы можете искать и запрашивать ее в Logs Explorer или Log Analytics. Для повседневной работы инструмент Flow Analyzer, являющийся частью Network Intelligence Center, преобразует те же записи в интерактивную диаграмму и таблицу, позволяя группировать и фильтровать трафик по кластеру, пространству имен, рабочей нагрузке, поду или сервису всего за несколько кликов.

В приведенных ниже пошаговых инструкциях используется Online Boutique, демонстрационное приложение на основе микросервисов с открытым исходным кодом, запущенное в кластере GKE Autopilot в регионе us-central1. Развертывание loadgenerator отправляет синтетический трафик покупателей на интерфейсный сервис frontend, который вызывает productcatalogservice, cartservice, currencyservice, recommendationservice, shippingservice, adservice и checkoutservice.

Сценарий 1: Превращение IP-адресов в имена рабочих нагрузокНезависимо от того, расследуете ли вы инцидент или оцениваете изменения в архитектуре, первый вопрос всегда звучит одинаково: какие конечные точки взаимодействуют друг с другом и каков объем этого взаимодействия?

Вместо отображения эфемерных пар IP-адресов метаданные GKE позволяют Flow Analyzer ответить на этот вопрос напрямую, используя имена рабочих нагрузок Kubernetes.

Шаги в Flow Analyzer:

• Откройте Network Intelligence Center > Flow Analyzer и установите временной диапазон равным последнему 1 часу.

Откройте Network Intelligence Center > Flow Analyzer и установите временной диапазон равным последнему 1 часу.

• В разделе Source и Destination установите параметр Organize flows by в значение GKE workload.

В разделе Source и Destination установите параметр Organize flows by в значение GKE workload.

• В панели фильтров добавьте фильтр GKE workload is known, чтобы отображался только трафик между подами.

В панели фильтров добавьте фильтр GKE workload is known, чтобы отображался только трафик между подами.

• Нажмите Run new query.

Нажмите Run new query.

Группировка трафика по рабочей нагрузке GKE-источника и рабочей нагрузке GKE-назначения во Flow Analyzer для построения карты зависимостей микросервисов без поиска по сырым IP-адресам.

Ключевые выводы: отсортированная по объему таблица представляет собой готовую карту зависимостей приложения: frontend обрабатывает входящие запросы от loadgenerator (представляющего пользовательский трафик), в то время как productcatalogservice отвечает на вызовы как от recommendationservice, так и от frontend. Поскольку в каждой строке вместо сырых IP-адресов отображаются имена рабочих нагрузок, любое неавторизованное или неожиданное взаимодействие между рабочими нагрузками сразу же становится очевидным.

Сценарий 2: Детальный анализ отдельного сервисаКогда сервис работает медленно или готовится к изменениям, вам нужно знать, кто зависит от него и насколько сильно.

Шаги в Flow Analyzer:

• Измените параметр Traffic aggregation на Client ↔ server (bidirectional), чтобы запросы и ответы между парой подсчитывались вместе.

Измените параметр Traffic aggregation на Client ↔ server (bidirectional), чтобы запросы и ответы между парой подсчитывались вместе.

• В разделе Server добавьте фильтр GKE workload = productcatalogservice.

В разделе Server добавьте фильтр GKE workload = productcatalogservice.

• Нажмите Run new query, а затем нажмите Details в верхней строке.

Нажмите Run new query, а затем нажмите Details в верхней строке.

Фильтрация по рабочей нагрузке Server GKE (productcatalogservice) с агрегацией Клиент ↔ сервер (двунаправленной) для просмотра доли вызывающих абонентов и шкалы времени «Детали».

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

Вариант 3: Найдите поды, которые общаются между зонами. В региональном кластере GKE интенсивные службы, попадающие в разные зоны, отправляют каждый запрос через границу зоны, что приводит к дополнительным расходам на передачу данных между зонами. Поскольку VPC Flow Logs фиксируют зону на обоих концах каждого потока, пары подов, создающие этот трафик, легко обнаружить.

Шаги в Flow Analyzer:

• Переключитесь с базовых фильтров на фильтры SQL, которые позволяют сравнивать два поля одного и того же потока.

Переключитесь с базовых фильтров на фильтры SQL, которые позволяют сравнивать два поля одного и того же потока.

• В поле WHERE введите src_gcp_zone <> dest_gcp_zone.

В поле WHERE введите src_gcp_zone <> dest_gcp_zone.

• Установите для параметра «Организовать потоки по» значения «Зона GCP источника», «Под GKE источника», «Зона GCP назначения» и «Под GKE назначения».

Установите для параметра «Организовать потоки по» значения «Зона GCP источника», «Под GKE источника», «Зона GCP назначения» и «Под GKE назначения».

• Нажмите «Запустить новый запрос».

Нажмите «Запустить новый запрос».

Использование SQL-фильтров с src_gcp_zone <> dest_gcp_zone и многоатрибутной группировкой для определения пар подов, создающих межзональный сетевой трафик.

Ключевые выводы: в таблице отображается межзональный трафик, ранжированный по объему, с указанием точных подов и зон на каждом конце. В нашем кластере основные потоки происходят между подом интерфейса в us-central1-b и подом currencyservice в us-central1-c, за которыми следуют пары checkoutservice, shippingservice и productcatalogservice. Чтобы продолжить исследование, нажмите «Исследовать в Log Analytics», чтобы открыть базовый SQL-запрос для дополнительной настройки, такой как добавление объединений или временных сегментов.

У GKE есть встроенное решение: установите для службы trafficDistribution: PreferSameZone (PreferClose в более старых версиях), чтобы отдавать предпочтение работоспособным конечным точкам в зоне вызывающего абонента, и убедитесь, что в каждой зоне достаточно реплик для обслуживания собственного трафика.

Что следует иметь в виду

• Трафик из пода в интернет: журналы потоков VPC Flow Logs не содержат аннотаций подов, поскольку агент маскарада заменяет IP-адрес пода на IP-адрес узла до того, как поток будет выбран для выборки. Сохранение внутренних пунктов назначения в списке без маскировки сохраняет имена подов для этих потоков, а если вы запустить ip-masq-agent с видимостью внутри узла, этот список также должен включать диапазоны IP-адресов узлов и подов кластера, чтобы избежать проблем с подключением.

Трафик из пода в интернет: журналы потоков VPC Flow Logs не содержат аннотаций подов, поскольку агент маскарада заменяет IP-адрес пода на IP-адрес узла до того, как поток будет выбран для выборки. Сохранение внутренних пунктов назначения в списке без маскировки сохраняет имена подов для этих потоков, а если вы запустить ip-masq-agent с видимостью внутри узла, этот список также должен включать диапазоны IP-адресов узлов и подов кластера, чтобы избежать проблем с подключением.

• Заблокированный трафик: трафик, заблокированный сетевой политикой, никогда не достигает сети VPC, поэтому для его исследования используйте ведение журнала NetworkPolicy.

Заблокированный трафик: трафик, заблокированный сетевой политикой, никогда не достигает сети VPC, поэтому для его исследования используйте ведение журнала NetworkPolicy.

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

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

Следующие шаги

Если в ваших кластерах уже включены журналы потоков VPC Flow Logs, обновление корзины _Default и открытие Flow Analyzer — это все, что нужно для воспроизведения трех описанных выше пошаговых руководств. Чтобы узнать больше, см. документацию:

• Использование журналов потоков VPC Flow Logs

Использование журналов потоков VPC Flow Logs

• Формат записей VPC Flow Logs для GKE

Формат записей VPC Flow Logs для GKE

• Анализ сетевого трафика с помощью Flow Analyzer

Анализ сетевого трафика с помощью Flow Analyzer

• Рекомендации по обеспечению сетевой наблюдаемости GKE

Рекомендации по обеспечению сетевой наблюдаемости GKE

• Устранение неполадок сетевой наблюдаемости GKE

Устранение неполадок сетевой наблюдаемости GKE

• Контейнеры и Kubernetes
• Сети
• GKE
• Разработчики и практики