Сети в Kubernetes: выбор CNI плагинов и настройка Network Policies

Представьте себе офис, где сотрудники могут свободно общаться друг с другом, но при этом строго запрещено передавать конфиденциальные документы без разрешения. В мире Kubernetes is системы оркестрации контейнеров, которая управляет развертыванием и масштабированием приложений эта «офисная культура» реализована через сетевые плагины и политики безопасности. Без правильной настройки сети ваши поды (Pods) либо не смогут найти друг друга, либо станут легкой добычей для злоумышленников.

В этой статье мы разберем, как работает интерфейс CNI (Container Network Interface - спецификация для подключения сетей к контейнерам), какие плагины выбрать для ваших задач и как настроить строгие правила доступа с помощью Network Policies. Мы уйдем от теории и посмотрим на реальные механизмы работы.

Как CNI превращает хаос в порядок

Когда вы запускаете под в кластере, ему нужен IP-адрес и возможность отправлять пакеты. Но Kubernetes сам по себе не занимается сетью - он делегирует эту задачу сторонним решениям. Именно здесь вступает в игру CNI.

CNI - это не программа, а спецификация, разработанная CNCF. Она задает стандартный способ взаимодействия между средой выполнения контейнеров (например, containerd или CRI-O) и сетевым драйвером. Процесс выглядит так:

1. Kubelet просит среду выполнения создать сеть для пода.
2. Среда выполнения создает сетевой namespace (песочницу).
3. Запускается бинарный файл плагина CNI из директории /opt/cni/bin/.
4. Плагин настраивает интерфейсы, назначает IP и маршруты.
5. Результат возвращается обратно Kubelet.

Благодаря этому модульному подходу вы можете менять сетевой драйвер, не переписывая код приложения. Главное правило CNI: каждый под получает уникальный IP-адрес в плоской сети кластера. Это значит, что под на узле А может напрямую обратиться к поду на узле Б по IP, как если бы они были в одной локальной сети.

Популярные CNI плагины: кто есть кто

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

Если вам нужно просто запустить тестовый кластер, Flannel подойдет идеально. Он требует минимум настроек. Однако для продакшена лучше смотреть в сторону Calico или Cilium. Calico использует протокол BGP для обмена маршрутами между узлами, что снижает задержки. Cilium же использует технологию eBPF (extended Berkeley Packet Filter), позволяя перехватывать и обрабатывать трафик прямо в ядре Linux, минуя традиционные механизмы iptables. Это дает огромную производительность и возможности мониторинга.

Network Policies: firewall внутри кластера

По умолчанию в Kubernetes все поды могут общаться со всеми другими подами. Это называется «разрешено всё». Для внутренней разработки это удобно, но для безопасности - катастрофа. Если один под взломан, злоумышник получит доступ ко всей внутренней сети.

Здесь на помощь приходят Network Policies is ресурсы Kubernetes для управления разрешенным сетевым трафиком между подами. Они работают как внутренние фаерволы. Важно понимать: Network Policies применяются только если ваш CNI плагин их поддерживает. Flannel игнорирует эти ресурсы, поэтому для безопасности вам нужен Calico, Cilium, Romana или Weave.

Структура политики проста. Вы указываете:

• podSelector: к каким подам применяется правило.
• ingress: какой входящий трафик разрешен.
• egress: какой исходящий трафик разрешен.

Например, вы хотите, чтобы фронтенд-поды могли обращаться только к бэкенду, но не к базе данных. Или наоборот - база данных должна принимать соединения только от бэкенда. С помощью Network Policies вы жестко ограничиваете этот поток.

Пример настройки политики безопасности

Давайте создадим политику, которая изолирует базу данных PostgreSQL. Допустим, у нас есть лейбл `app: database`. Мы хотим запретить любой входящий трафик, кроме того, который исходит от подов с лейблом `app: backend`.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432

Что происходит здесь? Мы говорим Kubernetes: «Примени это правило ко всем подам с меткой database». Затем мы указываем тип политики Ingress (входящий). В блоке ingress мы разрешаем трафик только от подов с меткой backend и только на порт 5432 (стандартный порт PostgreSQL). Все остальные попытки подключения будут молча заблокированы.

Обратите внимание: если вы не укажете policyTypes, политика может не примениться корректно. Всегда явно указывайте, интересует ли вас входной или выходной трафик.

Сложные сценарии: много интерфейсов и L7 фильтрация

Иногда одного сетевого интерфейса недостаточно. Например, вашему приложению нужен доступ к внутренней корпоративной сети и одновременно к публичному интернету, причем через разные каналы. Для таких случаев используется Multus is плагин для поддержки нескольких сетевых интерфейсов в Kubernetes подах. Multus позволяет прикреплять дополнительные интерфейсы к поду, используя различные CNI плагины для каждого из них.

Другой уровень сложности - фильтрация на уровне приложения (Layer 7). Традиционные Network Policies работают на уровнях L3/L4 (IP-адреса и порты). Что делать, если нужно разрешить доступ к API только для метода GET, но запретить DELETE?

Здесь shines Cilium. Благодаря поддержке HTTP-политик, Cilium может анализировать содержимое пакетов. Вы можете написать правило, которое разрешает трафик только если заголовок X-API-Key имеет определенное значение. Это открывает двери для микросегментации безопасности, когда защита строится не вокруг периметра сети, а вокруг каждого отдельного сервиса.

Частые ошибки при настройке сетей

Даже опытные инженеры допускают промахи при конфигурации CNI. Вот три самые распространенные проблемы:

1. Конфликт IP-диапазонов. Если диапазон IP-адресов подов пересекается с вашей физической сетью или VPN, пакеты могут теряться. Всегда проверяйте CIDR-блоки перед развертыванием.
2. Отсутствие Egress-правил. Многие забывают настраивать исходящий трафик. По умолчанию, если нет правил Egress, поведение зависит от реализации CNI. В некоторых случаях трафик блокируется полностью, ломая работу DNS или обновлений.
3. Непонимание приоритета правил. Network Policies суммируются. Если одна политика разрешает трафик, а другая запрещает, результат зависит от логики объединения. Обычно действует принцип «если хотя бы одно правило разрешает - трафик проходит» (для Ingress). Тестируйте политики в изолированной среде.

Как выбрать решение для вашего проекта

Не существует универсального плагина. Выбор зависит от зрелости вашей команды и требований бизнеса.

• Для стартапов и PoC: Используйте Flannel или Kube-router. Они просты, документация обширна, а проблем с совместимостью почти нет.
• Для крупного продакшена: Выбирайте Calico. Он стабилен, хорошо масштабируется и предоставляет мощные инструменты аудита трафика.
• Для zero-trust архитектуры: Рассмотрите Cilium. Его возможности L7 фильтрации и интеграция с Service Mesh делают его лидером в области современной безопасности.

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