Zeitüberschreitung bei Kubernetes-Diensten beim Zugriff auf Pods auf verschiedenen Workern

Zeitüberschreitung bei Kubernetes-Diensten beim Zugriff auf Pods auf verschiedenen Workern

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-redmindestens worker-blueeinen 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:

  1. 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}

  1. 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 NodePortden 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-redEndpunkt curlen, werden SieNURdie Antwort vom worker-redPod erhalten, liegt daran, dass der andere Pod an einen anderen Endpunkt gebunden ist worker-blue:<node-port>und vom worker-redEndpunkt aus nicht erreichbar ist. Ja, es ist derselbe Dienst, aber er wird von zwei Endpunkten unterstützt, die jeweils unterschiedliche Hostnamen haben.

So NodePortfunktionieren 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 LoadBalanceralle Pods im Service gemeinsam haben.

Ich hoffe, das beseitigt Ihre Verwirrung!

verwandte Informationen