Сети в Kubernetes: практический гайд по CNI, Pod Network и Service Network для DevOps

Сетевая модель Kubernetes часто вызывает вопросы даже у опытных инженеров. Она отличается от привычных Docker-сетей и требует понимания нескольких абстракций: Pod Network, Container Network Interface (CNI) и Service Network. Этот гайд объясняет принципы работы каждой из них, дает практические инструкции для настройки и диагностики, а также помогает выбрать CNI-плагин для ваших задач. Вы научитесь правильно публиковать сервисы, строить отказоустойчивую инфраструктуру и быстро устранять типичные проблемы.

Основы сетевой модели Kubernetes: почему «каждому Pod свой IP»?

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

Модель сетей Docker, где контейнеры получают адреса внутри bridge-сети узла, не подходит для оркестрации. Она создает сложности с маршрутизацией между узлами и требует дополнительных настроек. Kubernetes решает эту проблему через две ключевые абстракции: Pod Network и Service Network. Pod Network обеспечивает связь на уровне контейнеров внутри Podа и между Podами. Service Network предоставляет стабильную конечную точку для доступа к группе динамически меняющихся Podов.

Pod Network: как контейнеры внутри Pod общаются и получают свой IP

Pod - минимальная единица работы в Kubernetes. Он может содержать один или несколько контейнеров, которые совместно используют сетевые ресурсы. При создании Podа Kubernetes через CNI-плагин назначает ему уникальный IP адрес из пула кластера. Этот адрес принадлежит Podу, а не отдельным контейнерам внутри него.

Контейнеры внутри одного Podа общаются через локальную сетевую область видимости. Они видят друг друга по именам, указанным в манифесте, и могут использовать локальные порты. За организацию этой сети отвечает специальный инфраструктурный контейнер, часто называемый pause-контейнером. Он создает виртуальный сетевой интерфейс, который затем используется всеми контейнеры приложения.

Проверить сетевые интерфейсы Podа можно командой kubectl exec <pod-name> -- ip addr. Вы увидите основной интерфейс, например eth0, с IP адресом Podа. Контейнеры приложения будут иметь свои интерфейсы внутри этого пространства.

Service Network: абстракция для стабильного доступа к приложениям

IP адреса Podов нестабильны. Podы создаются, удаляются, перемещаются между узлами. Service решает эту проблему, предоставляя постоянную точку доступа. Это абстракция, которая определяет логическую группу Podов и политику доступа к ним.

Service получает фиксированный IP адрес (ClusterIP) внутри кластера, который не меняется. Kubernetes автоматически создает объект Endpoints, который динамически отслеживает IP адресы всех Podов, соответствующих селекторам Service. Когда Podы меняются, Endpoints обновляется, но ClusterIP Service остается неизменным.

Внутренняя реализация Service основана на kube-proxy. Этот компонент на каждом узле создает правила в iptables или ipvs, которые перенаправляют трафик с ClusterIP Service на реальные IP адреса Podов из Endpoints. Так клиент внутри кластера, обращающийся к имени Service, всегда попадает на рабочий Pod.

Container Network Interface (CNI): движок Pod Network

Container Network Interface - стандарт, который отделяет оркестратор от конкретной реализации сети. Kubernetes не управляет сетью напрямую. Когда kubelet создает Pod, он вызывает CNI-плагин, который выполняет всю низкоуровневую работу.

CNI-плагин отвечает за три основные задачи. Он выделяет Podу IP адрес из заданного пула. Подключает Pod к сети кластера, создавая необходимые интерфейсы и маршруты. Настраивает маршрутизацию, чтобы трафик мог достигать Podа из других узлов и обратно. Формат конфигурации CNI - JSON файлы, которые хранятся в директории /etc/cni/net.d/ на каждом узле.

Как работает CNI-плагин: от вызова kubelet до IP в Pod

Процесс начинается при создании Podа. Kubelet, запущенный на узле, получает инструкцию из API сервера. Он вызывает CNI-плагин через специальный исполняемый файл, передавая ему конфигурацию и данные Podа (например, его идентификатор). Плагин выполняет свою логику: резервирует IP, создает сетевой интерфейс внутри Podа, обновляет маршруты на узле. Затем возвращает результат kubelet, который завершает создание Podа.

Если процесс fails, Pod останется в состоянии без IP адреса. Для диагностики нужно проверить логи kubelet: journalctl -u kubelet. Часто там можно найти ошибки CNI плагина, например, проблемы с выделением IP из пула или недоступность сетевых ресурсов.

