Usługa NodePort K8s jest "nieosiągalna przez IP" tylko na 2/4 urządzeń podrzędnych w klastrze

Question

Utworzono klaster K8s z 5 maszyn wirtualnych (1 master i 4 slaves z systemem Ubuntu 16.04.3 LTS) przy użyciu kubeadm. Użyłem flannel do skonfigurowania sieci w klastrze. Udało mi się pomyślnie wdrożyć aplikację. Wyjaśniłem to przez usługę NodePort. Odtąd sprawy się skomplikowały.

Przed uruchomieniem wyłączyłem domyślną usługę firewalld na serwerze głównym i węzłach.

Jak rozumiem z K8s Services doc, typ NodePort udostępnia usługę we wszystkich węzłach w klastrze. Jednak po jego utworzeniu usługa była wyświetlana tylko w 2 węzłach na 4 w klastrze. Domyślam się, że nie jest to oczekiwane zachowanie (prawda?)

Do rozwiązywania problemów, oto niektóre specyfikacje zasobów:

root@vm-vivekse-003:~# kubectl get nodes 
NAME    STATUS AGE  VERSION 
vm-deepejai-00b Ready  5m  v1.7.3 
vm-plashkar-006 Ready  4d  v1.7.3 
vm-rosnthom-00f Ready  4d  v1.7.3 
vm-vivekse-003 Ready  4d  v1.7.3 //the master 
vm-vivekse-004 Ready  16h  v1.7.3 

root@vm-vivekse-003:~# kubectl get pods -o wide -n playground 
NAME          READY  STATUS RESTARTS AGE  IP   NODE 
kubernetes-bootcamp-2457653786-9qk80  1/1  Running 0   2d  10.244.3.6 vm-rosnthom-00f 
springboot-helloworld-2842952983-rw0gc 1/1  Running 0   1d  10.244.3.7 vm-rosnthom-00f 

root@vm-vivekse-003:~# kubectl get svc -o wide -n playground 
NAME  CLUSTER-IP  EXTERNAL-IP PORT(S)   AGE  SELECTOR 
sb-hw-svc 10.101.180.19 <nodes>  9000:30847/TCP 5h  run=springboot-helloworld 

root@vm-vivekse-003:~# kubectl describe svc sb-hw-svc -n playground 
Name:    sb-hw-svc 
Namespace:   playground 
Labels:    <none> 
Annotations:  <none> 
Selector:   run=springboot-helloworld 
Type:    NodePort 
IP:     10.101.180.19 
Port:    <unset> 9000/TCP 
NodePort:   <unset> 30847/TCP 
Endpoints:   10.244.3.7:9000 
Session Affinity: None 
Events:    <none> 

root@vm-vivekse-003:~# kubectl get endpoints sb-hw-svc -n playground -o yaml 
apiVersion: v1 
kind: Endpoints 
metadata: 
    creationTimestamp: 2017-08-09T06:28:06Z 
    name: sb-hw-svc 
    namespace: playground 
    resourceVersion: "588958" 
    selfLink: /api/v1/namespaces/playground/endpoints/sb-hw-svc 
    uid: e76d9cc1-7ccb-11e7-bc6a-fa163efaba6b 
subsets: 
- addresses: 
    - ip: 10.244.3.7 
    nodeName: vm-rosnthom-00f 
    targetRef: 
     kind: Pod 
     name: springboot-helloworld-2842952983-rw0gc 
     namespace: playground 
     resourceVersion: "473859" 
     uid: 16d9db68-7c1a-11e7-bc6a-fa163efaba6b 
    ports: 
    - port: 9000 
    protocol: TCP 

Po pewnym majsterkowania zdałem sobie sprawę, że w tych „wadliwych” węzłami 2, usługi te nie były dostępne z samych hostów.

Node01 (pracy):

root@vm-vivekse-004:~# curl 127.0.0.1:30847  //<localhost>:<nodeport> 
Hello Docker World!! 
root@vm-vivekse-004:~# curl 10.101.180.19:9000 //<cluster-ip>:<port> 
Hello Docker World!! 
root@vm-vivekse-004:~# curl 10.244.3.7:9000  //<pod-ip>:<port> 
Hello Docker World!! 

