Вопрос или проблема
Окружение:
Kubernetes мастер: 192.168.174.110
Kubernetes рабочий узел-01: 192.168.174.125
Kubernetes рабочий узел-02: 192.168.174.126
Версия Kubernetes: v1.31.2-1.1
Метод установки: kubeadm init
ОС хоста: Ubuntu 22.04 LTS
CNI и версия: calico v3.29.0
CRI и версия: containerd://2.0.0
Все узлы kube-proxy используют режим прокси iptables.
root@k8s-master-01:/download# kubectl logs kube-proxy-8bsgh -n kube-system
I1 126 06:45:53.566881 1 server_linux.go:66] “Использование прокси iptables”
Мне удалось успешно связаться через веб-браузер на ноутбуке, получив доступ к http://192.168.174.110:32670.
Кроме того, я проверил правила iptables и не нашел никаких связанных правил DNAT для порта 32670. Я также использовал команду “netstat -nat|grep 32670” на хосте Kubernetes мастер, чтобы проверить наличие открытых портов, связанных с 32670, но их не было.
Поэтому я не понимаю, как порт 32670 здесь направляет запросы трафика на конечный узел пода? Пожалуйста, помогите мне объяснить это, спасибо.
Ответ или решение
Стратегия коммуникации и рабочий принцип между k8s Service типа NodePort и iptables
В рамках вашей среды Kubernetes с версией v1.31.2-1.1 и настройкой, использующей kubeadm для установки, важно понимать, как работает NodePort сервис и как он взаимодействует с iptables для маршрутизации сетевого трафика. Ниже представлен подробный разбор этого механизма.
Основы работы Kubernetes Service и NodePort
Kubernetes Service обеспечивает абстракцию для доступа к набору Pod’ов. Один из популярных типов сервисов — NodePort. Этот тип сервиса позволяет вам получать доступ к приложениям, работающим в ваших Pod’ах, через статический порт на каждом узле кластера. NodePort назначает определенный порт (в вашем случае это 32670) и перенаправляет трафик на соответствующий порт типа ClusterIP (обычно на другой порт, на котором работает ваш сервис в кластере).
Стратегия маршрутизации с использованием iptables
В конфигурации, где все узлы кластера используют режим проксирования iptables, kube-proxy создает правила iptables, которые помогают в маршрутизации трафика. Основные шаги этого процесса включают:
-
Создание правил iptables: kube-proxy, работающий в режиме iptables, отвечает за генерацию необходимых правил, которые обрабатывают вхождения и выходы трафика. Он создает правила, которые перенаправляют трафик с порта NodePort на соответствующий Pod.
-
Обработка трафика: Когда клиент отправляет запрос на порт 32670 на IP-адрес вашего мастер-узла (192.168.174.110), iptables ищет соответствующее правило, чтобы определить, каким образом направить этот трафик. В вашем случае правила могут не быть видны в видео iptables, потому что kube-proxy обновляет их динамически при изменениях в состоянии кластера.
-
Обработка DNAT: Если вы не видите правил DNAT для порта 32670, это может быть связано с тем, что правила были созданы не в текущий момент или их настройки могут конфликтовать с динамическими изменениями в состоянии кластера. DNS запись указывает kube-proxy, какой сервис должен обрабатывать входящий трафик.
Отсутствие прослушивающих портов
Команда netstat -nat|grep 32670 не показала никаких активных прослушиваний на порту 32670 по двум основным причинам:
-
Динамическое управление трафиком: В Kubernetes часто используется механизм виртуализации сетевой инфраструктуры, что делает допустимым отсутствие физического прослушивания на узле. Входящий трафик на узел перенаправляется на соответствующий Pod через kube-proxy.
-
Кластерный IP: На уровне сети ваши Pod’ы могут находиться на разных узлах, и порты, открытые для насужд по умолчанию на ваших этих узлах, могут не отражать общий доступ в рамках кластера. Вместо этого правила iptables динамически перенаправляют трафик.
Заключение
Ваша проблема с отсутствием наблюдаемых правил DNAT и прослушиваемых портов типична для среды Kubernetes с использованием сервисов типа NodePort и управления маршрутизацией с помощью iptables. kube-proxy работает, управляя сетевыми правилами и маршрутизацией, что позволяет направлять трафик к нужным Pod’ам, даже если это не явно видно на уровне сетевого интерфейса. Если у вас есть дополнительные вопросы по этой теме или необходима помощь в устранении неполадок, всегда можно обратиться за поддержкой к сообществу Kubernetes.
Следует также учесть, что техподдержка и дальнейшее исправление сетевых правил может потребовать дополнительного анализа логов и конфигураций ваших сервисов.