Как исправить Kubernetes Ingress Controller, отключающий узлы от кластера
У меня возникли проблемы с установкой Ingress Controller в моем локальном кластере (созданном с помощью Kubespray, с запуском MetalLB для создания LoadBalancer.).
Я пытался использовать nginx, traefik и kong, но все получили одинаковые результаты.
Я устанавливаю свою диаграмму nginx helm, используя следующие значения.yaml:
controller:
kind: DaemonSet
nodeSelector:
node-role.kubernetes.io/master: ""
image:
tag: 0.23.0
rbac:
create: true
С командой:
helm install --name nginx stable/nginx-ingress --values values.yaml --namespace ingress-nginx
Когда я развертываю входной контроллер в кластере, создается служба (например, nginx-ingress-controller для nginx). Эта служба относится к типу LoadBalancer и получает внешний IP-адрес.
При назначении этого внешнего IP-адреса узел, связанный с этим внешним IP-адресом, теряется (статус «Не готов»). Однако, когда я проверяю этот узел, он все еще работает, он просто отрезан от другого узлы, он даже не может пропинговать их (маршрут не найден). Когда я удаляю службу (не остальную часть диаграммы nginx helm), все работает, и Ingress работает. Я также пытался установить nginx/traefik/kong без LoadBalancer, используя NodePorts или внешние IP-адреса в службе, но получаю тот же результат.
Кто-нибудь признает это поведение? Почему вход все еще работает, даже когда я удаляю службу nginx-ingress-controller?
Привет @A_Suh, спасибо за ответ! Внешний IP-адрес для службы — это IP-адрес одного из 5 узлов в моем кластере. Назовем этот узел X. Когда сервис создан и получает внешний IP-адрес, X получает статус «Не готов». Тем не менее, X не отключен, так как я все еще могу войти в него, и kubelet все еще работает. В тот момент, когда служба установлена в моем кластере, X больше не может получить доступ к главному узлу, поэтому его проверка работоспособности больше не может достигать главного узла. Когда я пингую главный узел (или любой другой узел) с X, я получаю сообщение «Узел назначения недоступен».
это странно, что ваш DHCP-сервер назначает IP-адрес службе, которая уже была назначена узлу. Вы попытаетесь вручную установить статический IP-адрес для своей входящей службы? то есть apiVersion: v1 kind: Service spec: type: LoadBalancer loadBalancerIP: 10.10.10.10
Ага, значит я что-то не так настроил. Поскольку балансировщик нагрузки работает внутри кластера, не должен ли IP-адрес балансировщика нагрузки быть IP-адресом одного из узлов внутри кластера? Я настроил MetalLB для предоставления диапазона IP-адресов балансировщикам нагрузки, и эти IP-адреса являются IP-адресами узлов в моем кластере. Извините, я новичок в Kubernetes и думаю, что что-то упускаю?
Нет, не должно быть одинаково. Вы предоставляете доступ к сервису как отдельный объект. Поэтому, пожалуйста, измените диапазон IP-адресов, чтобы LB не пересекался с IP-адресами узла.
Я пытался использовать IP-адрес за пределами моего кластера, но когда я проверяю службы, внешний IP-адрес моего входного контроллера остается ожидающим? Кроме того, когда я просматриваю документацию MetalLB, я читаю: «В самом простом сценарии пул состоит из IP-адресов узлов Kubernetes, но IP-адреса также могут быть выданы DHCP-сервером». (kubernetes.github.io/ingress-nginx/deploy/baremetal) Поскольку я не использую DHCP-сервер для раздачи IP-адресов, мне кажется, что я должен предоставлять IP-адреса узлов в моем кластере? Или я что-то упускаю?
о, вы были правы, для MetalLB вы должны предоставить IP-адреса узлов. Вам удалось решить проблему?
Привет @A_Suh, мне только что удалось решить эту проблему. Оказывается, вы были правы, и мне нужно было указать IP-адреса вне кластера, чтобы исправить это. Причина, по которой это сначала не сработало, заключалась в том, что DHCP не был настроен в моей сети. Спасибо за вашу помощь!
Ответы 1
После долгих поисков мы наконец нашли рабочее решение этой проблемы.
Как упоминал @A_Suh, пул IP-адресов, которые использует metallb, должен содержать IP-адреса, которые в настоящее время не используются одним из узлов в кластере. Добавляя новый диапазон IP-адресов, который также настроен на сервере DHCP, metallb может использовать ARP для привязки одного из IP-адресов к одному из узлов.
Например, в моем кластере из 5 узлов (kube11-15): когда metallb получает диапазон 10.4.5.200/31 и выделяет 10.4.5.200 для моего nginx-ingress-controller, 10.4.5.200 связан с kube12. На запросы ARP для 10.4.5.200 все 5 узлов отвечают kube12, и трафик будет направляться на этот узел.
Не могли бы вы уточнить это - «узел, связанный с этим внешним IP-адресом, потерян». Вы имеете в виду, что узел и служба входа пытаются назначить один и тот же общедоступный IP-адрес?