Хороший вопрос, чтобы начать изучать что-то новое (также для меня):
Ваши проблемы связаны с kube-proxy по умолчанию в кластере K8s, он работает в iptables mode.
Каждый узелв кластере Kubernetes работает Kube-прокси. Kube-proxy отвечает за реализацию формы виртуального IP-адреса для служб.
В этом режиме kube-proxy следит за плоскостью управления Kubernetes для добавления и удаления объектов Service и Endpoint. Для каждого Сервиса он устанавливает правила iptables, которые захватывают трафик на IP-адрес и порт кластера Сервиса и перенаправляют этот трафик на один из внутренних наборов Сервиса. Для каждого объекта Endpoint он устанавливает правила iptables, которые выбирают бэкэнд Pod.
Узловые компоненты kube-proxy :
- kube-proxy - это сетевой прокси, который работает на каждом узле в кластере и реализует часть концепции службы Kubernetes.
- kube-proxy поддерживает сетевые правила на узлах. Эти сетевые правила разрешают сетевое взаимодействие с вашими модулями из сетевых сеансов внутри или вне кластера.
- kube-proxy использует уровень фильтрации пакетов операционной системы, если он есть, и он доступен. В противном случае, kube-proxy пересылает сам трафик.
Как описано здесь :
Из-за этих правил iptables,всякий раз, когда пакет предназначен для IP-адреса службы, он DNATed (DNAT = трансляция сетевого адреса назначения), что означает, что IP-адрес назначения изменяется с IP-адреса службы на один из IP-адресов конечных точек, выбранных случайным образом с помощью iptables. Это обеспечивает равномерное распределение нагрузки между внутренними модулями.
Когда происходит это DNAT, эта информация сохраняется в conntrack - таблице отслеживания соединений Linux (хранит преобразования из 5 кортежей, которые iptables выполнил: protocol, srcIP,srcPort, dstIP, dstPort). Это связано с тем, что когда ответ возвращается, он может отменить DNAT, что означает изменение исходного IP-адреса с Pod IP на IP-адрес службы. Таким образом, клиент не знает, как поток пакетов обрабатывается за кулисами.
Существуют также различные режимы, вы можете найти дополнительную информацию здесь
Во время инициализации кластера вы можете использовать --service-cidr строковый параметр Default: "10.96.0.0/12"
- ClusterIP: IP-адрес, назначенный услуге
Kubernetes назначает стабильный, надежный IP-адрес каждой вновь создаваемой услуге (ClusterIP) из пула кластера доступных IP-адресов службы. Kubernetes также назначает имя хоста для ClusterIP, добавляя запись DNS. ClusterIP и имя хоста являются уникальными в пределах кластера и не изменяются в течение жизненного цикла Сервиса. Kubernetes освобождает ClusterIP и имя хоста только в том случае, если Сервис удален из конфигурации кластера. Вы можете связаться с исправным Pod, на котором запущено ваше приложение, используя ClusterIP или имя хоста Сервиса.
- Pod IP: IP-адрес, назначенный данному Pod.
Kubernetes назначает IP-адрес (Pod IP) виртуальному сетевому интерфейсу в пространстве имен сети Pod из диапазона адресов, зарезервированных для Pod на узле. Этот диапазон адресов является подмножеством диапазона IP-адресов, назначенного кластеру для модулей, который можно настроить при создании кластера.
Ресурсы:
Надеюсь, это помогло