Unterschied zwischen targetPort und Port in der Kubernetes Service-Definition

Ein Kubernetes Servicekann ein targetPortund portin der Service-Definition haben:

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

Was ist der Unterschied zwischen portund targetPort?

Service: Dies leitet den Verkehr zu einem Pod.

TargetPort: Dies ist der tatsächliche Port, auf dem Ihre Anwendung im Container ausgeführt wird.

Port: Manchmal stellt Ihre Anwendung im Container verschiedene Dienste an einem anderen Port bereit.

Beispiel: Die eigentliche Anwendung kann ausgeführt werden, 8080und Integritätsprüfungen für diese Anwendung können am 8089Port des Containers ausgeführt werden. Wenn Sie also den Dienst ohne Port erreichen, weiß er nicht, an welchen Port des Containers er die Anforderung umleiten soll. Der Dienst muss über eine Zuordnung verfügen, damit er den spezifischen Port des Containers erreichen kann.

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      nodePort: 30475
      port: 8089
      protocol: TCP
      targetPort: 8080
    - name: metrics
      nodePort: 31261
      port: 5555
      protocol: TCP
      targetPort: 5555
    - name: health
      nodePort: 30013
      port: 8443
      protocol: TCP
      targetPort: 8085 

Wenn Sie die Taste drücken, wird my-service:8089der Datenverkehr an 8080den Container (targetPort) weitergeleitet. Wenn Sie drücken, wird es ebenfalls zum Container (targetPort) my-service:8443umgeleitet 8085. Dies myservice:8089ist jedoch intern im Kubernetes-Cluster und kann verwendet werden, wenn eine Anwendung mit einer anderen Anwendung kommunizieren möchte. Um den Dienst von außerhalb des Clusters zu erreichen, muss jemand den Port auf dem Hostcomputer verfügbar machen, auf dem kubernetes ausgeführt wird, damit der Datenverkehr zu einem Port des Containers umgeleitet wird. Dies ist node port(Port auf dem Host-Computer verfügbar). Im obigen Beispiel können Sie den Dienst von außerhalb des Clusters (Postbote oder ein beliebiger Rest-Client) über aufrufenhost_ip:nodePort

Sagen Sie Ihre Host - Maschine ip ist , 10.10.20.20um die http treffen kann, Metriken, Gesundheitsdienste durch 10.10.20.20:30475, 10.10.20.20:31261, 10.10.20.20:30013.

Änderungen: Bearbeitet gemäß Raedwald- Kommentar.

Es hilft mir, Dinge aus der Perspektive des Dienstes zu betrachten .

• nodePort: Der Port auf dem Knoten, an dem externer Datenverkehr eingeht
• port: Der Port dieses Dienstes
• targetPort Der Zielport auf dem Pod, an den der Datenverkehr weitergeleitet werden soll

Der nodePortDatenverkehr wird weitergeleitet und portan den Dienst weitergeleitet, der dann targetPortan die Pods weitergeleitet wird.

Es lohnt sich, mehr nodePortfür den externen Verkehr zu betonen . Andere Pods im Cluster, die möglicherweise auf den Dienst zugreifen müssen, werden nur verwendet port, nicht, nodePortda es sich nur um internen Zugriff auf den Dienst handelt.

Beachten Sie auch, dass wenn targetPortnicht festgelegt, standardmäßig derselbe Wert wie verwendet wird port. ZB 80:80für Service-Port- 80Targeting-Container-Port 80.

Die oben von @Manikanta P gegebene Antwort ist richtig. Die Erklärung von "Port" könnte jedoch in der ersten Lesung etwas unklar sein. Ich werde mit einem Beispiel erklären:

Betrachten Sie eine Webanwendung mit ihrem statischen Inhalt (Startseite, Bilder usw.), der von httpd gehostet wird, und dem dynamischen Inhalt (z. B. Antwort auf Anfragen usw.), der von Tomcat gehostet wird. Der Webserver (oder der statische Inhalt) wird von httpd am Port 80bereitgestellt, während der Appserver (oder der dynamische Inhalt) von tomcat am Port bereitgestellt wird8080 .

