Управление и маршрутизация сетевого трафика в Kubernetes (2026): от базовой связности до Service Mesh | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Управление и маршрутизация сетевого трафика в Kubernetes (2026): от базовой связности до Service Mesh

06 июня 2026 13 мин. чтения
Содержание статьи

Сетевая связность в Kubernetes - это фундамент для работы любых приложений. Без правильно настроенного CNI-плагина Pod'ы не смогут общаться друг с другом, а без корректно определенных Service и Ingress пользователи не получат доступ к вашим сервисам. Эта статья проходит весь путь: от выбора и установки сетевого плагина до реализации сложных стратегий развертывания через Service Mesh и отладки проблем в работающем кластере. Вы получите конкретные инструкции, сравнения и примеры конфигураций, проверенные на практике.

Мы начнем с основ - обеспечения базовой IP-связности между всеми компонентами кластера, затем разберем стандартные абстракции Kubernetes для маршрутизации, перейдем к тонкому управлению трафиком и безопасности и завершим четкой методикой диагностики. Каждый раздел содержит готовые к использованию команды и YAML-манифесты.

Фундамент: обеспечение базовой сетевой связности в кластере

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

CNI-плагины 2026: Cilium, Calico и Flannel в сравнении

В 2026 году выбор сводится к нескольким ключевым решениям, каждое из которых занимает свою нишу. Основные критерии сравнения: поддержка eBPF, производительность, возможности NetworkPolicy и дополнительные функции, такие как встроенная observability.

  • Cilium лидирует в использовании eBPF для фильтрации и маршрутизации трафика на уровне ядра, что дает высокую производительность и богатые возможности observability через Hubble. Он предоставляет расширенные NetworkPolicy (например, на уровне DNS) и имеет встроенные функции, близкие к Service Mesh.
  • Calico остается эталоном стабильности и зрелости. Он использует либо pure L3-маршрутизацию (BGP) для максимальной производительности, либо overlay-сеть (IP-in-IP, VXLAN). Его модель NetworkPolicy считается одной из самых полных и проверенных временем.
  • Flannel - это максимально простой плагин, который «просто работает». Он создает overlay-сеть (по умолчанию VXLAN) и не имеет встроенных возможностей NetworkPolicy (требуется установка Calico или другого провайдера политик). Его выбирают для тестовых сред, кластеров с минимальными требованиями к безопасности или когда приоритет - минимальная сложность администрирования.

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

Практика: установка и базовая проверка Cilium

Рассмотрим установку Cilium с помощью Helm, так как это стандартный и рекомендуемый метод. Предполагается, что у вас уже есть кластер Kubernetes и установлены Helm и kubectl.

1. Добавьте репозиторий Helm Cilium:

helm repo add cilium https://helm.cilium.io/
helm repo update

2. Установите Cilium с активацией Hubble для observability:

helm install cilium cilium/cilium --version 1.15.0 \
  --namespace kube-system \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

Эта команда установит Cilium в пространство имен kube-system. Параметры hubble.relay.enabled и hubble.ui.enabled включают компоненты для сбора и визуализации сетевых потоков.

3. Дождитесь запуска всех Pod'ов Cilium:

kubectl get pods -n kube-system -l k8s-app=cilium

Убедитесь, что все Pod'ы перешли в состояние Running.

4. Проверьте статус Cilium:

cilium status --wait

Эта команда покажет, что все компоненты Cilium работают корректно, а кластер готов к работе.

5. Запустите встроенный тест связности, чтобы убедиться, что сеть функционирует:

cilium connectivity test

Этот тест развернет набор тестовых приложений и проверит связность между ними, а также с внешними ресурсами.

Частая проблема: конфликт CIDR. Если в вашей сети уже используется диапазон IP-адресов по умолчанию для Pod'ов в Cilium (10.0.0.0/8), его нужно изменить во время установки, добавив параметр --set ipam.operator.clusterPoolIPv4PodCIDR="172.16.0.0/16" в команду helm install.

Абстракции Kubernetes для маршрутизации трафика: Service и Ingress

После настройки базовой IP-связности необходимо определить, как трафик достигает ваших приложений. Kubernetes предоставляет два основных ресурса: Service для внутренней балансировки нагрузки и стабильных эндпоинтов и Ingress для управления входящим HTTP/HTTPS трафиком извне кластера.

Service: типы, селекторы и внутренняя балансировка нагрузки

