Обзор
Коммуникация между подами в Kubernetes опирается на сетевое подключение между контейнерами, независимо от того, находятся они на одном узле или на разных. Способ коммуникации зависит от расположения подов и конфигурации сети.
Лучшая практика: используй Service DNS
Настоятельно рекомендуется использовать Kubernetes Service DNS для коммуникации между подами вместо прямых IP-адресов подов. Это критично, потому что:
- Поды временны и их IP-адреса меняются после передеплоя
- Service DNS предоставляет стабильную, постоянную точку входа для коммуникации между подами
- Такой подход скрывает изменения в базовой инфраструктуре
Коммуникация на одном узле
Когда два пода работают на одном хосте:
- Трафик идёт от виртуального сетевого интерфейса Pod1 к docker bridge (
cbr0)
- Мост напрямую отправляет пакет Pod2
- Участие физического сетевого интерфейса не требуется
Коммуникация между узлами
Когда поды работают на разных узлах, путь коммуникации сложнее:
- Pod1 (192.168.2.10/24 на node1) отправляет трафик, предназначенный для Pod2 (192.168.3.10/24 на node2)
- Поскольку поды находятся в разных подсетях, пакет идёт на шлюз Pod1 (
cbr0)
- Шлюз отправляет трафик на физический интерфейс node1
- Физический маршрутизатор node1 маршрутизирует трафик на физический маршрутизатор node2
- Трафик доходит до node2 и проходит через его мост (
cbr1) к Pod2
Роль CNI-плагина
Плагины Container Network Interface (CNI) вроде Calico упрощают маршрутизацию между узлами за счёт:
- Автоматического добавления маршрутов для всех IP-адресов docker bridge на всех узлах
- Избавления от необходимости ручной настройки маршрутов на физических маршрутизаторах
- Предоставления возможностей сетевых политик и безопасности
Использование CNI-плагина — это рекомендуемый подход для production Kubernetes-кластеров.