Was ein Entwickler möchte: Der Benutzer sollte von außerhalb auf den Webserver zugreifen können, ABER nicht von außen auf den Appserver.

Lösung: Der Diensttyp des Webservers in seiner service.yml ist NodePort, während der Diensttyp des Appservers in seiner service.yml ClusterIP ist.

Code für die service.yml des Webservers:

spec:
  selector:
    app: Webserver
  type: NodePort        // written to make this service accessible from outside.
  ports:
    - nodePort: 30475   // To access from outside, type <host_IP>:30475 in browser.
      port: 5050        // (ignore for now, I will explain below).
      protocol: TCP
      targetPort: 80  // port where httpd runs inside the webserver pod.

Code für Appservers service.yml

spec:
  selector:
    app: appserver
  type: ClusterIP        // written to make this service NOT accessible from outside.
  ports:
    - port: 5050         // port to access this container internally
      protocol: TCP
      targetPort: 8080   // port where tomcat runs inside the appserver pod.

Beachten Sie auch, httpd.confdass wir in die Datei des Webservers die IP schreiben, die die Anforderung eines Benutzers an den Appserver umleitet. Diese IP lautet : host_IP:5050.

Was genau passiert hier? Ein Benutzer schreibt hostIP:30475und sieht die Seite des Webservers. Dies liegt daran, dass es von httpd am Port 80(Zielport) bereitgestellt wird. Wenn ein Benutzer auf eine Schaltfläche klickt, wird eine Anfrage gestellt. Diese Anforderung wird an den Appserver umgeleitet, da in der httpd.confDatei der Port 5050erwähnt wird und dies der Port ist, an dem der Container des Appservers und der Conatainer des Webservers intern kommunizieren. Wenn der App-Server die Anforderung empfängt, kann er die Anforderung bearbeiten, da Tomcat am Port ausgeführt wird 8080.

Diese Antwort bezieht sich zusätzlich zu den anderen Antworten auf die Dokumentation von Kubernetes:

https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/ :

targetPort: ist der Port, an dem der Container Datenverkehr akzeptiert,

port: ist der abstrahierte Service-Port. Dies kann jeder Port sein, den andere Pods für den Zugriff auf den Service verwenden

https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/ :

Portdefinitionen in Pods haben Namen, und Sie können diese Namen im targetPortAttribut eines Dienstes referenzieren . Dies funktioniert auch dann, wenn im Dienst eine Mischung von Pods mit einem einzigen konfigurierten Namen vorhanden ist und dasselbe Netzwerkprotokoll über verschiedene Portnummern verfügbar ist.

"Zielport" ist der Port, auf dem Ihr Container ausgeführt wird.

Port: Port leitet den Datenverkehr vom Dienst zum Container um.

Bereitstellung der Bereitstellung

  master $ kubectl get deployments
NAME         READY   UP-TO-DATE   AVAILABLE   AGE

nginx        1/1     1            1           31s
master $ kubectl expose deployment nginx --name=nginx-svc --port=8080 --target-port=80
service/nginx-svc exposed

master $ kubectl get svc

NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE

nginx-svc    ClusterIP   10.107.209.151   <none>        8080/TCP   5s

NodePort: ist der Port, über den der Dienst extern auf den Port zugreifen kann.

Hoffe das antwortet.

Kurz gesagt

nodeport: Lauscht externe Anforderungen auf allen Worker-Knoten auf nodeip: port und leitet die Anforderung an port weiter.

port: Interner Cluster-Service-Port für Container und überwacht eingehende Anforderungen vom Nodeport und leitet sie an targetPort weiter.

targetPort:Empfangen Sie die Anfrage vom Port und leiten Sie sie an den Container Pod (Port) weiter, wo sie abgehört wird. Selbst wenn Sie dies nicht angeben, werden standardmäßig dieselben Portnummern wie der Port zugewiesen.

Wenn der Container Port 9376 überwacht, ist targetPort : 9376

Wenn ein Dienst Port 80 abhört, dann Port : 80

Dann sieht die Konfiguration der Service-Ports wie folgt aus

ports:
 - protocol: TCP
   port: 80
   targetPort: 9376

Schließlich wurde die Anforderung an den Port des Dienstes empfangen und an den Zielport des Pods weitergeleitet.