Service - это абстракция, которая определяет логический набор Pod'ов и политику доступа к ним. Он решает проблему динамических IP-адресов Pod'ов, предоставляя стабильную DNS-запись и виртуальный IP (ClusterIP). Kube-proxy на каждом узле (работающий в режиме iptables или IPVS) отвечает за перенаправление трафика с виртуального IP Service на реальные IP-адреса Pod'ов.

Основные типы Service:

  • ClusterIP (тип по умолчанию): предоставляет внутренний IP-адрес, доступный только внутри кластера. Используется для связи между микросервисами.
  • NodePort: открывает статический порт на каждом узле кластера. Трафик на <NodeIP>:<NodePort> перенаправляется на Service. Подходит для тестирования или простых сценариев без облачного балансировщика.
  • LoadBalancer: интегрируется с облачным провайдером (AWS ELB, GCP Cloud Load Balancing) для создания внешнего балансировщика нагрузки. Внешний IP-адрес балансировщика автоматически прописывается в статусе Service.

Пример манифеста Service типа ClusterIP для frontend-приложения:

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend  # Селектор ищет Pod'ы с меткой app=frontend
  ports:
  - port: 80       # Порт, на котором Service принимает запросы
    targetPort: 8080 # Порт контейнера в Pod'е, на который перенаправляется трафик
  type: ClusterIP

После создания Service Kubernetes непрерывно обновляет его Endpoints - список IP-адресов и портов Pod'ов, соответствующих селектору. Проверить Endpoints можно командой:

kubectl get endpoints frontend-service

Headless Service (без ClusterIP) создается указанием clusterIP: None. Он возвращает DNS A-записи напрямую для IP-адресов Pod'ов, что полезно для stateful-приложений, таких как базы данных, где клиенту нужно подключиться к конкретному экземпляру.

Ingress: управление HTTP/HTTPS трафиком извне

Ingress не является типом Service. Это набор правил, которые разрешают входящие соединения к сервисам кластера. Для их выполнения необходим Ingress Controller - специальный Pod, который отслеживает объекты Ingress и настраивает балансировщик (чаще всего Nginx или Envoy) согласно этим правилам.

1. Установите Nginx Ingress Controller с помощью Helm:

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

2. Создайте простой Ingress Resource, который маршрутизирует трафик на два разных сервиса на основе имени хоста:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: "app.admin-wiki.ru"
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
  - host: "api.admin-wiki.ru"
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 8080

3. Для настройки TLS создайте Secret с сертификатом и ключом и укажите его в Ingress:

apiVersion: v1
kind: Secret
type: kubernetes.io/tls
data:
  tls.crt: 
  tls.key: 
metadata:
  name: tls-secret
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-ingress
spec:
  tls:
  - hosts:
      - app.admin-wiki.ru
    secretName: tls-secret
  rules:
  - host: app.admin-wiki.ru
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

Аннотации (annotations) в метаданных Ingress позволяют тонко настраивать поведение контроллера, например, задавать правила rewrite, настройки балансировки или ограничения скорости. Подробные примеры работы с Service и Ingress, включая решение типичных ошибок, собраны в нашем практическом руководстве по Service и Ingress.

Продвинутое управление трафиком и безопасность с Network Policies

По умолчанию все Pod'ы в кластере Kubernetes могут общаться друг с другом. Network Policies позволяют реализовать модель «запретить по умолчанию» (deny-by-default) и явно разрешить только необходимые сетевые соединения, что критически важно для безопасности микросервисных приложений и соответствия требованиям.

Network Policy - это ресурс Kubernetes, который определяет правила входящего (ingress) и исходящего (egress) трафика для группы Pod'ов, отобранных с помощью селектора. Важно помнить: сам по себе ресурс NetworkPolicy ничего не делает. Его должен поддерживать и применять ваш CNI-плагин (Calico, Cilium и другие).

Кейсы Network Policies для типовых сценариев

Пример 1: Запрет всего входящего трафика в неймспейс по умолчанию. Это базовая политика для изоляции неймспейса. Она разрешает весь исходящий трафик, но блокирует весь входящий, если он не разрешен другими политиками.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {} # Применяется ко всем Pod'ам в неймспейсе production
  policyTypes:
  - Ingress
  ingress: [] # Пустой список правил = запретить весь входящий трафик

Пример 2: Разрешение входящего трафика только от Pod'ов с меткой role=frontend на порт 80. Эта политика позволяет frontend-сервисам обращаться к backend.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend # Источник: Pod'ы с меткой role=frontend (в любом неймспейсе)
    ports:
    - protocol: TCP
      port: 80

