Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

CNI_POD_COMMUNICATION_FAIL Сетевое оборудование и VPN

Траблшутинг сети контейнеров: CNI плагины Calico и Flannel в Kubernetes

Обновлено: 25.08.2026 · Официальная документация ↗
  • Поды на разных нодах кластера Kubernetes не пингуются и не могут установить TCP соединение (Cross-node Pod-to-Pod failure).
  • Поды зависают в статусе ContainerCreating с ошибкой Failed to setup network for sandbox: plugin type="calico" failed.
  • BGP сессии между нодами кластера Calico находятся в состоянии Idle / Connect.
  • DNS запросы от подов к CoreDNS завершаются по таймауту i/o timeout (53).

1. Проверка статуса CNI и BGP-пиринга в Calico

# Установка утилиты calicoctl
calicoctl node status

# Проверка IP Pool и режима инкапсуляции (VXLAN / IPIP)
calicoctl get ippool -o wide

2. Устранение неверного выбора сетевого интерфейса (IP Autodetection)

Если у сервера несколько сетевых адаптеров, CNI может ошибочно привязаться к неверному интерфейсу (например, к docker0 или VPN):

# Редактирование DaemonSet Calico-node
kubectl -n kube-system set env daemonset/calico-node IP_AUTODETECTION_METHOD=interface=eth0,ens*

# Для Flannel (аргумент запуска в ConfigMap kube-flannel-cfg):
"--iface=eth0"

3. Проверка прохождения инкапсулированного трафика между нодами

Убедитесь, что межсетевые экраны между нодами кластера не блокируют оверлейные порты:

  • Calico (BGP): TCP порт 179;
  • Calico (IPIP): IP протокол 4 (IPIP encapsulation);
  • Calico / Flannel (VXLAN): UDP порт 4789 (или 8472);
  • WireGuard (если включено шифрование): UDP порт 51820 / 51821.
# Тест прохождения VXLAN UDP порта между нодами
nc -z -v -u <IP_ДРУГОЙ_НОДЫ> 4789

4. Проверка MTU оверлейной сети CNI

Оверхед VXLAN составляет 50 байт, IPIP — 20 байт. Если на физическом интерфейсе MTU 1500, MTU в CNI должно быть уменьшено:

# В ConfigMap calico-config (veth_mtu):
# 1500 - 50 (VXLAN) = 1450
kubectl -n kube-system edit configmap calico-config

5. Проверка правил фильтрации Forwarding в Linux

# Проверка политики FORWARD ядра (должна быть ACCEPT)
iptables -P FORWARD ACCEPT

# Проверка включения маршрутизации пакетов в sysctl
sysctl net.ipv4.ip_forward
sysctl net.bridge.bridge-nf-call-iptables
💡 Практика специалистов: Никогда не выставляйте значение MTU интерфейсов CNI равным MTU физической сети (1500). Несоответствие MTU оверлея и физической сети (DF=1) приводит к скрытому зависанию gRPC и TLS соединений между микросервисами при передаче полезной нагрузки более 1450 байт.

Частые вопросы (FAQ)

Почему трафик между подами внутри одной ноды работает, а между разными нодами нет?

Внутри одной ноды пакеты коммутируются локальным veth-мостом (L2). Между нодами трафик заворачивается в туннель VXLAN/IPIP или маршрутизируется через BGP. Если на внешнем фаерволе заблокированы UDP 4789, IP Protocol 4 или TCP 179, кросс-нодовый трафик сбрасывается.

Что делает параметр IP_AUTODETECTION_METHOD в Calico?

Он указывает демону calico-node, по какому правилу определять физический IP-адрес хоста для построения BGP-пиринга и туннелей (по регулярному выражению имени интерфейса, CIDR подсети или первому публичному IP).

В чем разница между режимами Calico IPIP, VXLAN и Non-encapsulated (Host Routing)?

IPIP инкапсулирует пакет в IP-пакет (20 байт оверхед), работает только в IPv4. VXLAN упаковывает пакет в UDP (50 байт оверхед), работает в любых L3 сетях. Non-encapsulated не создает оверхеда, но требует, чтобы физическая сеть знала маршруты к Pod CIDR через BGP.

Почему при падении CNI ломаются все DNS-запросы в кластере?

Сервис CoreDNS работает в виде подов внутри кластера. При сбое сетевого плагина поды клиентов теряют маршрутизацию к виртуальным IP-адресам (ClusterIP) службы kube-dns.

Полезные материалы
Рекомендуем