⚙️ Теория
🌐 Kubernetes network model в двух пунктах
Базовые ожидания Kubernetes:
- каждый Pod получает собственный IP;
- Pod может обращаться к другому Pod без NAT между pod-сетями (в модели Kubernetes).
CNI-плагин реализует эту модель в конкретной инфраструктуре.
🧩 Что делает CNI
CNI (Container Network Interface) определяет контракт между runtime/kubelet и сетевым плагином:
ADD: подключить сетевой интерфейс и маршруты pod;DEL: удалить настройки;CHECK(если поддерживается): верификация состояния.
Это описано в CNI SPEC.
🔌 Service networking отдельно от CNI
Важно разделять:
- pod networking (обычно CNI);
- service virtual IP/load-balancing (kube-proxy или eBPF data plane).
Ошибки в одном слое не всегда означают проблему другого.
⚠️ Типичные инциденты
- overlap CIDR pod/network с корпоративными сетями;
- MTU mismatch (особенно при overlay);
- неверная network policy, которая режет service-to-service трафик;
- асимметричная маршрутизация между node.
❓ Что нужно уметь объяснить
Почему "у pod есть IP" еще не означает, что сеть здорова?
Потому что нужен полный путь: DNS -> Service -> Pod, плюс policy/mTLS/routing. Любой из этапов может ломать связь.
Почему MTU критичен для overlay?
Инкапсуляция уменьшает эффективный payload. Если MTU не согласован, получаем фрагментацию/дропы и рост latency.
Где граница ответственности CNI?
CNI обеспечивает pod connectivity; бизнес-маршрутизация и часть L7-функций лежат выше (ingress/service mesh/app).
🧪 Практика
1. Проверка pod/service connectivity
kubectl get pods -A -o wide
kubectl get svc -A
kubectl exec -it <pod> -- sh -c 'ip a; ip route; nslookup kubernetes.default'
2. Проверка network policies
kubectl get networkpolicy -A
kubectl describe networkpolicy -n <ns> <name>
3. Базовые guardrails
- планировать pod CIDR/service CIDR без overlap;
- стандартизировать MTU для выбранного CNI режима;
- иметь smoke-tests на east-west connectivity в CI/CD.
🧾 Вывод
CNI это фундамент сетевой работоспособности кластера. Надежность достигается не выбором "модного" плагина, а контролем CIDR/MTU/policy и регулярной диагностикой pod-to-pod/service путей.