Пример 3: Разрешение исходящего трафика Pod'а только к CIDR внешней базы данных. Эта политика ограничивает выход Pod'а в интернет, разрешая соединение только с конкретным внешним хостом.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-external-db
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: data-processor
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 203.0.113.100/32 # Конкретный IP внешней БД
    ports:
    - protocol: TCP
      port: 5432

Особенности реализации: Calico исторически имеет самую зрелую поддержку NetworkPolicy. Cilium полностью поддерживает стандартные NetworkPolicy и расширяет их, добавляя, например, правила на уровне DNS-запросов или HTTP-путей. Flannel не поддерживает политики самостоятельно, для их использования необходимо установить Calico в режиме только политик (Calico CNI при этом не используется). Более глубокий разбор практик сетевой безопасности, включая работу с iptables, вы найдете в статье «Сетевая безопасность контейнеров в 2026».

Service Mesh: Istio и Linkerd для Canary-развертываний и A/B-тестирования

Service Mesh решает задачи, выходящие за рамки базовой связности Kubernetes: разбивка трафика (traffic splitting), наблюдение за межсервисным общением (observability), обеспечение отказоустойчивости (retries, timeouts, circuit breaking) и безопасность на уровне mTLS. Он реализуется как набор sidecar-прокси (чаще всего на базе Envoy), развернутых рядом с каждым Pod'ом приложения, и плоскости управления, которая конфигурирует эти прокси.

Два основных решения в 2026 году: Istio (богатый функционал, высокая сложность) и Linkerd (легковесный, сфокусированный на простоте и производительности).

Canary-развертывание с Istio: пошаговый сценарий

Canary-развертывание - это стратегия постепенного ввода новой версии сервиса в эксплуатацию. Трафик постепенно переводится со старой версии (v1) на новую (v2), что позволяет отслеживать метрики и откатиться при появлении проблем.

Предположим, у нас есть Deployment frontend-v1. Мы хотим развернуть frontend-v2 и начать направлять на него часть трафика.

1. Разверните обе версии приложения. Убедитесь, что Pod'ы имеют разные метки версий (например, version: v1 и version: v2), но общую метку приложения (например, app: frontend).

2. Создайте Service, который будет указывать на Pod'ы с меткой app: frontend (он будет выбирать Pod'ы обеих версий):

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend
  ports:
  - port: 80

3. Настройте Istio VirtualService и DestinationRule для управления трафиком.

DestinationRule определяет подмножества (subsets) на основе меток Pod'ов:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: frontend-dr
spec:
  host: frontend-service.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

VirtualService определяет правила маршрутизации между этими подмножествами. Начнем с направления 90% трафика на v1 и 10% на v2:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: frontend-vs
spec:
  hosts:
  - frontend-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: frontend-service.default.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: frontend-service.default.svc.cluster.local
        subset: v2
      weight: 10

4. Мониторинг. Используйте инструменты observability, такие как Kiali или Grafana с прометеем, чтобы отслеживать ключевые метрики для версии v2: задержку (latency), частоту ошибок (error rate), объем трафика. Если метрики в норме, постепенно увеличивайте вес для v2 до 50%, затем до 100%, обновляя VirtualService.

Настройка A/B-тестирования трафика

A/B-тестирование позволяет направлять трафик на разные версии сервиса на основе определенных условий, например, заголовков HTTP-запроса. Это полезно для тестирования нового пользовательского интерфейса или функциональности на определенной группе пользователей.

Пример VirtualService для A/B-теста: пользователи с заголовком X-Test-Group: beta попадают на новую версию UI, остальные - на стабильную.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: frontend-ab-test
spec:
  hosts:
  - frontend-service.default.svc.cluster.local
  http:
  - match:
    - headers:
        x-test-group:
          exact: beta
    route:
    - destination:
        host: frontend-service.default.svc.cluster.local
        subset: v2
  - route:
    - destination:
        host: frontend-service.default.svc.cluster.local
        subset: v1

Такой заголовок может добавляться на уровне Ingress Gateway Istio или генерироваться клиентским приложением для пользователей, включенных в тестовую группу.

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

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

Чеклист: от Pod к Service и обратно