Базовая настройка CNI: конфигурационный файл и его параметры

Минимальный конфигурационный файл для простого bridge плагина выглядит так:

{
  "cniVersion": "0.4.0",
  "name": "mynet",
  "type": "bridge",
  "bridge": "cni0",
  "isDefaultGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/16",
    "rangeStart": "10.244.1.0",
    "rangeEnd": "10.244.1.255",
    "gateway": "10.244.0.1"
  }
}

Параметр type указывает имя CNI плагина (например, bridge, calico, flannel). Параметр ipam определяет метод управления IP адресами. Host-local - простой вариант, который выделяет адреса из заданной подсети для каждого узла. Файлы конфигурации применяются автоматически при запуске kubelet. Их можно просмотреть для проверки текущей сетевой модели кластера.

Практическое сравнение CNI-плагинов: Calico, Cilium, Flannel и другие

Выбор CNI плагина определяет возможности сети кластера: безопасность, производительность, сложность управления. Для разных задач оптимальны разные решения. Таблица ниже дает краткое сравнение.

Для небольшого кластера для обучения или тестов Flannel - самый быстрый путь к рабочей сети. Для production среды с требованиями к безопасности и масштабируемости выбирайте Calico. Если нужны глубокие возможности мониторинга, фильтрация трафика на уровне HTTP методов и интеграция с service mesh, Cilium будет оптимальным выбором. Все плагины поддерживают текущие версии Kubernetes (1.28+). Актуальное сравнение CNI-плагинов для Kubernetes в 2026 году с детальным анализом архитектуры и производительности вы найдете в отдельном руководстве на admin-wiki.ru.

Calico: сетевые политики и производительность на уровне BGP

Calico может работать в двух режимах. Underlay режим использует протокол BGP для прямого объявления маршрутов Podов в физическую сеть. Это дает максимальную производительность, но требует поддержки BGP от сетевого оборудования. Overlay режим применяет IP-in-IP или VXLAN туннелирование для создания виртуальной сети между узлами, что подходит для облачных сред.

Calico предоставляет полную реализацию Kubernetes NetworkPolicy. Вы можете детально контролировать трафик между Podами, namespace и внешним миром. Пример политики, запрещающей все входящие соединения кроме порта 80 из определенного namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-only-from-monitoring
spec:
  podSelector:
    matchLabels:
      app: webapp
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 80

Для интеграции с корпоративной сетевой инфраструктурой через BGP существует специальное руководство по динамической маршрутизации в Kubernetes.

Cilium: eBPF, L7-политики и интеграция с service mesh

Cilium использует технологию eBPF для реализации сетевых функций непосредственно в ядре Linux. Это заменяет традиционные механизмы iptables и обеспечивает высокую производительность даже при большом количестве сетевых правил.

Помимо стандартных NetworkPolicy на уровне IP и портов (L3-L4), Cilium позволяет задавать политики на уровне HTTP методов, путей и заголовков (L7). Например, можно разрешить только GET запросы к определенному API endpoint. Cilium также предоставляет детальные метрики сетевого трафика, которые можно интегрировать с Prometheus для мониторинга.

Flannel: простота и надежность для старта и тестовых сред

Flannel использует overlay сеть на основе VXLAN. Он создает виртуальную сетевую область на каждом узле и соединяет их туннелями. Конфигурация минимальна: после установки плагин автоматически выделяет подсеть для каждого узла и управляет маршрутизацией.

Flannel не имеет собственной реализации NetworkPolicy. Для использования политик безопасности необходимо установить Calico как backend для Flannel. Это добавляет сложность, но сохраняет простоту базовой сетевой модели. Flannel идеально подходит для быстрого развертывания кластера, например, с kubeadm, когда основная цель - получить рабочую сеть без глубокой настройки.

Service в Kubernetes: типы, настройка и внутренняя работа

Service - основной механизм для доступа к приложениям в кластере. Kubernetes поддерживает несколько типов Service, каждый решает конкретную задачу.

ClusterIP: сервис для внутреннего взаимодействия Podов

ClusterIP - стандартный тип Service. Он создает виртуальный IP адрес, доступный только внутри кластера. Пример манифеста:

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

DNS сервер кластера, обычно CoreDNS, автоматически создает запись для этого Service. Podы могут обращаться к нему по имени backend-service или полному DNS имени backend-service.default.svc.cluster.local. Проверить работу можно запуском временного Podа и выполнением команды kubectl exec -it test-pod -- curl http://backend-service.

