LINUX.ORG.RU
решено Форум — Admin  

Не пингуется одна из нод k8s

 ,


0

1

Список воркер нод:

k8s-worker - домашняя машина за роутером

k8s-worker1 - облако

k8s-worker2 - облако

Eсть проблема с доступом подов к подам конкретной ноды(k8s-worker).

пинг из подов по узлам:

k8s-worker1->k8s-worker1 работет

k8s-worker2->k8s-worker2 работет

k8s-worker->k8s-worker работет

k8s-worker2->k8s-worker1 работет

k8s-worker1->k8s-worker2 работет

k8s-worker2->k8s-worker не работет

k8s-worker1->k8s-worker не работет

k8s-worker->k8s-worker1 не работет

Пинги подов внутри ноды проходят нормально, что у одной, что у другой, но при попытке пингануть поды на ноде k8s-worker c ноды k8s-worker1 пинги падают по таймауту. Если на k8s-worker запускается ingress-nginx-controller, то ингресы не создаются по тому же таймауту

Error from server (InternalError): error when creating "ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": failed to call webhook: Post "https://ingress-nginx-controller-admission.default.svc:443/networking/v1/ingresses?timeout=10s": context deadline exceeded

Если запустить контроллер ингреса на ноде k8s-worker1, то ингрес нормально создается и все работает штатно, если в ингресе прописаны роуты к подам находящиеся на ноде k8s-worker, то запросы виснут на таймауте.

kubectl get deployments,daemonsets,pods,svc -A -o wide - https://pastebin.com/VuuUkaFV

из сетевых настроек на локальной машине только прописывал внешний адрес на сетевой интерфейс в остальном сетевые настройки не отличаются от облачных нод.

[Match]
Name=enp2s0

[Network]
Address=<externalIP>/24
Gateway=192.168.1.1
DNS=8.8.8.8
DNS=8.8.4.4
DNS=77.88.8.88
DNS=77.88.8.2

[Address]
Address=192.168.1.117/24

в какую сторону нужно копать что смотреть еще?


Ответ на: комментарий от Mars36

Сомневаюсь, что такой вариант будет работать нормально

  • во-первых, как ты сам заметил, у тебя даже пинг не проходит
  • во-вторых, тебе нужно проверить, что есть доступ к портам нод через этот нестандартный вариант
  • в третьих, в конфигах kubelet’а и служебных подов «домашней ноды» наверное как-то нужно отразить, что ее внешний адрес другой
  • в четвертых, cni plugin должен согласиться работать в таких условиях

оно тебе надо? ну если только в академических целях, чтобы лучше понять, как оно работает

в нормальной ситуации ноды кластера должны быть в одном широковещательном домене

router ★★★★★
()
Ответ на: комментарий от Mars36

Ну удачи :)

Для начала нарисуй (для себя) схему, где у тебя располагаются все компоненты кластера (etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kube-proxy, kubelet) и как они взаимодействуют

потом начинай проверять, что работают те взаимодействия, которые идут между облаком провайдера и твоей домашней сетью. у тебя есть сетевые политики на стороне провайдера и nat в твоей домашней сети

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от Mars36

Вот идет пакет из интернета на extrenalIP(правильно понимаю что это белый ip, который выдает роутеру твой провайдер?) доходит до wan-интерфейса роутера и дальше как он попадает на сетевой интерфейс хоста за роутером?

cobold ★★★★★
()
Ответ на: комментарий от cobold

да ip белый. Согласен, что это костыль, но в противном случае cni дергает локальный адрес с сетевого интерфейса, т.е. внешний приходится проставлять руками каждый раз после ребута

Mars36
() автор топика

З.Ы. если нода в кластер добавилась и поды на ней создаются штатно (через кластер), а проблема только на этапе создания ingress controller, посмотри его манифест

Возможно, ты пытаешься использовать балансировщик из облака (через service типа loadBalancer) для доступа к твоей домашней машине, а он такой юмор не понимает

router ★★★★★
()
Ответ на: комментарий от router

Не много не уточнил, проблема есть еще до установки балансера(используется metallb, кластер bare-metal) и ингрес контроллера. Т.е. проблема появляется сразу после установки кластера и накатывания calico

Mars36
() автор топика
Admin