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!
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 –
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) –
@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 –