Объясни, как пакет от пода А попадает в под B на другой ноде.

Требования сетевой модели Kubernetes

Kubernetes требует, чтобы каждый Pod имел уникальный IP-адрес и мог напрямую общаться с любым другим Pod без NAT. Это называется «flat network model». Реализацию обеспечивает CNI-плагин (Container Network Interface): Calico, Flannel, Cilium, Weave и др.

Путь пакета: шаг за шагом

1. Пакет покидает контейнер Pod A

Контейнер отправляет пакет на IP Pod B (например, 10.244.2.5). Пакет попадает в виртуальный сетевой интерфейс пространства имён Pod — eth0 внутри Pod. На другом конце этого veth-pair — интерфейс veth-xxxxx на ноде.

2. Обработка на ноде Pod A

Linux-мост (cbr0 у Flannel, или нет моста у Calico в режиме BGP) или eBPF-hook принимает пакет. Ядро проверяет таблицу маршрутизации ноды:

ip route show
# 10.244.2.0/24 via 192.168.1.3 dev eth0  # маршрут к подсети ноды B

Маршрут говорит: «Подсеть 10.244.2.0/24 находится на ноде B (192.168.1.3) — отправь туда».

3. Инкапсуляция (зависит от CNI)

• Flannel (VXLAN): пакет оборачивается в UDP/VXLAN (порт 8472). Внешний IP — IP ноды B. Flannel daemon (flanneld) на ноде A выполняет инкапсуляцию через интерфейс flannel.1.
• Calico (BGP): без инкапсуляции. Calico настраивает BGP-пиринг между нодами, маршруты распространяются нативно. Пакет идёт как обычный IP-пакет с MAC-адресом шлюза.
• Cilium (eBPF): eBPF-программа в ядре перехватывает пакет и выполняет туннелирование или прямую маршрутизацию без userspace-процессов.

4. Транзит по физической сети

Пакет (инкапсулированный или нет) проходит через физический коммутатор/роутер дата-центра от ноды A к ноде B по их реальным IP-адресам.

5. Приём на ноде Pod B

Flannel daemon (или eBPF-hook) на ноде B декапсулирует пакет, восстанавливая оригинальный IP Pod A → Pod B. Затем пакет маршрутизируется через veth-pair в сетевое пространство имён Pod B — и попадает на eth0 Pod B с адресом назначения 10.244.2.5.

Роль iptables/kube-proxy

При обращении через Service (ClusterIP) в цепочку вмешивается kube-proxy: он добавляет правила iptables (или ipvs), которые выполняют DNAT — подменяют IP сервиса на IP одного из Pod-эндпоинтов. После DNAT пакет идёт по описанному выше пути.

# Посмотреть правила kube-proxy для Service
iptables -t nat -L KUBE-SERVICES -n --line-numbers

# Посмотреть маршруты на ноде
ip route show table main

# Посмотреть VXLAN FDB (Flannel)
bridge fdb show dev flannel.1

Подводные камни

• MTU и фрагментация: VXLAN добавляет 50 байт оверхеда. Если MTU ноды 1500, Pod должен использовать MTU 1450. Неправильный MTU в ConfigMap flannel-config даёт silent packet drops для больших пакетов.
• Network Policy не работает без поддержки CNI: Flannel сам по себе не реализует NetworkPolicy — нужен дополнительный компонент (Calico в режиме policy-only поверх Flannel). Calico и Cilium реализуют политики встроенно.
• BGP требует поддержки от инфраструктуры: Calico в BGP-режиме без инкапсуляции работает только если физическая сеть разрешает BGP-анонсы с нод (обычно on-prem). В managed cloud (EKS, GKE) часто используют overlay.
• kube-proxy в iptables-режиме не масштабируется: при тысячах Service правила iptables становятся огромными, latency растёт. Переходите на ipvs-режим или Cilium без kube-proxy.
• SNAT при выходе из кластера: при обращении Pod к внешним ресурсам нода выполняет SNAT (IP ноды заменяет IP Pod). Внешний сервис видит IP ноды, а не Pod. Это усложняет whitelist'инг.
• Отладка сложна: пакет проходит через несколько netns, veth, туннели. Используйте tcpdump на интерфейсах ноды и nsenter для входа в netns Pod.

• Не упоминать CNI
• Говорить, что весь трафик идет через API server
• Путать ClusterIP с Pod IP

• Разделяет direct Pod IP и Service path
• Понимает veth namespace host path
• Знает overlay vs routed CNI