Архитектура сетей Kubernetes: от сетевого стека Linux до Pod IPs и eBPF

Архитектура сетей Kubernetes: от сетевого стека Linux до Pod IPs и eBPF

Понимание сетевой модели Kubernetes является базовым требованием для проектирования отказоустойчивых кластеров и отладки инфраструктурных инцидентов. На верхнем уровне система предлагает простые абстракции — поды со своими IP-адресами и виртуальные сервисы для балансировки трафика. Однако под капотом этих абстракций находится многослойная комбинация примитивов ядра Linux, правил фильтрации пакетов и высокоуровневых плагинов плагина CNI (Container Network Interface).

Базовый контракт оркестратора требует, чтобы любой под мог взаимодействовать с любым другим подом в кластере по прямому IP-адресу без использования NAT (Network Address Translation). Канонические спецификации сетевой модели приведены в материале Kubernetes Services, Load Balancing, and Networking.

Фундамент Linux: пространства имен, виртуальные пары и мосты

Сетевая изоляция в контейнерных средах строится на механизме пространства имен сетевого стека ядра Linux (Network Namespaces). В отличие от контрольных групп (cgroups), отслеживающих утилизацию CPU и памяти, сетевой namespace предоставляет контейнеру собственное изолированное представление интерфейсов, таблиц маршрутизации, сокетов и правил сетевого экрана.

Связывание изолированного пространства имен пода с сетевым стеком физического или виртуального узла (Node) осуществляется через примитив veth (Virtual Ethernet Pair).

1. Создание пары виртуальных интерфейсов: Соединение работает как виртуальный кабель. Один конец пары (eth0) помещается внутрь network namespace пода, а второй конец (vethXXXX) остается в основном пространстве имен узла.
2. Коммутация через виртуальный мост: На хосте интерфейсы veth подключаются к виртуальному программному мосту (Linux Bridge) или обрабатываются напрямую датаплейном сетевого плагина.
3. Межузловая инкапсуляция: При отправке пакета на другой узел CNI-плагин упаковывает исходный IP-пакет в оверлейный туннель (например, VXLAN или Geneve) либо маршрутизирует его напрямую через BGP.

Назначением уникальных диапазонов подсетей (PodCIDR) для каждого узла занимается компонент kube-controller-manager, а вызов конкретного плагина CNI при запуске пода осуществляет агент kubelet.

Сервисы, виртуальные IP и эволюция датаплейна

Поды в Kubernetes являются эемерными (временными) объектами: при перезапусках и масштабировании их IP-адреса меняются. Для предоставления постоянного сетевого адреса используется абстракция Service со стабильным виртуальным адресом ClusterIP.

За обработку трафика к ClusterIP и его перенаправление на здоровые конечные точки (Pods) отвечает демонический процесс kube-proxy, работающий на каждом узле. Порядок сопоставления виртуальных IP подробно описан в спецификации Kubernetes Virtual IPs and Service Proxies.

Исторически технология реализации kube-proxy прошла три основных технологических поколения:

• Netfilter / iptables: Компонент генерирует цепочки правил в подсистеме Netfilter ядра. При поступлении пакета на ClusterIP правила последовательно выбирают случайно целевой под. Главный недостаток подхода — линейная сложность O(N). В кластерах с десятками тысяч сервисов обновление правил при изменении объектов EndpointSlice приводит к высокой нагрузке на CPU и задержкам.
• IPVS (IP Virtual Server): Подсистема ядра Linux, предназначенная для L4-балансировки. IPVS использует хэш-таблицы со сложностью поиска O(1), что кардинально снижает накладные расходы при частых обновлениях списков пода.
• eBPF (Extended Berkeley Packet Filter): Современный подход, отказывающийся от модели kube-proxy на базе iptables. Программы eBPF проверяются встроенным верификатором ядра, компилируются JIT в машинный код и подключаются прямо к сетевым сокетам и hooks (например, XDP или tc). Сетевые плагины вроде Cilium обрабатывают пакеты до их попадания в сетевой стек Linux.

Путь пакета: от приложения до целевого пода

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

1. Отправка из пода: Приложение выполняет системный вызов connect() и отправляет пакет в интерфейс eth0 своего пространства имен.
2. Переход на узел: Пакет проходит через виртуальный кабель veth и попадает в основной namespace узла.
3. Преобразование ClusterIP: Сетевой стек узла (или eBPF-программа) перехватывает пакет с адресом назначения ClusterIP. По данным из EndpointSlice выбирается конкретный IP-адрес конечного пода и выполняется трансляция адресов (DNAT).
4. Маршрутизация между узлами: Если выбранный под находится на соседнем узле, CNI-плагин инкапсулирует пакет в VXLAN-заголовок и отправляет его по физической сети через eth0 узла.
5. Прием и деинкапсуляция: Приемный узел снимает оверлейный заголовок, находит целевой veth по IP-адресу и доставляет пакет в сокет приемного процесса.

Системная отладка сетевых проблем в кластере

При возникновении сетевых аварий инженер должен изолировать слой сбоя, последовательно проверив DNS, сетевые политики NetworkPolicy, статус конечных точек и состояние узла.

Для диагностики рекомендуются следующие шаги и утилиты командной строки:

1. Проверка работы DNS-резолвера: Выполните команду dig +short service-name.namespace.svc.cluster.local внутри пода. Если адрес не резолвится, проблема на уровне CoreDNS.
2. Анализ активных endpoints: Проверьте наличие готовых подов командой kubectl get endpointslices -n <namespace>. Если список пуст, ни один под не прошёл Readiness Probe.
3. Проверка сетевых политик: Команда kubectl get networkpolicy -n <namespace> позволяет выявить правила, блокирующие трафик по портам или меткам.
4. Низкоуровневая диагностика сокетов: На самом узле используйте утилиты ss -tulpn для проверки открытых портов, traceroute для отслеживания хопов и openssl s_client для валидации TLS-соединений.

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