Kubernetes networking — это набор правил и механизмов, которые обеспечивают связь между подами, сервисами, узлами и внешними клиентами. Эта модель нужна, чтобы контейнерные приложения обменивались данными предсказуемо, без ручной настройки сети для каждого экземпляра.
Kubernetes скрывает часть низкоуровневой сетевой логики, но сама сеть внутри кластера устроена не примитивно. Чтобы понимать маршрутизацию трафика, отладку сервисов и ограничение доступа между приложениями, нужно разобраться в базовых принципах: как адресуются поды, зачем нужен Service, что делает kube-proxy и где применяется CNI.
Содержание статьи
Что такое Kubernetes
Kubernetes — это платформа оркестрации контейнеров, которая автоматизирует запуск, масштабирование и управление приложениями в контейнерах.
Система появилась как открытый проект на базе идей, которые Google использовала во внутренней инфраструктуре для управления распределёнными нагрузками. Сегодня Kubernetes стал стандартным инструментом для запуска контейнерных приложений в локальной инфраструктуре, приватных облаках, публичных облаках и гибридных средах.
Контейнеры упаковывают код и зависимости приложения в изолированную среду. За счёт этого одно и то же приложение можно переносить между серверами и платформами с меньшим числом расхождений по окружению. Kubernetes управляет такими контейнерами не по одному, а как системой: следит за количеством экземпляров, восстанавливает упавшие компоненты и распределяет нагрузку.
Из чего состоит сеть Kubernetes
Сеть Kubernetes связывает между собой поды, сервисы, узлы и внешние точки доступа. Внутри кластера эти элементы должны взаимодействовать так, будто находятся в едином адресном пространстве.
На практике сеть в Kubernetes охватывает несколько уровней. Есть связь контейнеров внутри одного пода. Есть обмен данными между подами на одном узле и между подами на разных узлах. Есть отдельный слой доступа через Service, который даёт стабильную точку входа к группе подов, даже если сами поды пересоздаются и получают новые IP-адреса.
Снаружи кластера трафик тоже должен попасть к приложению. Для этого используются сетевые механизмы публикации сервисов: NodePort, LoadBalancer, Ingress и другие варианты в зависимости от задачи.
Какие термины нужно понимать перед разбором
Чтобы понять сетевую модель Kubernetes, достаточно держать в голове несколько базовых понятий: IP-адрес, порт, DNS, NAT, сетевое пространство имён и прокси.
IP-адрес — это адрес устройства или сетевой сущности в сети. В Kubernetes IP получает под, а иногда и сервис в виде виртуального адреса.
Порт определяет, какому процессу или приложению должен быть доставлен сетевой трафик. Один IP может обслуживать несколько приложений, если они слушают разные порты.
DNS нужен для разрешения имён в адреса. В кластере Kubernetes DNS помогает обращаться к сервисам и подам по читаемым именам вместо запоминания IP.
NAT — это преобразование адресов. В обычных сетях он часто нужен для выхода внутренних адресов наружу. Внутренняя модель Kubernetes строится так, чтобы связь между подами в идеале обходилась без NAT.
Сетевое пространство имён изолирует сетевые интерфейсы, маршруты и порты. Контейнеры внутри одного пода используют общее сетевое пространство имён, поэтому могут общаться через localhost.
Прокси в контексте Kubernetes обычно вспоминают из-за kube-proxy — компонента, который поддерживает сетевые правила для маршрутизации трафика к сервисам.
Как работает сеть Kubernetes
Сетевая модель Kubernetes строится вокруг плоской сети, где каждый под может связаться с любым другим подом в кластере по IP-адресу. Это одно из главных отличий Kubernetes от схем, где связь приходится собирать из ручных пробросов портов и промежуточных правил.
Такой подход упрощает запуск распределённых приложений. Если один сервис должен обратиться к другому, системе не нужно каждый раз строить отдельную схему соединения между контейнерами. Поды получают собственные адреса, а сетевой слой обеспечивает маршрутизацию между узлами.
Для разработчика это выглядит проще, чем устроено под капотом. Он работает с подами и сервисами, а маршруты, правила и виртуальные интерфейсы обычно настраиваются через сетевой плагин и компоненты самого кластера.
Какие правила лежат в основе сетевой модели Kubernetes
Базовая модель Kubernetes сводится к трём правилам: каждый под имеет собственный IP, все поды могут общаться друг с другом без NAT внутри кластера, системные агенты на узле могут обращаться к подам на этом узле.
Отсюда вытекает важное следствие. Под в Kubernetes воспринимается как самостоятельная сетевая единица. Это упрощает адресацию и избавляет от схем, где контейнеры внутри кластера приходится публиковать через цепочку вручную настроенных портов.
При этом IP пода не считается постоянным. Если под удалён или пересоздан, адрес, скорее всего, изменится. Поэтому для стабильного доступа к приложению поверх подов используется Service.
Как устроено взаимодействие контейнеров внутри одного пода
Контейнеры в одном поде общаются через localhost, потому что разделяют одно сетевое пространство имён. Для сети Kubernetes это самый локальный и прямой тип взаимодействия.
Это значит, что контейнеры внутри пода видят один и тот же IP-адрес и один набор доступных портов. Один контейнер может слушать порт, а другой обращаться к нему по 127.0.0.1 или localhost. Такая схема удобна, когда в поде вместе работают основной контейнер приложения и вспомогательный контейнер, который, например, проксирует запросы или собирает логи.
Как работает связь между подами
Связь pod-to-pod означает, что любой под в кластере может обратиться к другому поду напрямую по его IP-адресу, независимо от того, находятся ли они на одном узле или на разных.
Если поды размещены на одном узле, трафик проходит локальнее и проще. Если на разных, сетевой плагин и маршрутизация между узлами обеспечивают доставку пакетов через инфраструктуру кластера.
Для удобства в Kubernetes работает встроенный DNS-сервис. Он позволяет обращаться к сущностям по именам, а не только по IP. Это особенно полезно в динамической среде, где экземпляры приложений могут появляться и исчезать.
Зачем нужен Service в Kubernetes
Service даёт стабильную точку доступа к группе подов, даже если сами поды пересоздаются и меняют IP-адреса. Без Service клиенту пришлось бы постоянно отслеживать актуальные адреса всех экземпляров приложения.
Service описывает логическую группу подов, обычно по меткам. Когда запрос приходит на адрес сервиса, он перенаправляется на один из подходящих подов. За счёт этого Service решает сразу несколько задач: постоянный адрес, балансировка трафика и удобное обнаружение приложений внутри кластера.
Самый частый внутренний вариант — ClusterIP. Такой сервис доступен только изнутри кластера и используется для связи между приложениями.
Что делает kube-proxy
kube-proxy поддерживает сетевые правила на узлах и направляет трафик к нужным сервисам и подам. Он следит за изменениями в Service и подах, чтобы маршрутизация оставалась актуальной.
Когда набор подов меняется, kube-proxy обновляет правила обработки трафика на узле. В Linux для этого часто используются механизмы вроде iptables. Благодаря этому запрос на виртуальный адрес сервиса уходит не в пустоту, а попадает на реальный backend-под, который сейчас доступен.
Пользователь обычно не взаимодействует с kube-proxy напрямую. Но при разборе проблем с доступностью сервиса этот компонент всплывает очень быстро.
Какие варианты доступа к сервисам есть извне
Для внешнего доступа Kubernetes использует несколько типов сервисов и правил маршрутизации. Выбор зависит от того, нужен ли внутренний доступ, публикация на порту узла, внешний балансировщик или HTTP-маршрутизация.
| Механизм | Для чего нужен | Как работает |
| ClusterIP | Внутренний доступ внутри кластера | Даёт виртуальный IP, доступный только изнутри |
| NodePort | Публикация сервиса через порт на каждом узле | Открывает статический порт на IP узлов |
| LoadBalancer | Внешний доступ через балансировщик | Использует внешний балансировщик провайдера |
| ExternalName | Доступ к внешнему ресурсу по DNS-имени | Связывает сервис Kubernetes с внешним DNS-именем |
| Ingress | Маршрутизация HTTP и HTTPS к сервисам | Направляет внешние запросы по правилам хоста и пути |
NodePort часто используют для базовой публикации и тестирования. LoadBalancer применяют там, где инфраструктура умеет выдавать внешний балансировщик и публичный адрес. Ingress нужен, когда нужно управлять внешним доступом на уровне маршрутов, доменов и веб-трафика.
Чем ClusterIP, NodePort, LoadBalancer и Ingress отличаются на практике
Разница между ними в уровне доступа и способе публикации приложения. ClusterIP работает только внутри кластера, NodePort открывает порт на каждом узле, LoadBalancer выносит сервис наружу через внешний балансировщик, а Ingress управляет входящими HTTP и HTTPS-запросами по правилам маршрутизации.
Если приложению нужен только внутренний обмен между сервисами, обычно хватает ClusterIP. Если надо быстро проверить доступ снаружи без сложной схемы, используют NodePort. Если инфраструктура поддерживает облачные балансировщики, удобнее LoadBalancer. Когда сервисов много и нужен единый вход с маршрутизацией по путям и доменам, применяют Ingress.
Что такое сетевые политики Kubernetes
Сетевые политики Kubernetes задают правила, которые определяют, какой трафик разрешён для подов. Они нужны для ограничения доступа между приложениями внутри кластера.
По умолчанию в ряде сценариев сеть внутри кластера может быть слишком открытой. Сетевые политики позволяют описать, какие поды могут принимать входящие соединения и куда им разрешён исходящий трафик. Политика обычно опирается на селекторы подов и правила ingress и egress.
Это особенно полезно, когда в одном кластере работают разные команды, окружения или сервисы с разным уровнем доверия. Изоляция в таком случае снижает риск нежелательных соединений между компонентами.
Из чего состоит сетевая политика
Базовая сетевая политика включает селектор подов, правила входящего трафика и правила исходящего трафика.
- Pod selector определяет, к каким подам применяется политика.
- Ingress задаёт, кто может отправлять трафик в эти поды.
- Egress определяет, куда выбранные поды могут обращаться сами.
Сами политики начинают работать только вместе с сетевым решением, которое умеет их применять. Не каждый сетевой плагин реализует этот механизм одинаково.
Что такое CNI и зачем он нужен
CNI, или Container Network Interface, — это стандарт, который описывает, как сетевые плагины должны подключать контейнеры и поды к сети. В Kubernetes именно CNI обычно отвечает за выдачу адресов, настройку интерфейсов и маршрутов.
Kubernetes сам по себе задаёт модель сети, но не реализует её полностью в одиночку. Реальную сетевую связность обеспечивают плагины, совместимые с CNI. Они создают сетевые пространства имён, назначают IP-адреса, настраивают маршрутизацию между узлами и помогают обеспечить связь pod-to-pod.
За счёт стандарта CNI Kubernetes может работать с разными сетевыми реализациями без жёсткой привязки к одному поставщику или одному подходу.
Какие CNI-плагины встречаются чаще всего
Среди известных CNI-плагинов часто упоминают Calico, Flannel и Weave. Они решают одну и ту же базовую задачу, но по-разному строят маршрутизацию, изоляцию и сетевую топологию.
Одни варианты делают упор на простую оverlay-сеть между узлами. Другие лучше подходят для контроля сетевых политик и маршрутизации без лишних туннелей. Конкретный выбор зависит от архитектуры кластера, требований к изоляции и особенностей среды, где развёрнут Kubernetes.
Почему сеть Kubernetes кажется сложной
Сеть Kubernetes выглядит сложной из-за количества абстракций. В работе участвуют поды, сервисы, DNS, kube-proxy, сетевые плагины, правила публикации наружу и политики доступа между приложениями.
При этом каждая часть решает отдельную задачу. Под получает адрес и запускает приложение. Service даёт стабильную точку входа. kube-proxy направляет трафик. CNI обеспечивает связность между узлами. NetworkPolicy ограничивает, кто с кем может говорить. Если разложить модель по этим уровням, картина становится заметно яснее.
Как кратко запомнить сетевую модель Kubernetes
Сетевую модель Kubernetes удобно помнить как четыре вида связи: контейнер с контейнером, под с подом, под с сервисом и внешний клиент с сервисом.
- Контейнеры внутри одного пода общаются через localhost.
- Поды общаются друг с другом по IP внутри плоской сети кластера.
- Service даёт стабильный адрес для доступа к группе подов.
- Внешний трафик попадает в кластер через NodePort, LoadBalancer, Ingress и связанные механизмы.
Если понимать именно эту схему, дальше уже проще разбираться в деталях реализации, диагностике сетевых проблем и выборе подходящего CNI-плагина.
