
Ich versuche, ein Paar Kubernetes-Worker auf EC2-Instanzen einzurichten und stoße dabei auf das Problem, dass der Dienst scheinbar nicht alle Pods „sieht“, die er sehen sollte.
Meine genaue Umgebung besteht aus einem Paar AWS Snowballs, Red und Blue, und mein Cluster sieht wie folgt aus control
: , worker-red
, und worker-blue
[1]. Ich stelle einen Dummy-Python-Server bereit, der auf ein GET auf Port 8080 wartet und mit dem lokalen Hostnamen antwortet. Ich habe ihn mit genügend Replikaten eingerichtet, sodass beide worker-red
mindestens worker-blue
einen Pod haben. Schließlich habe ich einen Dienst erstellt, dessen Spezifikation wie folgt aussieht:
spec:
type: NodePort
selector:
app: hello-server
ports:
- port: 8080
targetPort: 8080
nodePort: 30080
Ich kann jetzt überprüfen, ob meine Pods aktiv sind
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
hello-world-deployment-587468bdb7-hf4dq 1/1 Running 0 27m 192.168.1.116 worker.red <none> <none>
hello-world-deployment-587468bdb7-mclhm 1/1 Running 0 27m 192.168.1.126 worker.blue <none> <none>
Jetzt kann ich versuchen, sie zu locken
curl worker-red:30080
greetings from hello-world-deployment-587468bdb7-hf4dq
curl worker-blue:30080
greetings from hello-world-deployment-587468bdb7-mclhm
Das passiert ungefähr die Hälfte der Zeit. In der anderen Hälfte der Zeit schlägt Curl mit einem Timeout-Fehler fehl. Genauer gesagt: Curling von Worker-Red führt NUR zu einer Antwort von hf4dq und Curling von Worker-Blue führt NUR zu einer Antwort von mclhm. Wenn ich Worker-Blue absperre und entleere, sodass beide meiner Pods auf Worker-Red laufen, gibt es nie ein Timeout und beide Pods werden antworten.
Es scheint, als ob der NodePort-Dienst keine Pods erreicht, die sich nicht auf dem Host befinden, den ich curle. So wie ich sie verstehe, sollten Dienste nicht so funktionieren. Was übersehe ich?
[1] Wenn ich es so einrichte, dass zwei Arbeiter beide auf Red sind, tritt dasselbe Problem auf, das ich beschreibe. Da dies aber mein primärer Anwendungsfall ist, werde ich mich auch darauf konzentrieren.
Antwort1
Es ist schwer, einfach zu sagen, was hier falsch sein könnte, aber es gibt einige Schritte, die Sie unternehmen können, um Ihr Problem zu beheben:
- Debug-Pods, prüfen Sie insbesondere, ob die Protokolle verdächtige Hinweise enthalten:
kubectl logs ${POD_NAME} ${CONTAINER_NAME}
kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
- Debug-Dienste, indem Sie beispielsweise Folgendes ankreuzen:
Existiert der Dienst?
Funktioniert der Dienst per DNS-Namen?
Funktioniert der Dienst per IP?
Ist der Dienst richtig definiert?
Verfügt der Dienst über Endpunkte?
Funktioniert der Kube-Proxy?
Durch die Ausführung dieser Schritte können Sie die Ursache Ihres Problems finden und die Funktionsweise der Dienste besser verstehen.
Antwort2
Sie verwenden NodePort
den Typ „Dienst“. In diesem Fall entspricht das, was Sie beobachten, genau den Erwartungen.
Ihr Dienst gleicht 2 Pods ab, die auf zwei verschiedenen Knoten ausgeführt werden. Da der Dienst vom Typ ist NodePort
, besteht eine inhärente Verbindung zwischen einem Pod Ihres Dienstes und dem Knoten, auf dem er ausgeführt wird. Wenn Sie den worker-red
Endpunkt curlen, werden SieNURdie Antwort vom worker-red
Pod erhalten, liegt daran, dass der andere Pod an einen anderen Endpunkt gebunden ist worker-blue:<node-port>
und vom worker-red
Endpunkt aus nicht erreichbar ist. Ja, es ist derselbe Dienst, aber er wird von zwei Endpunkten unterstützt, die jeweils unterschiedliche Hostnamen haben.
So NodePort
funktionieren Dienste im Wesentlichen.
Wenn Sie beide auf demselben Knoten bündeln, sind beide Pods über denselben Knoten-Hostnamen erreichbar, sodass das Curling beider funktioniert. Seitdem sind beide Endpunkte auf unterschiedliche Ports abgebildet, aber diegleicher Hostname.
Um Ihr Verständnis hierfür zu vertiefen, können Sie versuchen, Ihren Servicetyp in zu ändern LoadBalancer
. Sie werden feststellen, dass Sie beide Pods mit demselben Hostnamen erreichen können, unabhängig davon, wo sie geplant werden. Und dieser Hostname/diese IP-Adresse ist die Adresse, die LoadBalancer
alle Pods im Service gemeinsam haben.
Ich hoffe, das beseitigt Ihre Verwirrung!