В Kubernetes каждый под получает уникальный IP-адрес, но узлы кластера часто находятся в разных L2-сегментах сети. Динамическая маршрутизация решает задачу связи между подами на разных узлах. За эту связность отвечают CNI-плагины, которые управляют сетевыми интерфейсами и маршрутами. Они реализуют две основные модели: overlay-сети с инкапсуляцией трафика и маршрутизацию на уровне L3. От выбора модели и конкретного плагина зависят производительность, безопасность и сложность эксплуатации кластера.
Как работает динамическая маршрутизация между подами в Kubernetes
Kubernetes использует модель плоской сети, где каждый под виден другим подам напрямую по своему IP. Для реализации этой модели используется стандарт Container Network Interface. Когда kubelet создает новый под, он вызывает CNI-плагин, который настраивает сетевое пространство имен, виртуальные интерфейсы и правила маршрутизации. Плагин работает на каждом узле, обеспечивая согласованность сетевого состояния всего кластера.
Роль CNI-плагина: от манифеста пода до сетевого интерфейса
Процесс создания сетевого стека для пода состоит из пяти шагов. Сначала kubelet создает контейнер pause, который служит сетевым пространством имен. Затем он вызывает CNI-плагин, указанный в конфигурации /etc/cni/net.d, передавая ему параметры: идентификатор контейнера, путь к его сетевому пространству имен и идентификатор сети. Плагин создает виртуальную пару интерфейсов veth, один конец которой помещается в пространство имен контейнера, а другой подключается к мосту cni0 или аналогичному устройству на узле. Из предварительно выделенного пула назначается IP-адрес, который добавляется в таблицу маршрутизации узла или в общую базу данных overlay-сети. Например, плагин Calico в режиме BGP динамически анонсирует маршрут к подсети пода на всех узлах кластера.
Overlay vs. L3-маршрутизация: две парадигмы сетевой связности
Overlay-сети, такие как реализованные в Flannel с VXLAN, инкапсулируют исходный пакет от пода в UDP-пакет. Этот пакет передается между узлами через стандартные сетевые порты. Преимущество подхода в простоте развертывания: не требуется настройка физических коммутаторов и маршрутизаторов. Недостаток в снижении производительности из-за оверхеда на инкапсуляцию и сложности диагностики трафика. L3-маршрутизация, которую использует Calico в режиме BGP, работает иначе. Узлы Kubernetes становятся BGP-пирами и обмениваются маршрутами напрямую. Трафик между подами передается без инкапсуляции, что снижает нагрузку на CPU и уменьшает задержки. Однако этот подход требует настройки BGP на сетевом оборудовании или использования Route Reflector внутри кластера.
Сравнение CNI-плагинов: Calico, Cilium и Flannel для разных задач
Выбор CNI-плагина определяет архитектуру сети, возможности безопасности и производительность кластера. Flannel подходит для быстрого старта и простых окружений, Calico предлагает баланс производительности и гибкости для production, а Cilium использует технологию eBPF для расширенного контроля и мониторинга.
Flannel: максимальная простота для overlay-сетей
Flannel работает в режиме VXLAN по умолчанию. Его устанавливают одной командой kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml. Архитектура проста: на каждом узле запускается агент flanneld, который управляет подсетью для узла и настраивает маршрутизацию через VXLAN-туннель. Основное ограничение Flannel - базовые сетевые политики Kubernetes работают только при установке дополнительного компонента, например, Calico для политик. Производительность ниже из-за инкапсуляции, что критично для высоконагруженных приложений. Flannel идеален для development-окружений, homelab или простых production-кластеров, где приоритетом является скорость развертывания, а не тонкая настройка безопасности.
Calico: гибкость и производительность на уровне L3
Calico поддерживает оба режима работы: VXLAN для overlay и BGP для нативной маршрутизации. В режиме BGP каждый узел становится BGP-пиром и анонсирует маршруты к подсетям своих подов. Это исключает оверхед на инкапсуляцию. Calico предоставляет мощные сетевые политики, которые поддерживают селекторы по namespace, pod, портам и протоколам, а также правила для egress и ingress трафика. Политики реализованы через iptables или IPVS. Calico подходит для production-кластеров любого масштаба, где требуется детальный контроль трафика между микросервисами и соответствие требованиям безопасности. Для интеграции с физическими маршрутизаторами, такими как MikroTik или Cisco, можно настроить BGP-пиринг, что позволяет отказаться от ручного прописывания статических маршрутов. Подробнее об этом читайте в нашем руководстве по динамической маршрутизации BGP в Kubernetes с Calico.
Cilium: eBPF, безопасность и observability следующего поколения
Cilium заменяет традиционные механизмы iptables и IPVS на программы eBPF, которые выполняются непосредственно в ядре Linux. Это дает прирост производительности за счет снижения нагрузки на CPU и позволяет реализовывать политики безопасности на уровне HTTP, gRPC и других L7-протоколов. Встроенный инструмент Hubble визуализирует зависимости между сервисами и отслеживает сетевые потоки в реальном времени. Cilium эффективен для защиты от DDoS-атак и изоляции сервисов на уровне API. Его выбирают для высоконагруженных кластеров, сред с повышенными требованиями к безопасности и observability, а также для постепенной миграции к сервисной сетке. Например, политика Cilium может разрешить доступ к методу POST конкретного API только для подов с определенной меткой.
Готовая конфигурация: развертывание Calico с базовой отказоустойчивостью
Для установки Calico в кластер Kubernetes используйте официальный манифест. Эта конфигурация включает настройки для повышения отказоустойчивости и масштабирования.
Манифест установки и ключевые параметры настройки
Выполните команду для установки последней стабильной версии Calico:
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/custom-resources.yamlВ файле custom-resources.yaml настройте ключевые параметры. Укажите CIDR для пула IP-адресов подов, который не должен пересекаться с сетями узлов и сервисов Kubernetes:
spec:
calicoNetwork:
ipPools:
- blockSize: 26
cidr: 10.244.0.0/16
encapsulation: VXLANCrossSubnet
natOutgoing: Enabled
nodeSelector: all()Параметр encapsulation: VXLANCrossSubnet включает overlay-режим. Для использования BGP измените его на IPIPCrossSubnet или настройте BGP-пиры отдельно. После установки проверьте состояние подов:
kubectl get pods -n calico-systemВсе поды должны быть в состоянии Running.
Настройка компонентов Typha для масштабирования
Typha выступает прокси между API Kubernetes и множеством экземпляров calico-node. Это снижает нагрузку на etcd и kube-apiserver в больших кластерах. Для кластера с 10 и более узлами рекомендуется запустить 3 реплики Typha. Настройка выполняется через редактирование ресурса Installation:
kubectl patch installation default --type=merge -p '{"spec":{"typha":{"replicas":3}}}'Для обеспечения отказоустойчивости разнесите поды Typha по разным узлам с помощью Pod Anti-Affinity. Это гарантирует, что отказ одного узла не выведет из строя все экземпляры Typha.
Диагностика проблем сетевой связности в кластере
Сетевые проблемы в Kubernetes часто связаны с конфигурацией CNI, блокировкой портов или исчерпанием ресурсов. Алгоритм диагностики строится от проверки состояния компонентов к анализу сетевых маршрутов.
Чек-лист: от исчерпания IP до блокировки портов VXLAN
- Новые поды не получают IP. Причина: исчерпан пул IP-адресов в Calico или Flannel. Решение: расширить CIDR пула или добавить новый пул. В Calico проверьте статус блоков:
calicoctl ipam show. - Пинг работает только между подами на одном узле. Причина: заблокирован порт для overlay-сети. Для VXLAN это UDP-порт 8472, для Geneve - 6081. Решение: открыть порты в правилах межсетевого экрана на узлах и сетевом оборудовании.
- Прерывистая связность или потеря пакетов. Причина: неправильный MTU. В облачных провайдерах часто используется собственный overlay, что требует уменьшения MTU в конфигурации CNI. Решение: установить MTU на 50-100 байт меньше стандартного 1500, например, 1450 в настройках плагина.
- Узел в состоянии
NetworkPluginNotReady. Причина: ошибка загрузки образа CNI-плагина, недостаток прав или конфликт версий. Решение: проверить логи kubelet (journalctl -u kubelet) и логи DaemonSet CNI-плагина.
Для анализа производительности сетевого стека в разных средах оркестрации может быть полезно сравнение накладных расходов. Подробные тесты приведены в статье Производительность Docker vs Kubernetes vs LXC в 2026: объективные тесты CPU, памяти, сети и запуска приложений.
Использование Cilium Hubble для анализа потоков трафика
После установки Cilium Hubble предоставляет детальную observability. Запустите Hubble UI или используйте CLI для мониторинга трафика. Команда показывает все сетевые соединения в реальном времени:
hubble observeДля фильтрации только заблокированных пакетов сетевой политикой используйте:
hubble observe --verdict DROPPEDЭтот инструмент наглядно демонстрирует, как политики влияют на трафик, и помогает находить ошибки в правилах.
Оптимизация производительности и отказоустойчивости сети
Настройка сети Kubernetes для production требует планирования архитектуры, реализации политик безопасности и обеспечения отказоустойчивости компонентов управления.
Настройка сетевых политик (Network Policies) для изоляции
Примените политику «запретить по умолчанию» для каждого namespace. Это базовый принцип безопасности. Создайте манифест default-deny.yaml:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: my-app
spec:
podSelector: {}
policyTypes:
- IngressЗатем создайте разрешающую политику, которая разрешает трафик от фронтенда к бэкенду по порту 8080:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: my-app
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080Протестируйте политики в staging-среде перед применением в production. Для комплексной безопасности микросервисов рассмотрите стратегии, описанные в руководстве по SSL/TLS termination в Kubernetes: сравнение архитектур Ingress, Service Mesh и внешних балансировщиков.
Планирование сетевой архитектуры для масштабирования
Выделите CIDR для подов с запасом. Используйте подсеть /16 вместо /24, чтобы избежать нехватки адресов при росте кластера. Убедитесь, что выбранный CIDR не пересекается с сетями узлов, сервисов Kubernetes и корпоративной инфраструктуры. Для кластеров более 100 узлов при использовании Calico в режиме BGP настройте Route Reflectors. Это предотвращает необходимость поддержки full-mesh BGP-сессий между всеми узлами, что снижает нагрузку на контрольную плоскость. Разместите Route Reflectors на выделенных узлах управления с гарантированными ресурсами.
Для обеспечения отказоустойчивости разнесите управляющие поды CNI-плагина, такие как Typha или оператор Cilium, по разным узлам с помощью podAntiAffinity. Используйте PodDisruptionBudget для гарантии минимального количества работающих реплик во время плановых работ. Настройте мониторинг ключевых метрик сети: использование IP-пулов, состояние BGP-сессий, количество отброшенных пакетов политиками. Готовые шаблоны для мониторинга высоконагруженных систем можно найти в статье Наблюдаемость для высоконагруженных систем в 2026: ключевые метрики, алерты и дашборды.
При миграции сложных приложений в кластер с новой сетевой архитектурой важен продуманный план. Практические шаги и решения типичных проблем описаны в руководстве Переход от монолита к микросервисам в 2026 году: практический план для системных инженеров.
Для автоматизации работы с различными AI-моделями в процессе разработки и документирования инфраструктуры можно использовать агрегатор API AiTunnel, который предоставляет единый интерфейс для доступа к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях.