Сетевая маршрутизация в Docker и Kubernetes: практическое руководство по настройке, диагностике и выбору CNI

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

Это руководство систематизирует знания о сетевой маршрутизации от базовых Docker-сетей до сложных кластеров Kubernetes. Вы получите практические команды для настройки, диагностики и оптимизации, проверенные в production-средах. Материал поможет DevOps инженерам и системным администраторам строить надежную сетевую инфраструктуру для микросервисов.

Основы сетевой маршрутизации в Docker: от изоляции к коммуникации

Docker использует сетевые пространства имен Linux для изоляции контейнеров. Каждый контейнер получает собственное виртуальное сетевое устройство, которое подключается к драйверу сети на хосте. Стандартный драйвер bridge создает виртуальный коммутатор, позволяющий контейнерам на одном физическом сервере общаться между собой и с внешней сетью через NAT.

Bridge-сети работают только в пределах одного хоста. Для распределенных систем Docker предоставляет overlay-сети, которые инкапсулируют трафик в туннели VXLAN или аналогичные технологии. Это позволяет контейнерам на разных серверах видеть друг друга как находящихся в одной локальной сети.

Docker bridge сеть: стандартная изоляция и коммуникация

По умолчанию Docker создает сеть bridge с именем bridge. Контейнеры, запущенные без указания сети, автоматически подключаются к ней. Для создания пользовательской bridge-сети выполните команду:

docker network create --driver bridge my_bridge_network --subnet 172.20.0.0/16

Эта команда создает сеть с драйвером bridge и выделяет подсеть 172.20.0.0/16 для контейнеров. Чтобы подключить существующий контейнер к сети, используйте:

docker network connect my_bridge_network container_name

Просмотреть список всех сетей можно командой docker network ls. Для инспектирования конкретной сети, включая подключенные контейнеры и настройки подсети, выполните docker network inspect my_bridge_network.

Внутри контейнера проверьте сетевую конфигурацию:

docker exec -it container_name ip addr show
docker exec -it container_name ip route show

Эти команды покажут назначенные IP-адреса и таблицу маршрутизации. Bridge-сеть использует NAT для выхода во внешний мир через iptables правила на хосте.

Overlay сети Docker для распределенных кластеров

Overlay-сети требуют кластерного режима Docker Swarm или внешнего хранилища ключ-значение (Consul, etcd, ZooKeeper). Они инкапсулируют L2-фреймы в UDP-пакеты VXLAN, создавая виртуальную сеть поверх физической инфраструктуры.

Для создания overlay-сети в Docker Swarm выполните:

docker network create --driver overlay --attachable my_overlay_network

Ключ --attachable позволяет подключать standalone-контейнеры к сети, а не только сервисы Swarm. Overlay-сети добавляют заголовок VXLAN (обычно 50 байт), что увеличивает overhead трафика и может вызывать проблемы с MTU.

Проверьте MTU в контейнере:

docker exec -it container_name ip link show eth0

Если физическая сеть имеет MTU 1500, установите MTU overlay-сети на 1450 для компенсации инкапсуляции:

docker network create --driver overlay --opt com.docker.network.driver.mtu=1450 my_overlay_network

Производительность overlay-сетей на 10-15% ниже, чем у bridge-сетей из-за обработки заголовков и шифрования. Для критичных к задержкам приложений рассмотрите альтернативы вроде macvlan или ipvlan драйверов.

CNI в Kubernetes: как кластер управляет сетью контейнеров

Kubernetes делегирует управление сетью контейнеров внешним плагинам через Container Network Interface (CNI). Стандарт CNI определяет, как сетевое решение выделяет IP-адрес поду, настраивает маршруты и обеспечивает связность. В отличие от Docker, где сеть управляется демоном, в Kubernetes каждый узел запускает CNI-плагин как DaemonSet.

Сетевая модель Kubernetes предъявляет три требования: каждый pod получает уникальный IP-адрес, все pods могут общаться друг с другом без NAT, и все узлы могут общаться со всеми pods. Эти требования обеспечивают плоскую сетевую модель, где сервисы взаимодействуют напрямую по IP.

Компонент kube-proxy реализует абстракцию Service через iptables или IPVS правила, перенаправляя трафик на backend pods. Сервисы типа ClusterIP создают виртуальный IP внутри кластера, NodePort открывает порт на каждом узле, а LoadBalancer интегрируется с облачными провайдерами.

Архитектура CNI-плагинов: Calico, Flannel, Cilium

CNI-плагины различаются архитектурой, производительностью и функциональностью. Calico использует BGP для распространения маршрутов между узлами или инкапсуляцию IP-in-IP для туннелирования. Flannel применяет простую overlay-сеть на основе VXLAN или host-gateway. Cilium построен на eBPF, что позволяет обрабатывать трафик на уровне ядра с минимальными накладными расходами.

Плагин	Принцип работы	NetworkPolicy	Производительность	Сложность
Calico	BGP/IP-in-IP	Полная поддержка + расширения	Высокая	Средняя
Flannel	VXLAN/host-gateway	Только через kube-proxy	Средняя	Низкая
Cilium	eBPF	Полная поддержка + L7-политики	Очень высокая	Высокая

Calico подходит для большинства production-сред благодаря балансу функциональности и стабильности. Он поддерживает Network Policies для изоляции трафика и может работать в pure routing режиме без overlay. Cilium выбирают для высокопроизводительных сред, где требуется observability трафика на уровне L7 и минимальные задержки.

Flannel остается простейшим решением для тестовых кластеров или сред, где не нужны сложные сетевые политики. Для интеграции с существующей сетевой инфраструктурой через BGP используйте Calico. Для глубокого мониторинга и безопасности на уровне приложений - Cilium.

Практическая настройка сети Kubernetes с CNI

Установите Calico на bare-metal кластер, созданный через kubeadm. Сначала скачайте манифест:

curl https://docs.projectcalico.org/manifests/calico.yaml -O

Отредактируйте CIDR подсети для pods в соответствии с вашей конфигурацией:

# В манифесте найдите параметр CALICO_IPV4POOL_CIDR и установите:
            - name: CALICO_IPV4POOL_CIDR
              value: "10.244.0.0/16"

Примените манифест:

kubectl apply -f calico.yaml

Проверьте работоспособность:

kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get nodes -o wide

На каждом узле Calico создает интерфейс tunl0 для IP-in-IP туннелирования или использует физические интерфейсы для BGP. Проверьте маршруты на узле:

ip route show
ip link show tunl0

Для диагностики проблем с CNI проверьте логи DaemonSet:

kubectl logs -n kube-system daemonset/calico-node

Если pods не получают IP-адреса, убедитесь, что CNI-биндары правильно настроены в /etc/cni/net.d/ и что демон kubelet имеет к ним доступ.

Диагностика и отладка сетевых проблем: от контейнера до кластера

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

Создайте чек-лист для быстрого реагирования: доступность DNS, правильность маршрутов, открытость портов, отсутствие блокировок сетевыми политиками и корректность MTU. Для комплексного анализа сетевой безопасности в контейнерах изучите практическое руководство по сетевой безопасности контейнеров в 2026 году.

Инструменты и команды для анализа сетевого стека

Для диагностики внутри контейнера используйте стандартные сетевые утилиты. Проверьте доступность другого пода:

kubectl exec -it pod-name -- ping -c 3 10.244.1.5
kubectl exec -it pod-name -- nc -zv 10.244.1.5 8080

Изучите сетевые соединения:

kubectl exec -it pod-name -- netstat -tulpn
kubectl exec -it pod-name -- ss -tulpn

На уровне узла проверьте iptables правила, которые создают kube-proxy и CNI-плагины:

iptables -L -n -v | grep KUBE
iptables -L -n -v | grep calico

Для анализа трафика между узлами используйте tcpdump на интерфейсе overlay или физическом интерфейсе:

tcpdump -i eth0 -n port 8472  # Для VXLAN трафика Flannel
tcpdump -i tunl0 -n  # Для IP-in-IP трафика Calico

В Docker для инспектирования сети выполните:

docker network inspect network_name | jq '.[].Containers'
docker exec container_name cat /etc/resolv.conf

Эти команды покажут подключенные контейнеры и DNS-конфигурацию. Для глубокого понимания сетевой модели Kubernetes обратитесь к практическому гайду по сетям Kubernetes.

Разбор реальных кейсов: почему нет связи между pod'ами?

Кейс 1: Проблема с MTU в overlay-сетях. Симптомы: пакеты фрагментируются, TCP-соединения устанавливаются медленно или обрываются. Диагностика: проверьте MTU на интерфейсе пода и сравните с MTU физической сети. Решение: уменьшите MTU overlay-сети на 50-100 байт для компенсации инкапсуляции VXLAN или IP-in-IP.

Кейс 2: Блокировка трафика сетевыми политиками Calico. Симптомы: ping между подами в разных namespace не работает, хотя IP-адреса доступны. Диагностика: проверьте Applied Network Policies:

kubectl describe networkpolicy -n namespace-name

Решение: создайте политику, разрешающую трафик, или временно отключите все политики для тестирования базовой связности.

Кейс 3: Ошибки маршрутизации из-за конфликта подсетей. Симптомы: pods не могут связаться с внешними ресурсами или узлами в определенных подсетях. Диагностика: проверьте таблицу маршрутизации на узле:

ip route show table all

Решение: измените CIDR подсети для pods в конфигурации CNI, чтобы избежать пересечения с внутренними сетями компании. Перезапустите сетевой плагин после изменения.

Безопасность и оптимизация: сетевые политики и eBPF-ускорение

Сетевая безопасность в Kubernetes строится на модели zero-trust, где весь трафик блокируется по умолчанию, а разрешения задаются явно через Network Policies. Эти политики определяют, какие pods могут общаться между собой, на каких портах и по каким протоколам.

eBPF (extended Berkeley Packet Filter) революционизирует сетевую маршрутизацию, позволяя выполнять код в ядре Linux без модификации его исходного кода. Cilium использует eBPF для замены iptables и kube-proxy, что снижает задержки и потребление CPU на 30-50%.

Настройка Kubernetes сетевых политик с Calico и Cilium

Базовая политика «deny-all» блокирует весь входящий и исходящий трафик для pods в namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

После применения этой политики разрешите необходимые соединения. Пример политики, разрешающей доступ к порту 3306 только с определенных pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-mysql
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: mysql
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 3306

Calico расширяет стандартные Network Policies, добавляя возможности like правила для CIDR блоков, логирование отклоненного трафика и применение политик к интерфейсам узлов. Cilium поддерживает политики уровня L7 для HTTP, gRPC и Kafka, позволяя фильтровать трафик по пути URL или заголовкам.

Для выбора оптимального CNI-плагина с учетом требований безопасности изучите актуальное сравнение CNI-плагинов для Kubernetes в 2026 году.

Cilium eBPF Kubernetes: ускорение маршрутизации и наблюдаемость

Cilium заменяет цепочки iptables eBPF-программами, которые выполняются непосредственно в ядре. Это устраняет линейный поиск по правилам iptables и снижает задержки маршрутизации с 100-200 микросекунд до 10-20 микросекунд для локального трафика.

Установите Cilium с включенным eBPF-режимом для kube-proxy:

helm install cilium cilium/cilium --namespace kube-system \
  --set kubeProxyReplacement=strict \
  --set k8sServiceHost=API_SERVER_IP \
  --set k8sServicePort=API_SERVER_PORT

Инструмент Hubble предоставляет observability трафика в реальном времени:

kubectl exec -n kube-system -it ds/cilium -- hubble observe

Эта команда показывает потоковую информацию о соединениях между pods, включая протоколы, порты и вердикты политик. Hubble UI визуализирует сетевую карту зависимостей сервисов.

Для мониторинга производительности сравните метрики до и после перехода на Cilium:

kubectl top nodes
kubectl top pods -n kube-system -l k8s-app=cilium

В production-средах с тысячами pods eBPF снижает потребление CPU на обработку сетевого трафика на 40-60% по сравнению с iptables-based решениями.

Миграция и интеграция: от Docker Compose сетей к продакшн-кластеру

Миграция сетевой конфигурации из Docker Compose в Kubernetes требует пересмотра архитектуры. В Docker Compose сети изолируют группы сервисов, в Kubernetes эту роль выполняют комбинации Namespace и NetworkPolicy. DNS-имена сервисов в Docker Compose преобразуются в Kubernetes Service с типом ClusterIP.

Инструмент Kompose автоматически конвертирует docker-compose.yml в манифесты Kubernetes, но часто требует ручной доработки сетевых настроек. Стратегия lift-and-shift подходит для простых приложений, но для production-сред рекомендуется рефакторинг с учетом возможностей Kubernetes.

Адаптация docker-compose.yml для Kubernetes

Рассмотрим пример docker-compose.yml с двумя сервисами и пользовательской сетью:

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    networks:
      - app-network
  api:
    image: myapp/api:latest
    networks:
      - app-network
networks:
  app-network:
    driver: bridge

В Kubernetes создайте Deployment для каждого сервиса и общий Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

Сеть app-network заменяется тем, что pods находятся в одном namespace и могут общаться напрямую по IP. Для изоляции добавьте NetworkPolicy, ограничивающую трафик только между этими сервисами.

Внешние сетевые ресурсы (базы данных, кэши, очереди) интегрируйте через ExternalName Service или Endpoints. Для комплексного подхода к сетевым технологиям в современных средах изучите полное руководство по сетевому администрированию 2026.

Для оптимизации Docker-сред в production обратитесь к продвинутому гайду по Docker в 2026 году.

При развертывании кластеров Kubernetes рассмотрите использование облачной инфраструктуры, например, Timeweb Cloud, который предоставляет управляемый Kubernetes и гибкие сетевые настройки.