абдей

Анатомия сквозной сетевой связности в самостоятельно управляемом Kubernetes на базе RKE2

Автор: Cuong Truong
Дата публикации: 2 октября 2026 года
Время чтения оригинала: 19 минут
Оригинал: Anatomy of End-to-End Connectivity in Self-Managed Kubernetes with RKE2

Перевод статьи.

Сколько промежуточных узлов проходит запрос, прежде чем достигнет вашего Pod? В этой статье мы проследим каждый такой переход в самостоятельно управляемом кластере Kubernetes, построенном на RKE2.

Зачем нужна полная картина взаимодействий

Большинство сетевых инцидентов в Kubernetes связано не с поломкой отдельного компонента, а с нарушением связи между двумя компонентами. Ingress возвращает 502, Pod не может разрешить доменное имя, новый узел никак не переходит в состояние Ready — в каждом случае это одно разорванное звено длинной цепи.

В управляемых сервисах — EKS, GKE, AKS — провайдер скрывает большую часть этой цепи. Когда вы управляете кластером самостоятельно, за всё отвечаете вы: за балансировщик нагрузки, порты между узлами, CNI, kube-proxy, ingress-контроллер и DNS. Никто не будет отлаживать их за вас.

В статье рассматриваются четыре потока взаимодействия, от внешнего мира вглубь кластера:

Управление: kubectl → kube-apiserver → etcd → kubelet → контейнер.
Взаимодействие Pod между собой: CNI объединяет Pod на разных узлах в единую плоскую сеть.
Входящий трафик: клиент из Интернета → балансировщик нагрузки → ingress → Service → Pod.
DNS: Pod → NodeLocalDNS → CoreDNS → вышестоящий DNS-сервер.

Каждый поток сопоставляется с тем, как он реализован в RKE2, на основе официальной документации docs.rke2.io. Три схемы служат общими иллюстрациями; если поведение RKE2 отличается от показанного на схеме, это оговаривается в тексте.

Общая картина: всё взаимодействует через kube-apiserver

Kubernetes построен по звездообразной архитектуре: kube-apiserver находится в центре, а остальные компоненты подключаются к нему как лучи. Никто, кроме apiserver, не взаимодействует с etcd, и ни один компонент не отдаёт команды другому напрямую.