У меня есть кластер кубнеров 3x узла: node1 (master), node2 и node3. У меня есть модуль, который в настоящее время запланирован на узле3, который я бы хотел открыть извне кластеру. Поэтому у меня есть служба типа nodePort с nodePort, установленной на 30080. Я могу успешно выполнить curl localhost:30080
локально на каждом узле: node1, node2 и node3. Но внешне curl nodeX:30080
работает только с node3. Остальные два таймаута. tcpdump подтверждает, что node1 и node2 получают запрос, но не отвечают.Сетевая проблема Kubernetes - Service nodePort не может быть достигнут извне
Как я могу сделать эту работу для всех трех узлов, поэтому мне не нужно отслеживать, на каком узле находится текущий модуль? Моя лучшая догадка заключается в том, что это проблема iptables, когда мне не хватает правила iptables для трафика DNAT, если исходный IP-адрес не является localhost. При этом я понятия не имею, как устранить неполадки, чтобы подтвердить, что это проблема, а затем как ее исправить. Кажется, что это правило должно быть автоматически.
Вот некоторая информация моя установка:
Кубэ-ravi196: 10.163.148.196
Кубэ-ravi197: 10.163.148.197
Кубэ-ravi198: 10.163.148.198
CNI: Канал (фланель + ситец)
Хост ОС: Ubuntu 16.04
кластера устанавливается через kubeadm
$ kubectl get pods --namespace=kube-system -l "k8s-app=kube-registry" -o wide
NAME READY STATUS RESTARTS AGE IP NODE
kube-registry-v0-1mthd 1/1 Running 0 39m 192.168.75.13 ravi-kube198
$ kubectl get service --namespace=kube-system -l "k8s-app=kube-registry"
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-registry 10.100.57.109 <nodes> 5000:30080/TCP 5h
$ kubectl get pods --namespace=kube-system -l "k8s-app=kube-proxy" -o wide
NAME READY STATUS RESTARTS AGE IP NODE
kube-proxy-1rzz8 1/1 Running 0 40m 10.163.148.198 ravi-kube198
kube-proxy-fz20x 1/1 Running 0 40m 10.163.148.197 ravi-kube197
kube-proxy-lm7nm 1/1 Running 0 40m 10.163.148.196 ravi-kube196
Обратите внимание, что скручиванию локальный из узла Ravi-kube196 успешно (404 хорошо).
[email protected]:~$ curl localhost:30080/test
404 page not found
Но попытка завивать IP от машины вне кластера не удается:
[email protected]:~$ curl 10.163.148.196:30080/test
(hangs)
Затем пытается завить IP узла, который стручок запланирован на работах .:
[email protected]:~$ curl 10.163.148.198:30080/test
404 page not found
Вот мои правила iptables для этого сервиса/модуля на узле 196:
[email protected]:~$ sudo iptables-save | grep registry
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kube-registry:registry" -m tcp --dport 30080 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "kube-system/kube-registry:registry" -m tcp --dport 30080 -j KUBE-SVC-JV2WR75K33AEZUK7
-A KUBE-SEP-7BIJVD3LRB57ZVM2 -s 192.168.75.13/32 -m comment --comment "kube-system/kube-registry:registry" -j KUBE-MARK-MASQ
-A KUBE-SEP-7BIJVD3LRB57ZVM2 -p tcp -m comment --comment "kube-system/kube-registry:registry" -m tcp -j DNAT --to-destination 192.168.75.13:5000
-A KUBE-SEP-7QBKTOBWZOW2ADYZ -s 10.163.148.196/32 -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-MARK-MASQ
-A KUBE-SEP-7QBKTOBWZOW2ADYZ -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m tcp -j DNAT --to-destination 10.163.148.196:1
-A KUBE-SEP-DARQFIU6CIZ6DHSZ -s 10.163.148.198/32 -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-MARK-MASQ
-A KUBE-SEP-DARQFIU6CIZ6DHSZ -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m tcp -j DNAT --to-destination 10.163.148.198:1
-A KUBE-SEP-KXX2UKHAML22525B -s 10.163.148.197/32 -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-MARK-MASQ
-A KUBE-SEP-KXX2UKHAML22525B -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m tcp -j DNAT --to-destination 10.163.148.197:1
-A KUBE-SERVICES ! -s 192.168.0.0/16 -d 10.106.192.243/32 -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc: cluster IP" -m tcp --dport 1 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.106.192.243/32 -p tcp -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc: cluster IP" -m tcp --dport 1 -j KUBE-SVC-E66MHSUH4AYEXSQE
-A KUBE-SERVICES ! -s 192.168.0.0/16 -d 10.100.57.109/32 -p tcp -m comment --comment "kube-system/kube-registry:registry cluster IP" -m tcp --dport 5000 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.100.57.109/32 -p tcp -m comment --comment "kube-system/kube-registry:registry cluster IP" -m tcp --dport 5000 -j KUBE-SVC-JV2WR75K33AEZUK7
-A KUBE-SVC-E66MHSUH4AYEXSQE -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-7QBKTOBWZOW2ADYZ
-A KUBE-SVC-E66MHSUH4AYEXSQE -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-KXX2UKHAML22525B
-A KUBE-SVC-E66MHSUH4AYEXSQE -m comment --comment "kube-system/glusterfs-dynamic-kube-registry-pvc:" -j KUBE-SEP-DARQFIU6CIZ6DHSZ
-A KUBE-SVC-JV2WR75K33AEZUK7 -m comment --comment "kube-system/kube-registry:registry" -j KUBE-SEP-7BIJVD3LRB57ZVM2
Кубэ-прокси журналы из 196 узла:
[email protected]:~$ kubectl logs --namespace=kube-system kube-proxy-lm7nm
I0105 06:47:09.813787 1 server.go:215] Using iptables Proxier.
I0105 06:47:09.815584 1 server.go:227] Tearing down userspace rules.
I0105 06:47:09.832436 1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_max' to 131072
I0105 06:47:09.836004 1 conntrack.go:66] Setting conntrack hashsize to 32768
I0105 06:47:09.836232 1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_established' to 86400
I0105 06:47:09.836260 1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_tcp_timeout_close_wait' to 3600
Вы не сможете получить доступ к сервису от ведущего - можете ли вы подтвердить, что не можете получить доступ к службе с 10.163.148.197? – kellanburket
Нет, это время для 197, а также 196 (мастер). Почему вы говорите, что я не смогу получить доступ к службе у мастера? По моему мнению, все узлы должны проксировать службу узлу с запланированным пакетом.И проксирование действительно работает, когда я запускаю 'curl localhost: 30080' непосредственно на ведущем устройстве или на любых мини-узлах. Просто внешне это терпит неудачу. – ravishi
Извините, вы правы в том, что касается главного узла - моя ошибка. – kellanburket