Если Pod A не может подключиться к Pod B или Service, следуйте этому чеклисту:

  1. Проверьте состояние Pod'ов: kubectl get pods -o wide. Убедитесь, что оба Pod'а в состоянии Running и имеют IP-адреса. Если IP-адреса нет, проблема на уровне CNI.
  2. Проверьте связность на уровне IP (минуя Service): Зайдите в Pod A (kubectl exec -it <pod-a-name> -- sh) и попробуйте выполнить ping или curl на IP-адрес Pod B. Если это не работает, проблема в базовой сетевой связности (CNI, сетевые политики, брандмауэр хоста).
  3. Проверьте DNS-имя Service: Изнутри Pod выполните nslookup <service-name>.<namespace>. Должен разрешиться в ClusterIP сервиса. Если нет, проверьте работу CoreDNS (kubectl get pods -n kube-system -l k8s-app=kube-dns).
  4. Проверьте Endpoints Service: kubectl get endpoints <service-name>. Список должен содержать IP-адреса и порты Pod'ов, соответствующих селектору Service. Пустой список означает, что селектор Service не совпадает с метками Pod'ов.
  5. Проверьте Network Policies: kubectl get networkpolicy --all-namespaces. Убедитесь, что нет политик, блокирующих трафик между вашими Pod'ами. Для детального анализа в Calico используйте calicoctl, в Cilium - cilium policy trace.
  6. Проверьте логи CNI-плагина на узлах: Найдите Pod'ы Cilium/Calico в kube-system и просмотрите их логи (kubectl logs -n kube-system <cni-pod-name>).

Инструменты: tcpdump, cilium monitor, сетевые неймспейсы

Когда стандартные методы не помогают, требуются низкоуровневые инструменты.

Использование tcpdump в сетевом неймспейсе Pod'а: Kubernetes 1.25+ предоставляет удобную команду kubectl debug для создания временного отладочного контейнера, который делится сетевым пространством имен проблемного Pod'а.

kubectl debug -it <problem-pod-name> --image=nicolaka/netshoot --target=<problem-pod-name> -- sh

В запущенном отладочном контейнере вы можете использовать tcpdump для перехвата трафика:

tcpdump -i any host <destination-service-ip> -vv

Использование cilium monitor (для кластеров на Cilium): Эта команда показывает сетевые потоки и решения о принятии/сбросе пакетов в реальном времени.

kubectl exec -n kube-system <cilium-pod> -- cilium monitor --related-to <pod-id>

Pod ID можно получить командой cilium identity list.

Для комплексного понимания сетевых технологий, включая настройку WireGuard и работу с DPI в современных условиях, обратитесь к полному руководству по сетевому администрированию 2026.

Выбор стека: сводка и рекомендации для 2026

Выбор инструментов зависит от требований вашего проекта, уровня экспертизы команды и бюджета. Вот сводные рекомендации:

  • Кластер для обучения, тестирования или домашний проект: Flannel (максимальная простота) + Nginx Ingress Controller. Network Policies не требуются или устанавливаются отдельно.
  • Продакшн-кластер общего назначения с балансом возможностей и сложности: Cilium или Calico (в зависимости от предпочтений: eBPF/observability vs стабильность) + Nginx Ingress Controller. Обязательное использование Network Policies.
  • Сложная микросервисная архитектура с высокими требованиями к Canary-развертываниям, observability и безопасности: Cilium (как CNI и основа для возможностей mesh) + Istio (полнофункциональный Service Mesh). Это самый мощный, но и самый сложный в освоении и эксплуатации стек.
  • Микросервисная архитектура с упором на простоту и низкие накладные расходы: Cilium/Calico + Linkerd (легковесный Service Mesh). Linkerd проще в установке и управлении, чем Istio, и потребляет меньше ресурсов.

Ключевой тренд 2026 года - конвергенция функций CNI и Service Mesh. Cilium активно развивает Cilium Service Mesh, предлагая встроенные возможности управления трафиком поверх eBPF, что может сократить необходимость в отдельном тяжеловесном mesh. eBPF продолжает укреплять свои позиции как технология, обеспечивающая высокую производительность, безопасность и наблюдаемость на уровне ядра Linux.

Для автоматизации рабочих процессов, связанных с ИИ, и доступа к множеству моделей через единый API может быть полезен сервис AiTunnel. Он позволяет интегрировать различные нейросетевые модели в ваши пайплайны, управлять бюджетами и ключами, что может быть актуально для команд, занимающихся MLops или автоматизацией.

Поделиться:
Сохранить гайд? В закладки браузера