2017-08-09 1 views
10

Ich habe einen K8s-Cluster von 5 VMs (1 Master und 4 Slaves unter Ubuntu 16.04.3 LTS) mit kubeadm erstellt. Ich habe flannel verwendet, um das Netzwerk im Cluster einzurichten. Ich konnte eine Anwendung erfolgreich bereitstellen. Ich habe es dann über den NodePort-Dienst verfügbar gemacht. Von hier an wurden die Dinge für mich kompliziert.K8s NodePort-Dienst ist "unerreichbar durch IP" nur bei 2/4 Slaves im Cluster

Bevor ich begann, deaktivierte ich den Standard-Service firewalld auf Master und den Knoten.

Wie ich aus der K8s Services doc verstehe, stellt der Typ NodePort den Dienst auf allen Knoten im Cluster. Bei der Erstellung wurde der Dienst jedoch nur an zwei von vier Knoten im Cluster verfügbar gemacht. Ich vermute, das ist nicht das erwartete Verhalten (oder?)

Zur Fehlersuche, hier sind einige Ressource-Spezifikationen sind:

[email protected]:~# 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 

[email protected]:~# 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 

[email protected]:~# 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 

[email protected]:~# 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> 

[email protected]:~# 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 

Nach einigem Tüfteln ich, dass auf diesen 2 „fehlerhaft“ Knoten realisiert diese Dienste waren nicht verfügbar von innerhalb dieser Hosts selbst.

node01 (in Betrieb):

[email protected]:~# curl 127.0.0.1:30847  //<localhost>:<nodeport> 
Hello Docker World!! 
[email protected]:~# curl 10.101.180.19:9000 //<cluster-ip>:<port> 
Hello Docker World!! 
[email protected]:~# curl 10.244.3.7:9000  //<pod-ip>:<port> 
Hello Docker World!! 

Node02 (in Betrieb):

[email protected]:~# curl 127.0.0.1:30847 
Hello Docker World!! 
[email protected]:~# curl 10.101.180.19:9000 
Hello Docker World!! 
[email protected]:~# curl 10.244.3.7:9000 
Hello Docker World!! 

Node03 (nicht in Betrieb):

[email protected]:~# curl 127.0.0.1:30847 
curl: (7) Failed to connect to 127.0.0.1 port 30847: Connection timed out 
[email protected]:~# curl 10.101.180.19:9000 
curl: (7) Failed to connect to 10.101.180.19 port 9000: Connection timed out 
[email protected]:~# curl 10.244.3.7:9000 
curl: (7) Failed to connect to 10.244.3.7 port 9000: Connection timed out 

Node04 (nicht in Betrieb):

[email protected]:/# curl 127.0.0.1:30847 
curl: (7) Failed to connect to 127.0.0.1 port 30847: Connection timed out 
[email protected]:/# curl 10.101.180.19:9000 
curl: (7) Failed to connect to 10.101.180.19 port 9000: Connection timed out 
[email protected]:/# curl 10.244.3.7:9000 
curl: (7) Failed to connect to 10.244.3.7 port 9000: Connection timed out 

Versucht netstat und telnet an allen 4 Slaves. Hier ist die Ausgabe:

node01 (die Arbeits Host):

[email protected]:~# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  27808/kube-proxy 
[email protected]:~# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
Connected to 127.0.0.1. 
Escape character is '^]'. 

Node02 (die Arbeits Host):

[email protected]:~# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  11842/kube-proxy 
[email protected]:~# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
Connected to 127.0.0.1. 
Escape character is '^]'. 

Node03 (die nicht arbeitende Host):

[email protected]:~# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  7791/kube-proxy 
[email protected]:~# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
telnet: Unable to connect to remote host: Connection timed out 

Node04 (der nicht funktionierende Host):

[email protected]:/# netstat -tulpn | grep 30847 
tcp6  0  0 :::30847    :::*     LISTEN  689/kube-proxy 
[email protected]:/# telnet 127.0.0.1 30847 
Trying 127.0.0.1... 
telnet: Unable to connect to remote host: Connection timed out 

Zusatz Info:

Vom kubectl get pods Ausgang, kann ich sehen, dass die Hülse tatsächlich auf Slave vm-rosnthom-00f eingesetzt wird. Ich bin in der Lage zu ping dieser Host von allen 5 VMs und curl vm-rosnthom-00f:30847 funktioniert auch von allen VMs.

Ich kann deutlich sehen, dass die interne Cluster-Vernetzung ist durcheinander, aber ich bin mir nicht sicher, wie Sie es lösen! iptables -L für alle Slaves sind identisch, und sogar die Local Loopback (ifconfig lo) läuft für alle Slaves. Ich bin völlig ahnungslos, wie ich es beheben kann!

+0

nur zur Bestätigung, führen Sie die IP-Adresse aller nicht-Docker-Schnittstellen verfügen über einen separaten IP-Raum als Docker, Schoten und Dienstleistungen? Der Befehl, den ich sehen möchte, ist 'root @ vm-deepejai-00b:/# curl THE_IP_OF_vm-vivekse-004: 30847', um sicherzustellen, dass' vm-deepejai-00b' möglicherweise Verkehr zu 'vm-vivekse-004' routen kann , denn das passiert unter der Decke sowieso –

+0

Auch, nur für äußerste Klarheit, hast du 'iptables -t nat -L 'sowie nur' iptables -L 'überprüft (ich konnte nicht sagen, ob du das meintest) –

+0

@MatthewLDaniel Was Ihren ersten Kommentar, die Locke arbeitet: 'root @ vm-deepejai-00b: ~ # 173.36.23.4:30847 Hallo Docker Welt rollen !!' wo 173.36.23.4 die IP von vm sind Vivekse-004 –

Antwort

-3

Wenn Sie den Dienst von einem beliebigen Knoten im Cluster aus erreichen möchten, benötigen Sie einen Diensttyp wie ClusterIP.Da Sie den Servicetyp als NodePort definiert haben, können Sie eine Verbindung von dem Knoten herstellen, auf dem der Dienst ausgeführt wird.


meine obige Antwort war nicht korrekt, basierend auf Unterlagen sollten wir in der Lage sein, von jedem NodeIP:Nodeport zu verbinden. aber es funktioniert auch nicht in meinem Cluster.

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

NodePort: Exposes den Dienst auf jedem IP Knoten in einer statisch Port (die NodePort). Ein ClusterIP-Dienst, zu dem der NodePort-Dienst routet, wird automatisch erstellt. Sie können den NodePort-Dienst von außerhalb des Clusters anfordern, indem Sie anfordern:.

Einer meiner Knoten ip forward nicht festgelegt. Ich konnte meinen Dienst verbinden mit NODEIP: nodePort

sysctl -w net.ipv4.ip_forward=1 
Verwandte Themen