Сеть в Kubernetes: от TCP/IP до service mesh

Ещё до запуска первого контейнера его сетевая «реальность» полностью определяется внутри ядра Linux. Понимание того, как Linux обрабатывает пакеты, интерфейсы и правила, критически важно для диагностики проблем на любом уровне стека. Эти основы являются строительными блоками как для контейнерных сред выполнения (container runtimes), так и для Kubernetes.

Самой базовой сетевой конструкцией в Linux является сетевой интерфейс (network interface) — программное представление точки подключения к сети. Это может быть физическое устройство, например сетевая карта (eth0), или чисто виртуальное, например интерфейс обратной петли (lo). Особое место среди виртуальных интерфейсов занимает мостовой интерфейс (bridge interface). Linux-мост работает как виртуальный коммутатор второго уровня (Layer 2), способный объединять несколько сетевых интерфейсов. Когда пакет от подключённого интерфейса приходит на мост, тот проверяет целевой MAC-адрес и перенаправляет пакет на нужный интерфейс того же хоста. Именно этот механизм позволяет контейнерам на одном хосте общаться между собой.

Когда пакет приходит на интерфейс, он передаётся ядру и проходит обработку в рамках фреймворка Netfilter. Netfilter предоставляет серию «хуков» (hooks) в пути обработки пакетов ядром, где другие программы могут регистрироваться для проверки и модификации пакетов. Наиболее известный инструмент для управления этими хуками — iptables, классическая утилита брандмауэра пространства пользователя. С помощью iptables можно создавать правила, проверяемые для каждого пакета: разрешить (ACCEPT), отбросить (DROP) или модифицировать его (например, с помощью трансляции сетевых адресов — NAT). Рядом с Netfilter работает conntrack — система, отслеживающая все сетевые соединения. Это позволяет ядру распознавать пакеты, принадлежащие уже установленным соединениям, что является основой для stateful-брандмауэров.

Помимо базовой таблицы маршрутизации ядра, для обработки более сложных потоков трафика появился ряд технологий. После iptables следующим шагом стал IPVS (IP Virtual Server). Созданный для высокопроизводительной балансировки нагрузки, IPVS использует более эффективные хэш-таблицы внутри ядра вместо последовательных списков правил iptables, что делает его предпочтительным выбором для окружений с большим количеством сервисов.

Последней эволюцией стал eBPF (extended Berkeley Packet Filter), принципиально изменивший подход к делу: ядро Linux само по себе стало программируемым. Традиционные инструменты вроде iptables обладают врождёнными ограничениями в масштабируемых динамических средах: iptables опирается на длинные последовательные цепочки правил, и при росте числа сервисов и политик обход этих цепочек для каждого пакета создаёт значительную нагрузку на CPU и увеличивает задержки. eBPF обходит эту проблему, позволяя небольшим, высокоэффективным и изолированным программам подключаться непосредственно к специфическим хукам внутри ядра — например, в момент получения пакета сетевым драйвером. Архитектура eBPF обеспечивает безопасность через строгий верификатор (verifier), анализирующий программу перед загрузкой, а JIT-компилятор (Just-In-Time compiler) преобразует байткод eBPF в нативный машинный код для максимальной скорости выполнения. Возможности программирования распространяются за пределы сети: подключаясь к точкам трассировки и системным вызовам, eBPF служит основой для продвинутых инструментов безопасности и наблюдаемости, становясь фундаментальной технологией для следующего поколения облачной инфраструктуры.

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

Прежде чем разобраться, как контейнеры общаются между собой, нужно чётко понять, что такое контейнер и какие механизмы ядра обеспечивают его изоляцию. В отличие от гипервизора (hypervisor), создающего полноценную виртуальную машину (VM) с собственной гостевой операционной системой, контейнер — куда более лёгкая конструкция. По сути, это изолированный процесс (или группа процессов), работающий непосредственно на ядре Linux хоста. Такой подход исключает накладные расходы на загрузку отдельной ОС, благодаря чему контейнеры создаются мгновенно и экономно расходуют ресурсы.

Эта мощная изоляция достигается прежде всего благодаря двум возможностям ядра Linux: контрольным группам (control groups, cgroups) и пространствам имён (namespaces). Cgroups — это учётчики ресурсов: они ограничивают потребление CPU, памяти и операций ввода-вывода контейнером. Пространства имён — архитекторы изоляции: они разделяют ресурсы ядра так, что контейнер имеет собственный изолированный вид системы. Особенно важно для нашей темы сетевое пространство имён (network namespace), которое предоставляет контейнеру полностью независимый сетевой стек: собственный набор сетевых интерфейсов, IP-адресов, таблиц маршрутизации и правил брандмауэра.

