В этой статье будут рассмотрены инструменты наблюдения за сетевой инфраструктурой Kubernetes и основные составляющие Observability/Наблюдаемости – мониторинг, журналы событий, метрики, распределенная трассировка и оповещения. Обсудим, как эти инструменты могут помочь обеспечить надежную и эффективную работу кластеров Kubernetes и запущенных на них микросервисах, а также какие преимущества и недостатки существуют при использовании этих решений.
Эта статья для DevOps, Kubernetes administrators и SRE инженеров, которым важно и интересно разобраться в том, как устроена сетевая инфраструктура Kubernetes, какое взаимодействие происходит на уровне ядра Linux и различных приложений (Go, Java, Python и т.п.); изучить две обширные технологии eBPF и OpenTelemetry, активно продвигаемые CNCF сообществом. А главное при помощи каких инструментов можно упростить принятие решений инженерам при использовании Kubernetes в своих проектах и продуктах.
Статья будет разбита на три части, в связи с большим количеством информации. Первая часть посвящена обзору подходов для наблюдения за инфраструктурой Kubernetes. Во второй части будут разобраны инструменты, базирующиеся на eBPF. В третьей части инструменты, использующие OpenTelemetry.
Содержание
Введение
Обзор сетевой инфраструктуры Kubernetes
Пример микросервисной архитектуры в Kubernetes
eBPF и OpenTelemetry
Подробнее о eBPF
Применимость eBPF в Kubernetes
Подробнее об OpenTelemetry
Эволюция архитектуры инструментирования приложений
Применимость такого метода в Kubernetes
Существующие подходы к мониторингу и Наблюдаемости в Kubernetes
Распределенная трассировка
Service Meshes
Системы мониторинга на основе eBPF
Классы инструментов наблюдения за сетевой инфраструктуры Kubernetes
Заключение
Введение
Современные масштабируемые приложения строятся на распределенных системах, использующих облачную инфраструктуру (cloud-native, serverless) и микросервисные программные архитектуры. К сожалению, принося много преимуществ компаниям, внедряющим их, эти системы также усложняют процессы по обеспечению стабильного функционирования программных продуктов а также отладки возникающих проблем.
Существенную ценность приобретают инструменты, которые позволят инженерным командам понять и устранить проблемы и улучшить работоспособность разрабатываемых платформ и сервисов. Отсюда возникает новый термин / класс инструментов – Наблюдаемость, на английском Observability. Который позволяет находить ответы, на такие вопросы: "Почему это происходит?" / "что послужило причиной?" / "Как сделать так, чтобы эта проблема больше не возникала?" – то есть понять систему извне, не зная её внутреннего устройства.
Обзор сетевой инфраструктуры Kubernetes
Kubernetes - это система контейнерной (а в расширенном случае и виртуальных машин) оркестрации, цель которой - выстроить повторяемые процессы, связанные с автоматизацией развертывания, масштабирования и обновления контейнерных сред. Системы Kubernetes, называемые кластерами (cluster), обычно работают на нескольких потенциально разнородных хост-машинах (hosts, термин из ЦОДа), называемых узлами (Nodes). Под (pod, абстрактный объект Kubernetes, представляющий собой «обертку» для одного или группы контейнеров) - это атомарный блок, которым управляет Kubernetes. Типичная конструкция кластера: он содержит несколько подов, которые в свою очередь запущенны на узлах. Каждый pod изолирован от хост-машины с помощью пространств имен и cgroups. Контейнеры в одном и том же pod не изолированы друг от друга и используют общие пространства имен.
☝️ Контейнеры, выполняющие вспомогательные функции по отношению к основному контейнеру в pod, называются sidecars.
Kubernetes не имеет строго закрепленной реализации сетевой инфраструктуры – существует лишь небольшой набор правил для однозначной идентификации подов. Вместо этого организация сетей в k8s достигается через использование сетевых плагинов, благодаря которым можно реализовывать свои настраиваемые сети.
Существует две основные категории сетевых плагинов: kubenet, CNI.
Первая категория: плагин Kubenet (старое название, в документации он уже присутствует под названием noop, который распространяется вместе с Kubernetes и предоставляет минимальный набор функций для функционирования кластера Kubernetes.
Вторая категория: сетевые плагины, реализующие спецификацию Container Network Interface (CNI), называемые CNI плагины: Flannel, Weave, Calico, Cilium, Istio и другие. CNI плагины могут реализовывать сетевую модель с помощью совершенно разных подходов (Cilium – BPF+XDP для контейнеров, Linen/ovn-kubernetes – Open vSwitch'и для оверлейных сетей и SDN/OpenFlow сред и т.д.).
Kubernetes (k8s) можно настроить с одновременных использованием нескольких CNI плагинов – либо при помощи ручной установки, либо при помощи сторонних решений, как Multus.
Инфраструктура Kubernetes также включает в себя сервисы (Services) и сетевые политики (Policies), которые позволяют приложениям взаимодействовать друг с другом внутри кластера:
Services Kubernetes обеспечивают постоянный IP-адрес и DNS-имя для набора подов, которые выполняют определенную функцию или предоставляют доступ к конкретному приложению. Сервисы могут быть созданы для любого набора подов, даже если они находятся на разных узлах кластера или в разных пространствах имен. Сервисы Kubernetes также обеспечивают балансировку нагрузки между подами, что позволяет распределять сетевой трафик между несколькими экземплярами приложения.
Network Policies Kubernetes позволяют управлять трафиком внутри кластера, определяя правила доступа к сервисам и подам. Например, сетевая политика может быть создана для разрешения доступа только из определенного пространства имен или для определенных IP-адресов. Политики также могут использоваться для настройки маршрутизации, например, для перенаправления трафика на другие сервисы или кластеры.
Мониторинг, вопросы безопасности и устранение неполадок сетевой инфраструктуры Kubernetes могут стать головной болью из-за больших различий в реализациях CNI а также свободе выбора при дальнейшей настройке k8s. Чем более сложное архитектурное взаимодействие между сервисами и компонентами k8s пытается настроить инженер, тем более вероятно возникновение проблем, например, таких – как блокировка сетевого трафика или неожиданные простои при работе приложения. А в свою очередь отказ от использования сетевых политик и шифрования трафика для упрощения микросервисной архитектуры поставит под угрозу безопасность разрабатываемого продукта.
Если вы хотите получить подробную информации о сетевых компонентах и взаимосвязях Kubernetes, могу порекомендовать следующее руководство.
Интересные статьи
Интересные статьи