Node02 (pracy):

root@vm-rosnthom-00f:~# curl 127.0.0.1:30847 
Hello Docker World!! 
root@vm-rosnthom-00f:~# curl 10.101.180.19:9000 
Hello Docker World!! 
root@vm-rosnthom-00f:~# curl 10.244.3.7:9000 
Hello Docker World!! 

Node03 (nie pracuje)

root@vm-plashkar-006:~# curl 127.0.0.1:30847 
curl: (7) Failed to connect to 127.0.0.1 port 30847: Connection timed out 
root@vm-plashkar-006:~# curl 10.101.180.19:9000 
curl: (7) Failed to connect to 10.101.180.19 port 9000: Connection timed out 
root@vm-plashkar-006:~# curl 10.244.3.7:9000 
curl: (7) Failed to connect to 10.244.3.7 port 9000: Connection timed out 

Node04 (nie pracuje)

root@vm-deepejai-00b:/# curl 127.0.0.1:30847 
curl: (7) Failed to connect to 127.0.0.1 port 30847: Connection timed out 
root@vm-deepejai-00b:/# curl 10.101.180.19:9000 
curl: (7) Failed to connect to 10.101.180.19 port 9000: Connection timed out 
root@vm-deepejai-00b:/# curl 10.244.3.7:9000 
curl: (7) Failed to connect to 10.244.3.7 port 9000: Connection timed out 

Wypróbowałem netstat i telnet na wszystkich 4 niewolnikach. Oto wynik:

Node01 (gospodarz roboczy):

root@vm-vivekse-004:~# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  27808/kube-proxy 
root@vm-vivekse-004:~# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
Connected to 127.0.0.1. 
Escape character is '^]'. 

Node02 (gospodarz roboczy):

root@vm-rosnthom-00f:~# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  11842/kube-proxy 
root@vm-rosnthom-00f:~# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
Connected to 127.0.0.1. 
Escape character is '^]'. 

Node03 (host nie pracujących):

root@vm-plashkar-006:~# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  7791/kube-proxy 
root@vm-plashkar-006:~# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
telnet: Unable to connect to remote host: Connection timed out 

Node04 (niedziałający host):

root@vm-deepejai-00b:/# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  689/kube-proxy 
root@vm-deepejai-00b:/# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
telnet: Unable to connect to remote host: Connection timed out 

informacji Dodatek:

Z wyjścia kubectl get pods, widzę, że kapsuła jest rzeczywiście wdrożony na niewolnika vm-rosnthom-00f. Jestem w stanie ping ten host ze wszystkich 5 maszyn wirtualnych i curl vm-rosnthom-00f:30847 działa również ze wszystkimi maszynami wirtualnymi.

Mogę wyraźnie zobaczyć, że wewnętrzne klastry sieciowe są pomieszane, ale nie jestem pewien, jak rozwiązać ten problem! iptables -L dla wszystkich niewolników są identyczne, a nawet Local Loopback (ifconfig lo) jest uruchomiony dla wszystkich urządzeń podrzędnych. Nie mam zielonego pojęcia, jak to naprawić!

Answer 1

Jeśli chcesz uzyskać dostęp do usługi z dowolnego węzła w klastrze, musisz mieć odpowiedni typ usługi pod numerem ClusterIP.Ponieważ zdefiniowałeś typ usługi jako NodePort, możesz połączyć się z węzłem, w którym działa usługa.

---

moja powyższa odpowiedź nie była poprawna, na podstawie dokumentacji, powinniśmy być w stanie połączyć się z dowolnym NodeIP:Nodeport. ale nie działa również w moim klastrze.

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services---service-types

NodePort: naraża obsługę na każdym węźle OD pod adresem statycznym portowy ( NodePort). Usługa ClusterIP, do której trasa NodePort będzie trasa , zostanie automatycznie utworzona. Będziesz mógł skontaktować się z usługą NodePort , spoza klastra, żądając :.

Jedno z moich adresów IP węzła nie jest ustawione. Udało mi się połączyć moje usługi przy użyciu NodeIP: nodePort

sysctl -w net.ipv4.ip_forward=1