Привет, Хабр! На связи Георг Гаал, основатель и CTO AEnix, идеолог cozystack.io, член программного комитета конференций DevOpsConf и ведущий разнообразных образовательных проектов. В этой статье я хочу поговорить про сетевую подсистему Kubernetes и разобраться, какой CNI-плагин выбрать для production-кластера. 

Kubernetes давно уже не просто модная технология, а основа многих продакшен-систем. Но с ним надо уметь работать (спасибо, кэп).

У Kubernetes модульная структура, которая позволяет использовать только те компоненты и возможности, которые нужны для решения конкретной задачи в конкретной обстановке. Но… какой серьёзный кластер без своей сетевой подсистемы? Давайте погрузимся и посмотрим, что же происходит с сетью в k8s. Заодно попробуем найти ответы на некоторые каверзные вопросы с собеседований.

За сеть в Kubernetes отвечает так называемый CNI-плагин. Очевидно, что выбор CNI-плагина — одно из первых и самых важных архитектурных решений, которое вы принимаете. От него зависят производительность, безопасность и наблюдаемость вашего кластера. Разберёмся, какой плагин выбрать, как его правильно настроить и какие грабли поджидают впереди.

Для обеспечения взаимозаменяемости сетевых плагинов был разработан этот самый интерфейс CNI — «Container Network Interface». Он позволяет взаимодействовать kubelet’у с сетевым плагином и по сути является достаточно простым протоколом. Настолько, что можно написать свой сетевой плагин на баше. И даже есть пример такого решения.

Интересный факт № 1 

В штатной поставке Kubernetes существует целый набор стандартных сетевых плагинов. Они устанавливаются на систему как зависимость для containerd и там самый базовый набор вроде bridge, ipvlan, loopback, macvlan, host-local, portmap и tuning

Но реальный выбор плагина в 95% случаев сегодня стоит между двумя титанами: Calico и Cilium. Чтобы понять, почему именно они, давайте быстро осмотрим ландшафт.

Быстрый разбор поляны: куда делись остальные?

Когда-то актуальных CNI-плагинов было много, и каждый был по-своему хорош. Но рынок стабилизировался. Давайте кратко пробежимся по «ветеранам» и нишевым решениям, чтобы понять, почему они отошли на второй план.

Старая гвардия:

• Flannel

Простой как валенок, идеален для minikube или тестового стенда. Использует базовый Overlay (VXLAN). Его главный минус — отсутствие поддержки Network Policies, что для production недопустимо. Интересно, что буквально недавно нашлась возможность добавить сетевые политики через дополнительный контейнер kube-network-policies. Детали тут.

• Weave Net

Когда-то был популярен за свою простоту и mesh-сеть. К сожалению, проект больше активно не развивается, а компания разработчик (Weaveworks) почила в бозе.

• Canal

Интересный гибрид, который использовал Flannel для сети и Calico для политик. Шёл в комплекте с дистрибутивом Rancher как плагин по умолчанию. Потерял актуальность, так как «чистый» Calico и Cilium предлагают более интегрированные и мощные решения.

Нишевые игроки:

• Multus

Это не CNI, а «мета-плагин». Его задача — позволить поду иметь несколько сетевых интерфейсов от разных CNI. Незаменим в телекоме или NFV, но для большинства веб-приложений это избыточно.

• Облачные CNI (AWS VPC CNI, Azure CNI, GKE CNI)

Отличный выбор, если вы живёте в экосистеме одного облака. Они обеспечивают нативную интеграцию с облачной сетью, назначая подам IP-адреса прямо из VPC. Основной минус — вы привязаны к провайдеру.и зачастую эти платины реализуют только базовые механики. Ожидать от них функционала аналогичного Cilium ClusterMesh достаточно странно.

Хорошие, но...

• Kube-router

Крепкое решение, использующее BGP и IPVS. Но его фаза активной разработки, по сути, завершилась, и сообщество вокруг него меньше, чем у лидеров. Если хочется надёжное и обкатанное решение без неожиданностей, kube-router может быть хорошим решением.

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

