Выставить входной контроллер ngnix в качестве набора демонов

Question

Я пытаюсь установить и использовать nginx-ingress для предоставления служб, работающих в кластере kubernetes, и я следую этим инструкциям .

На шаге 4 отмечается, что:

Если вы создали набор демонов, порты 80 и 443 контейнера контроллера Ingress сопоставляются с теми же портамиузел, где работает контейнер.Чтобы получить доступ к контроллеру Ingress, используйте эти порты и IP-адрес любого узла кластера, на котором работает контроллер Ingress.

Это означает, что набор демонов будет прослушивать порты 80 и 443 для переадресации.входящий трафик в службу отображается в конфигурационном файле ingress.yaml.

Но после выполнения инструкции 3.2 kubectl apply -f daemon-set/nginx-ingress.yaml был создан набор демонов, но ничего не прослушивалось на 80 или 443во всех узлах кластера.

Есть ли проблема с инструкцией по установке или я что-то там упустил.

Answer 1

Как указано Hang du (+1) В соответствии с настройками по умолчанию в вашем кластере для --proxy-mode:

Какой режим прокси использовать: 'userspace' (старше) или «iptables» (быстрее) или «ipvs».Если пусто, используйте лучший доступный прокси ( в настоящее время iptables ).Если выбран прокси-сервер iptables, независимо от того, каким образом, но версии ядра или версий iptables недостаточно, это всегда приводит к прокси пользовательского пространства.

При условии, что в kube-system установлен контроллер nginx-ingress-controller-xxxпробел вы можете использовать эту команду для проверки этих параметров на вашей стороне:

sudo iptables-save | grep $(kubectl get pods -n kube-system -o wide | grep nginx-ingress-controller-xxx | awk '{print $6}')

Более подробную информацию о iptables/netfilter вы можете найти здесь и здесь .

Дополнительные ресурсы:

• Сетевые плагины
• Представляем kube-iptables-tailer

Обновление :

HostNetwork - определяет, может ли модуль использовать пространство имен сети узла .Это дает модулю доступ к устройству обратной связи, службам, прослушивающим локальный хост, и может использоваться для отслеживания сетевой активности других модулей на том же узле.

В дополнение к ответу выше:

Чтобы привязать порты 80 и 443 непосредственно к сетевым интерфейсам узлов Kubernetes, вы можете настроить hostNetwork: true (но это не рекомендуется):

Включение этой опции предоставляет каждому системному демону доступ квходной контроллер NGINX на любом сетевом интерфейсе, включая обратную петлю хоста.Пожалуйста, оцените влияние, которое это может оказать на безопасность вашей системы.

Answer 2

Это не типичный Listen, который вы можете получить из вывода netstat.Это "слушается" iptables.Ниже приведены правила iptables для входного контроллера на узле моего кластера.

-A CNI-DN-0320b4db24e84e16999fd -s 10.233.88.110/32 -p tcp -m tcp --dport 80 -j CNI-HOSTPORT-SETMARK
-A CNI-DN-0320b4db24e84e16999fd -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.233.88.110:80
-A CNI-DN-0320b4db24e84e16999fd -s 10.233.88.110/32 -p tcp -m tcp --dport 443 -j CNI-HOSTPORT-SETMARK
-A CNI-DN-0320b4db24e84e16999fd -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.233.88.110:443

10.233.88.110 - это ip-адрес входящего контроллера, работающего на этом узле.

$ kubectl get pod -n ingress-nginx -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP              NODE          NOMINATED NODE   READINESS GATES
ingress-nginx-controller-5rh26   1/1     Running   1          77d   10.233.83.110   k8s-master3   <none>           <none>
ingress-nginx-controller-9nnwl   1/1     Running   1          77d   10.233.88.110   k8s-master2   <none>           <none>
ingress-nginx-controller-ckkb2   1/1     Running   1          77d   10.233.68.111   k8s-master1   <none>           <none>

Редактировать Когда запрос поступает на порт 80/443, iptables будет применять правило DNAT к этому запросу, которое изменяет целевой IP-адрес на IP-адрес входного контроллера.Фактическое прослушивание находится внутри контейнера контроллера входа.