NodePort и LoadBalancer: публикация сервисов для внешнего мира

NodePort открывает фиксированный порт (в диапазоне 30000-32767) на каждом узле кластера. Трафик на этот порт любого узла перенаправляется к соответствующему Service и далее к Podам.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: NodePort
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080

NodePort удобен для разработки и тестов, но в production его использование требует внимания к безопасности, поскольку порт открыт на всех узлах.

LoadBalancer тип интегрируется с облачным провайдером. После создания такого Service облачная платформа автоматически развертывает внешний балансировщик нагрузки и назначает ему публичный IP адрес. Конфигурация полностью управляется Kubernetes.

Как kube-proxy направляет трафик: iptables vs ipvs

Kube-proxy реализует механизм перенаправления трафика от Service к Podам. Он работает в двух основных режимах: iptables и ipvs.

Режим iptables использует правила firewall для маршрутизации. Это стандартный и надежный метод, но при большом количестве Service (тысячи) производительность может снижаться из-за линейного поиска правил.

Режим ipvs использует механизм виртуальных серверов ядра Linux. Он обеспечивает лучшую производительность в крупных кластерах и поддерживает более сложные алгоритмы балансировки (round-robin, least-connection). Проверить текущий режим можно командой kubectl get pods -n kube-system -l k8s-app=kube-proxy и просмотром логов. Для просмотра созданных правил в режиме iptables используйте iptables -L -t nat, для ipvs - ipvsadm -L.

Диагностика и решение типичных сетевых проблем в Kubernetes

Сетевые проблемы в Kubernetes часто имеют системный характер. Методика диагностики должна двигаться от внешнего клиента внутрь кластера: Ingress -> Service -> Endpoints -> Pod Network. Следующие шаги помогут локализовать проблему.

Pod не может связаться с Pod: проверка NetworkPolicy и маршрутов

Если один Pod не может связаться с другим, выполните последовательность проверок.

1. Убедитесь, что Podы имеют IP адреса и находятся в состоянии Running: kubectl get pod -o wide.
2. Проверьте наличие NetworkPolicy, которые могут блокировать трафик: kubectl get networkpolicy --all-namespaces.
3. Убедитесь в правильности маршрутов на узлах, где работают Podы: ip route show. Маршрут к подсети другого узла должен существовать.
4. Проведите тест связи напрямую: kubectl exec -it pod-a -- ping <IP-pod-b> или curl.

Частая причина - слишком строгая NetworkPolicy, запрещающая весь ingress трафик. Также проблема может быть в неправильной конфигурации CNI плагина, который не настроил маршруты между узлами.

Service не работает: проверка Endpoints, kube-proxy и DNS

Когда внешний или внутренний клиент не может достучаться к приложению через Service, диагностику начинайте с Endpoints.

1. Убедитесь, что Service имеет активные Endpoints: kubectl describe svc <service-name>. В секции Endpoints должны быть IP адресы Podов.
2. Если Endpoints пустые, проверьте селекторы в манифесте Service. Они должны соответствовать labels Podов, которые вы хотите включить.
3. Проверьте работу kube-proxy. Убедитесь, что его Podы работают в namespace kube-system. Проверьте логи: kubectl logs -n kube-system <kube-proxy-pod>.
4. Тестируйте DNS резолвинг внутри кластера. Запустите временный Pod и выполните nslookup <service-name>.

Проблемы с DNS часто возникают при сбоях CoreDNS или неправильной конфигурации сети Podа, которая блокирует DNS трафик.

Проблемы с CNI: Pod без IP адреса

Симптом - Pod остается в состоянии Pending или ContainerCreating, а его IP адрес не назначается. Диагностика требует проверки нескольких уровней.

