Как Kubernetes NodePort сервисы с Service.spec.externalTrafficPolicy = Local route traffic?

Кажется, есть два противоречивых объяснения того, как сервисы NodePort маршрутизируют трафик. Сервисы могут направлять трафик к одному из двух, а не к обоим:

  1. Nodes (through the kube-proxy) According to kubectl explain Service.spec.externalTrafficPolicy and this article that adds more detail, packets incoming to NodePort services with Service.spec.externalTrafficPolicy=Local set get routed to a kube-proxy, which then routes the packets to the corresponding pods its running.
    • This kube-proxy networking documentation further supports this theory adding that endpoints add a rule in the service's IPtable that forwards traffic to nodes through the kube-proxy.
  2. Модули: службы обновляют свои IP-таблицы с endpoints, которые содержат IP-адреса для модулей, к которым они могут выполнять маршрутизацию. Кроме того, если вы удалите селекторы меток вашей службы и отредактируйте конечные точки вы можете изменить, куда направляется ваш трафик.

Если один из них правильный, значит, я что-то неправильно понимаю.

  • Если службы направляют к узлам, то почему я могу редактировать endpoints, не нарушая IPtables?
  • Если сервисы направляются к модулям, то почему сервисы будут испытывать трудности с маршрутизацией к узлам, когда установлено Service.spec.externalTrafficPolicy?

kubernetes kubernetes-service
person mikeLundquist    schedule 04.02.2020    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Служба - это виртуальный адрес / порт, управляемый kube-proxy. Службы перенаправляют трафик на связанные с ними конечные точки, которые обычно являются модулями, но, как вы упомянули, могут быть установлены на любой IP-адрес / порт назначения.

NodePort Service не изменяет конечную точку службы, NodePort разрешает внешний трафик в Сервис через порт на узле.

Нарушение службы

kube-proxy может использовать 3 метода для реализовать пересылку службы от узла к месту назначения.

  • прокси пользователя
  • iptables
  • ipvs

Большинство кластеров используют iptables, что описано ниже. Я использую термин «пересылка» вместо «маршрут», потому что службы используют преобразование сетевых адресов (или прокси) для «пересылки» трафика вместо стандартной сетевой маршрутизации.

Служба ClusterIP - это виртуальная сущность, управляемая kube-proxy. Эта комбинация адреса / порта доступна на каждом узле в кластере и перенаправляет любой локальный (pod) служебный трафик на IP-адрес и порт конечных точек.

                                         / Pod (remote node)
Pod -- ClusterIP/Port -- KUBE-SVC-NAT  --  Pod
                                         \ Pod (remote node)

Служба с NodePort такая же, как указано выше, с добавлением способа перенаправления внешнего трафика в кластер через узел. kube-proxy управляет дополнительным правилом для отслеживания внешнего трафика и перенаправления его в те же правила службы.

Ext --     NodePort   \                / Pod (remote node)
                        KUBE-SVC-NAT --  Pod
Pod -- ClusterIP/Port /                \ Pod (remote node)

Параметр externalTrafficPolicy=Local заставляет службу NodePort использовать только локальный модуль для обслуживания входящего трафика. Это позволяет избежать сетевого перехода, что устраняет необходимость перезаписывать источник пакета (через NAT). Это приводит к тому, что реальный сетевой IP-адрес поступает в модуль, обслуживающий соединение, а не один из узлов кластера, являющийся исходным IP-адресом.

Ext --     NodePort   \                  Pod (remote node)
                        KUBE-SVC-NAT --  Pod (local)
Pod -- ClusterIP/Port /                  Pod (remote node)

iptables

Я рекомендую попытаться отследить соединение от источника к месту назначения для службы или порта узла на хосте. Это требует некоторых знаний iptables, но я думаю, что это того стоит.

Чтобы перечислить все IP / порты служб, которые будут перенаправлены:

iptables -vnL -t nat KUBE-SERVICES

Чтобы вывести список всех узловых портов, которые будут перенаправлены:

iptables -vnL -t nat KUBE-NODEPORTS

Когда у вас есть правило, вы можете пропустить KUBE-SVC-XXX "целевых" правил в полном выводе.

iptables -vnL -t nat | less

person Matt    schedule 05.02.2020
comment
Так как же можно применить externalTrafficPolicy к трафику с балансировкой нагрузки? Знает ли балансировщик нагрузки, на каких узлах работают соответствующие поды? - person mikeLundquist; 05.02.2020
comment
Для ручного фунта со службой NodePort проверка работоспособности фунта завершится ошибкой на узлах, на которых не запущены поды. Вы можете использовать селектор узлов в развертывании, чтобы ограничить узлы, которые вы соответствуете в конфигурации lb. - person Matt; 06.02.2020
comment
Для type: LoadBalancer только необходимые узлы должны быть перенесены на фунт (по крайней мере, на AWS. Я думаю, это может отличаться в зависимости от cloud-provider) - person Matt; 06.02.2020