На этой основе строятся практические реализации вроде сетевой модели Docker. При установке Docker создаёт на хосте виртуальный мост docker0. При запуске контейнера Docker создаёт пару виртуальных Ethernet-интерфейсов (veth-пара): один конец помещается внутрь нового сетевого пространства имён контейнера (как eth0), другой подключается к мосту docker0. Это позволяет контейнерам на одном хосте общаться между собой. Для связи контейнеров на разных хостах применяется оверлейная сеть (overlay networking): трафик контейнера инкапсулируется в пакет, понятный хостовой сети (с использованием протокола, например, VXLAN), и все контейнеры как будто находятся в одной плоской сети.

Чтобы каждая среда выполнения контейнеров не изобретала велосипед заново, сообщество разработало спецификацию CNI (Container Network Interface). CNI — простой стандарт, разделяющий среду выполнения контейнеров (containerd, CRI-O) и реализацию сети. Среда выполнения отвечает лишь за создание сетевого пространства имён и последующий вызов CNI-плагина, который выполняет фактическую работу по настройке сети: создаёт интерфейсы, назначает IP-адреса. Эта подключаемая архитектура является краеугольным камнем сетевой модели Kubernetes.

Kubernetes выводит сеть контейнеров на новый уровень, устанавливая чёткую, но гибкую сетевую модель. Она строится на нескольких фундаментальных принципах: каждый Pod (группа из одного или нескольких контейнеров) получает собственный уникальный IP-адрес в масштабах всего кластера, и любые Pod-ы могут напрямую общаться между собой без трансляции сетевых адресов (NAT). Это создаёт чистое плоское сетевое пространство, ведущее себя подобно традиционной локальной сети.

Для реализации этого пространство IP-адресов кластера делится на части. kube-controller-manager отвечает за назначение каждому узлу (Node) уникального диапазона IP-адресов — блока podCIDR. На каждом узле kubelet выступает в роли локального агента Kubernetes. Когда новый Pod планируется к запуску, kubelet вызывает настроенный CNI-плагин для подключения Pod-а к сети кластера. Сила этой модели — в её подключаемости. Можно выбирать из десятков популярных CNI-плагинов: Flannel — простой вариант, создающий оверлейную сеть; Calico — использует протокол маршрутизации BGP для высокопроизводительной работы без оверлея; Cilium — задействует eBPF для эффективной работы сети, наблюдаемости и безопасности.

Ключевым компонентом для обнаружения сервисов является kube-proxy — демон, работающий на каждом узле. Его задача — реализовывать абстракцию Service в Kubernetes. При создании сервиса ему назначается стабильный виртуальный IP-адрес (ClusterIP). Kube-proxy перехватывает трафик на этот ClusterIP и балансирует его между здоровыми Pod-бэкендами. Он работает в нескольких режимах: по умолчанию используется режим iptables. Для крупных кластеров предпочтительным часто считается режим ipvs, использующий более эффективные хэш-таблицы.

Несмотря на открытость коммуникаций по умолчанию, NetworkPolicy позволяет задавать правила брандмауэра для Pod-ов на уровне IP-адресов или портов. Эти политики применяются CNI-плагином, давая возможность создавать детализированные правила входящего и исходящего трафика. Наконец, ни одна современная сеть не обходится без DNS. Kubernetes предоставляет надёжный DNS-сервис с поддержкой кластера (как правило, CoreDNS), позволяющий Pod-ам находить друг друга по предсказуемым именам вместо эфемерных IP-адресов. Kubernetes также полностью поддерживает двойной стек IPv4/IPv6 (dual-stack), позволяя Pod-ам и сервисам получать оба типа адресов одновременно.

IP-адреса Pod-ов непостоянны. Для построения надёжных приложений Kubernetes предоставляет несколько мощных сетевых абстракций поверх базовой сети Pod-ов.

Основная абстракция — Service — предоставляет единую стабильную точку доступа к группе Pod-ов. Kubernetes отслеживает IP-адреса Pod-ов, обслуживающих сервис, с помощью EndpointSlices — масштабируемой замены оригинального объекта Endpoints. Существует несколько типов сервисов:

Для stateful-приложений вроде баз данных ресурс StatefulSet предоставляет Pod-ам стабильные уникальные сетевые идентификаторы (например, db-0.my-db-service), сохраняющиеся даже при перепланировании Pod-а.

Сервисы работают на уровне Layer 4 (TCP/UDP). Для управления внешним доступом на уровне Layer 7 (HTTP/HTTPS) Kubernetes предоставляет Ingress. Ресурс Ingress позволяет задавать правила маршрутизации внешнего HTTP-трафика к внутренним сервисам на основе имени хоста или URL-пути. Ingress-контроллер — это движок, воплощающий правила в жизнь: прокси внутри кластера, отслеживающий ресурсы Ingress и настраивающий себя для их применения.

Наконец, для самых требовательных микросервисных архитектур service mesh вроде Istio или Linkerd предлагает ещё более высокий уровень абстракции. Service mesh работает, внедряя лёгкий прокси-«sidecar» рядом с каждым контейнером приложения. Эти прокси образуют сеть, обеспечивающую продвинутые возможности: mTLS для безопасности, гибкое управление трафиком (канареечные релизы, A/B-тестирование) и глубокую наблюдаемость — без каких-либо изменений в коде приложения.

Надёжная система безопасности в Kubernetes выходит далеко за рамки одного NetworkPolicy. Она требует стратегии глубокоэшелонированной защиты (defense-in-depth), охватывающей всю систему.

Защита Control Plane: это первоочередная задача. API-сервер Kubernetes — мозг кластера, и несанкционированный доступ к нему катастрофичен. Лучшие практики включают отключение анонимного доступа, использование строгой аутентификации и применение принципа минимальных привилегий через детализированные правила RBAC (Role-Based Access Control).

Безопасность на уровне рабочих нагрузок: защита должна распространяться и на сами Pod-ы. Pod Security Admission (PSA) позволяет применять стандарты безопасности на уровне пространства имён. Через securityContext в спецификации Pod-а можно запретить опасные операции, например запуск от имени root или повышение привилегий, что существенно ограничивает последствия компрометации контейнера.

Взаимодействие в модели нулевого доверия с mTLS: в сети с нулевым доверием (zero-trust) доверие никогда не предполагается. Service mesh может принудительно применять взаимный TLS (mTLS) в масштабах всего кластера, автоматически шифруя весь трафик между сервисами и проверяя идентичность рабочих нагрузок с помощью сертификатов — без каких-либо изменений в коде приложений.

Безопасность во время выполнения и обнаружение угроз: последний рубеж — обнаружение угроз в реальном времени. Инструменты runtime security вроде Falco используют eBPF для мониторинга системных вызовов ядра. Они способны обнаруживать и оповещать об аномальном сетевом поведении — например, когда Pod неожиданно устанавливает исходящее соединение с незнакомым IP-адресом, что может указывать на взлом.

По мере роста Kubernetes стали очевидны ограничения оригинального Ingress API: он слабо специфицирован, что приводит к несовместимым реализациям, и недостаточно выразителен для сложной маршрутизации трафика. Для решения этих проблем сообщество Kubernetes разработало Gateway API — современный, стандартизированный и высокорасширяемый преемник, обеспечивающий большую гибкость, безопасность и разделение ответственности.

Сила Gateway API — в его ролевом дизайне (role-oriented design), разделяющем зоны ответственности:

Это разделение даёт важное преимущество: разработчик приложения может безопасно управлять правилами маршрутизации для своего сервиса, не имея возможности изменить общий шлюз. Gateway API также вводит такие возможности, как безопасная маршрутизация между пространствами имён (cross-namespace routing), и стандартизирует сложные паттерны управления трафиком: разделение трафика (traffic splitting) и маршрутизацию по заголовкам (header-based routing), создавая прочный фундамент для современных сетей Kubernetes.

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

Федерация service mesh: популярный подход, при котором service mesh вроде Istio или Linkerd настраивается для охвата нескольких кластеров. Устанавливая единый корень доверия, они создают объединённую service mesh, в которой Pod в кластере A может обнаружить и безопасно подключиться к сервису в кластере B так, будто тот находится локально.

Сетевое подключение на уровне сети: такие инструменты, как Submariner, работают на более низком уровне (L3/L4), создавая плоскую сеть между кластерами. Они устанавливают зашифрованные туннели между шлюзовыми узлами каждого кластера, объединяя сети Pod-ов и сервисов так, что любой Pod может напрямую обратиться к любому другому по его IP.

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

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