Базовая модель сети Kubernetes
- Каждый Pod получает *уникальный* IP-адрес в пределах кластера, без NAT между Pod’ами. [kubernetes](https://kubernetes.io/ru/docs/concepts/cluster-administration/networking/)
- Pod’ы могут напрямую ходить друг к другу по IP (Pod-to-Pod), а приложения внутри одного Pod’а общаются через
localhostи общую network namespace. [kubernetes](https://kubernetes.io/ru/docs/concepts/cluster-administration/networking/) - Доступ к Pod’ам снаружи организуется через объекты Service (ClusterIP/NodePort/LoadBalancer) и, как правило, Ingress или Gateway API. [kubernetes](https://kubernetes.io/ru/docs/concepts/overview/what-is-kubernetes/)
CNI и реализация сетей
- Kubernetes сам по себе не реализует L3-сеть; он опирается на Container Network Interface (CNI) плагины: Calico, Flannel, Cilium, Weave, antrea и др. [kubernetes](https://kubernetes.io/ru/docs/concepts/cluster-administration/networking/)
- CNI отвечает за создание veth‑пар для Pod’ов, IPAM, маршрутизацию между нодами (overlay/underlay/BGP/iptables/eBPF), иногда — за NetworkPolicy. [8host](https://www.8host.com/blog/vnutrennee-ustrojstvo-seti-kubernetes/)
- Разные плагины по‑разному строят datapath: от простого VXLAN/GRE оверлея над L2/L3 до BGP-анонса PodCIDR в physical fabric или eBPF‑маршрутизации без iptables. [habr](https://habr.com/ru/companies/cloud4y/articles/1008692/)
Компоненты узлов: kube-proxy и iptables/eBPF
- На каждом worker/контроллер‑ноде работает
kube-proxy, который реализует сервисы (ClusterIP, NodePort) через iptables/ipvs или собственный прокси‑datapath. [redhat](https://www.redhat.com/en/topics/containers/what-is-kubernetes) - Kubernetes Service получает стабильный виртуальный IP (ClusterIP);
kube-proxyрасставляет rules, чтобы входящий трафик на этот IP балансировался по backend‑Pod’ам (endpoints). [kubernetes](https://kubernetes.io/ru/docs/concepts/cluster-administration/networking/) - Некоторые CNI (например, Cilium) могут заменять функциональность
kube-proxy, реализуя сервисный load‑balancing через eBPF на уровне ядра. [habr](https://habr.com/ru/companies/cloud4y/articles/1008692/)
Типы трафика: Pod, Service, внешний мир
- Pod-to-Pod: плоское адресное пространство, маршрутизация через CNI, без NAT, с опциональной фильтрацией NetworkPolicy. [kubernetes](https://kubernetes.io/ru/docs/concepts/cluster-administration/networking/)
- Pod-to-Service: приложение ходит по DNS‑имени (
my-svc.my-namespace.svc.cluster.local) или по ClusterIP; дальше работаетkube-proxy/eBPF‑LB. [kubernetes](https://kubernetes.io/ru/docs/concepts/overview/components/) - External-to-Service: ingress‑контроллеры (Nginx, Traefik, HAProxy, Envoy) или LoadBalancer Service получают внешний IP/порт и публикуют HTTP(S)/TCP‑сервисы наружу, часто с TLS‑терминацией. [kubernetes](https://kubernetes.io/ru/docs/concepts/overview/what-is-kubernetes/)
NetworkPolicy, multi-network и дополнительные аспекты
- NetworkPolicy — это firewall‑слой на уровне Pod, описывающий, какой трафик (Ingress/Egress) разрешён между Pod’ами/Namespace’ами/сетевыми группами; реализуется поддерживающим CNI. [kubernetes](https://kubernetes.io/ru/docs/concepts/cluster-administration/networking/)
- Поддерживаются дополнительные сетевые интерфейсы (Multus CNI и др.) для Pod’ов, которым нужен прямой доступ к L2/VLAN/SRIOV (NFV, телеком, HFT и т.п.). [habr](https://habr.com/ru/companies/cloud4y/articles/1008692/)
- Для Windows‑узлов используются специфические реализации (WinCNI, HNS), но логическая модель (Pod IP, Service, NetworkPolicy) остаётся такой же. [learn.microsoft](https://learn.microsoft.com/ru-ru/training/modules/apply-networking-concepts-to-windows-containers/4-networking-concepts-for-kubernetes-containers)
Чтобы сделать ответ полезнее: тебе больше интересно «под капотом» datapath CNI (iptables, VXLAN, BGP, eBPF) или практическая часть — как именно поднимать кластер и выбирать плагин под свою инфраструктуру (bare metal, облако, on-prem)?
(https://www.perplexity.ai/)
[file-name 000372_2026-06-12_07-15-55.txt]