1. Анализируйте логи kubelet на узле, где должен запуститься Pod: journalctl -u kubelet --since "5 minutes ago". Часто там есть ошибки вызова CNI плагина.
2. Проверьте конфигурацию CNI плагина: cat /etc/cni/net.d/*.conf. Убедитесь в корректности JSON и доступности указанных сетевых ресурсов.
3. Убедитесь, что пул IP адресов не исчерпан. Для плагинов с host-local проверьте файлы выделения на каждом узле.
4. Проверьте, что необходимые сетевые интерфейсы (bridge, vxlan) созданы и работают: ip link show.

Для Calico типичная ошибка - невозможность установить соединение с Typha (центральным сервисом) при использовании больших кластеров. Для Flannel - проблемы с созданием VXLAN туннеля между узлами из-за блокировки портов firewall.

Архитектура сетей для production: Ingress, отказоустойчивость и безопасность

Production кластер требует планирования сетевой архитектуры. Ключевые компоненты: Ingress-контроллеры для маршрутизации внешнего трафика, NetworkPolicy для безопасности и стратегии отказоустойчивости для распределения нагрузки.

Ingress-контроллеры: маршрутизация HTTP/HTTPS трафика в кластер

Ingress ресурс определяет правила маршрутизации внешнего HTTP/HTTPS трафика к Service внутри кластера. Он позволяет маршрутизировать по доменному имени, пути URL и управлять TLS терминацией. Ingress-контроллер - это реализация этих правил, обычно развернутая как Pod в кластере.

Пример установки популярного Nginx Ingress Controller через Helm:

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

Пример простого Ingress ресурса, который маршрутизирует трафик по домену:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Ingress-контроллеры обеспечивают более гибкую маршрутизацию чем простые Service типа LoadBalancer. Для сложных сценариев SSL Termination и балансировки нагрузки рекомендуем ознакомиться с практическим сравнением архитектур на admin-wiki.ru.

NetworkPolicy: как ограничить трафик между Podами

NetworkPolicy позволяет реализовать сетевую безопасность на уровне L3-L4. Вы можете разрешать или запрещать трафик между Podами, namespace и из внешних источников.

Пример политики, которая запрещает весь ingress трафик к Podам с label app=db, кроме трафика из Podов с label app=backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-isolation
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Важно помнить, что NetworkPolicy работает только если CNI плагин поддерживает их реализацию. Calico и Cilium обеспечивают полную поддержку, Flannel требует дополнительной установки Calico как backend.

Планирование отказоустойчивой сетевой инфраструктуры

Отказоустойчивость сети в Kubernetes зависит от распределения компонентов и мониторинга.

• Распределяйте Podы критичных Service по разным узлам. Используйте anti-affinity правила в манифестах Podов.
• Размещайте несколько реплик Ingress-контроллеров на разных узлах. Это предотвратит полную недоступность внешнего трафика при сбое одного узла.
• Мониторинг ключевых метрик: количество правил iptables/ipvs (может расти и снижать производительность), ошибки в логах kube-proxy и CNI плагинов, загрузка сетевых интерфейсов на узлах.
• Для крупных кластеров рассмотрите переход kube-proxy в режим ipvs для лучшей производительности балансировки.

Сетевые решения должны масштабироваться вместе с кластером. Выбор CNI плагина, поддерживающего динамическую маршрутизацию и эффективную работу с большим количеством Podов, критически важен для production.

Шпаргалка и итоги: ключевые команды и выбор архитектуры

Сводная таблица типов Service помогает быстро выбрать нужный вариант.

Ключевые команды для диагностики сети Kubernetes.

• Просмотр сетевой информации Podов: kubectl get pod -o wide
• Детали Service и Endpoints: kubectl describe svc <name>
• Проверка NetworkPolicy: kubectl get networkpolicy -A
• Тест связи из Podа: kubectl exec -it <pod> -- curl http://service
• Проверка DNS: kubectl run test --image=busybox --restart=Never -- nslookup service
• Логи kubelet: journalctl -u kubelet
• Сетевые правила на узле: iptables -L -t nat или ipvsadm -L

Выбор архитектуры зависит от требований. Для небольшого кластера или обучения используйте Flannel с Service типа NodePort. Для production среды с требованиями безопасности выбирайте Calico и LoadBalancer Service с Ingress-контроллером. Для advanced кластеров с потребностями в мониторинге и L7-фильтрации подойдет Cilium.

Сетевой стек Kubernetes построен на четких абстракциях: Pod Network обеспечивает базовую связь, CNI плагины реализуют ее, а Service Network предоставляет стабильный доступ. Понимание этих компонентов и их взаимодействия позволяет эффективно строить, настраивать и диагностировать кластеры. Практические инструкции и сравнения в этом гайде дают инструменты для решения конкретных задач. Для более глубокого изучения сетевого администрирования и современных технологий, таких как обфускация трафика и сегментация, обратитесь к полному руководству по сетевому администрированию 2026. Если вам требуется автоматизация управления инфраструктурой, рассмотрите подходы Infrastructure as Code, подробно описанные в статье о Infrastructure as Code для Kubernetes в 2026. Для интеграции ИИ-сервисов в ваши приложения можно использовать единый API агрегатор, такой как AiTunnel, который предоставляет доступ к более чем 200 моделям без необходимости VPN и с оплатой в рублях.