Интересный факт № 2 

Можно использовать несколько CNI одновременно. Например, Cilium поддерживает работу в паре с AWS VPN CNI. В этом случае каждый CNI отвечает за какой-то свой набор функций. Например, AWS плагин за маршрутизацию (роутинг) и выделение адресов, а Cilium за наблюдаемость трафика и безопасность. Такой механизм называется chaining.

Интересный факт № 3 

Сервисная сеть Istio для настройки сетевых правил для каждого пода внутри сервисной сети использует магию iptables. Для упрощения механики Istio позволяет эту механику перенести с сайдкара на специализированный Istio CNI, единственная задача которого — правильная настройка сети, чтобы поды могли работать внутри сервисной сети.

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

Чтобы упростить этот непростой выбор, свёл основные параметры этих CNI в таблицу:

Анатомия сети в Kubernetes: что нужно помнить при настройке

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

Интересный факт № 4

Очевидно, что под может быть запущен только на одном вычислительном узле кластера. Не может быть такой ситуации, что часть контейнеров пода запущена на одном рабочем узле, а часть на другом. Кстати, такой вопрос может встретиться на собеседовании.

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

Как правило, IP-адрес пода назначается из специальной сети, которая называется clusterNetwork и диапазон её адресов — pod CIDR или clusternetwork CIDR. Она задаётся при инициализации кластера и нарезается на поддиапазоны /24, каждый из которых назначается на один из рабочих узлов кластера.

/24 — это некое значение по умолчанию, выбранное из соображений разумности, чтобы гарантировать возможность запуска 110 подов по умолчанию на каждом узле. /24 подразумевает 256 адресов, но из них мы вычитаем два служебных (.0 и .255) — и таким образом получаем 254 адреса. 

Запас адресов в два раза больше числа подов на узле позволяет избежать конфликтов, когда вновь создаваемые поды получают IP-адреса, которые ещё не освободились после удаления старых.

Для сети подов обычно используют так называемый overlay. По сути это некая дополнительная сеть, которая существует только в рамках узлов кластера. Физически она реализуется при помощи настройки туннелей (конечно, же автоматически средствами самого CNI-плагина) на базе протоколов vxlan, ipip и прочих. У каждого CNI-плагина свой список поддерживаемых протоколов.

Другой вариант реализации сети — это underlay. К нему прибегают, когда требуется максимальная производительность и/или прямая маршрутизация подов из внешней по отношению к кластеру сети. 

Вторая подсеть, с которой придется иметь дело — это сеть сервисов. Её диапазон адресов Service CIDR и он не должен пересекаться с clusternetwork CIDR. Из этого диапазона сразу резервируется первый адрес для сервиса под названием Kubernetes (например, в случае Service CIDR 10.64.0.0/16, адрес сервиса Kubernetes будет 10.64.0.1). Через него можно обратиться в API-кластера из любого пода.

Далее обычно резервируется адрес под CoreDNS. Как правило берется .10  из Service CIDR, но никакого ограничения тут нет: можно выбрать любой. Есть существенное отличие между адресами подов и адресами сервисов. Первые всё-таки маршрутизируются внутри кластера и физически присутствуют на интерфейсах узла, где запущен под. Адреса же сервисов обычно не присутствуют на интерфейсах и существуют только внутри iptables цепочек на узлах. При помощи iptables трафик, попадающий на такой «виртуальный» адрес, преобразуется и отправляется на те поды, на которые указывает сервис. 

Третья подсеть — это сама сеть рабочих узлов кластеров.

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

Прощай, kube-proxy!

Компонент kube-proxy отвечает за реализацию Services через iptables или IPVS. Но это не самый эффективный способ. Современные CNI, такие как Calico и Cilium, могут полностью заменить kube-proxy, реализуя его функциональность напрямую (часто через eBPF). Это убирает лишний компонент и делает обработку трафика еще быстрее.

Как решить типовые проблемы с CNI

Теория — это хорошо, но давайте к практике. С чем вы точно столкнетесь:

1. Поды на одном узле пингуются, а на разных — нет.

Это классический симптом проблемы с overlay-сетью.

Причина: чаще всего файервол (на хосте или в сети) блокирует трафик туннелей. Например, для VXLAN по умолчанию используется порт UDP/8472. Убедитесь, что он открыт между всеми узлами кластера. 

Также мне довелось столкнуться с частным случаем проблемы VXLAN в кластере на VMware. Поскольку сама платформа виртуализации использует этот же протокол, произошёл конфликт.

Что делать:

1. Проверьте логи CNI-демона (calico-node, cilium) на узлах. Там почти всегда есть ошибки, связанные с установкой соединения.

2. Проверьте iptables или nftables на хостах.

3. Проверьте сетевые настройки вашего облака или виртуализации. Например, в VMware бывает конфликт портов VXLAN, и его нужно менять в настройках CNI.

2. Я добавил одну Network Policy, и всё сломалось

Это не баг, а фича.

Причина: как только вы применяете в неймспейсе хотя бы одну политику NetworkPolicy, для всех подов в этом неймспейсе включается режим «default deny». Весь трафик, который не разрешен явно, блокируется.

Что делать:

1. Начните с базовой разрешающей политики для всего неймспейса, например, разрешите весь ingress-трафик.

2. Постепенно добавляйте более строгие, ограничивающие политики для конкретных приложений.

Важно: kubectl get networkpolicies показывает только стандартные политики Kubernetes. Calico и Cilium имеют свои CRD (GlobalNetworkPolicy, CiliumNetworkPolicy), которые нужно проверять отдельно!

3. Кластер не запускается, поды в вечном CrashLoopBackOff

Часто это проблема пересечения сетей.

Причина: выбранный вами Pod CIDR (например, 10.0.0.0/8 по умолчанию в некоторых инсталляторах) конфликтует с сетью, в которой работают ваши серверы. Это частая история в Hetzner или других хостингах, где по умолчанию используются большие приватные сети.

Что делать:

1. Планируйте IP-адресацию заранее! Выберите для подов и сервисов диапазоны, которые нигде больше не используются в вашей инфраструктуре.

2. При установке кластера (например, через kubeadm) явно укажите правильные podSubnet и serviceSubnet.

3. В Cilium лучше всего использовать режим Kubernetes Host Scope, чтобы за распределение подсетей по узлам отвечал kube-controller-manager, а не сам CNI.

Кратко подытожим

CNI — это фундамент вашего кластера. От выбора плагина и правильной настройки зависит не только производительность, но и безопасность всего кластера.

Мои рекомендации:

Сфокусируйтесь на лидерах

Для нового production-кластера ваш выбор почти всегда будет между Calico и Cilium.

Выбирайте осознанно

Calico — если нужна BGP-интеграция и проверенные технологии. Cilium — если в приоритете максимальная производительность, наблюдаемость и L7-политики.

Планируйте заранее

Правильная IP-адресация спасет вас от часов мучительной отладки.

Помните о безопасности

Начинайте использовать Network Policies как можно раньше, но делайте это аккуратно, чтобы не заблокировать себе весь трафик.

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

А уметь работать с Kubernetes вам придётся, если хотите оставаться востребованным на рынке IT-специалистов в 2026 году.

Прокачать свои навыки в k8s и разобраться во всех тонкостях конфигурации и установки production-ready кластера можно на курсе «Kubernetes Мега». За 8 недель обучения вы поймёте, как получить полный контроль над своей контейнерной инфраструктурой и эффективно её масштабировать в enterprise-условиях. Все подробности — на сайте.

Если же вам важно на продвинутом уровне освоить service mesh, вам подойдёт интенсив «Service mesh. База». В его основе — реальные бизнес-кейсы, которые помогут вам понять всю глубину этого подхода.