Differenza tra targetPort e port nella definizione del servizio Kubernetes

Un Kubernetes Servicepuò avere un targetPorte portnella definizione del servizio:

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

Qual'è la differenza tra the porte targetPort?

Servizio: indirizza il traffico a un pod.

TargetPort: questa è la porta effettiva su cui è in esecuzione l'applicazione all'interno del contenitore.

Porta: alcune volte la tua applicazione all'interno del container serve diversi servizi su una porta diversa.

Esempio: l'applicazione effettiva può essere eseguita 8080e i controlli di integrità per questa applicazione possono essere eseguiti sulla 8089porta del contenitore. Quindi, se colpisci il servizio senza porta, non sa a quale porta del container deve reindirizzare la richiesta. Il servizio deve avere una mappatura in modo che possa raggiungere la porta specifica del container.

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 

se colpisci il my-service:8089traffico viene indirizzato al 8080contenitore (targetPort). Allo stesso modo, se si preme my-service:8443, viene reindirizzato al 8085contenitore (targetPort). Ma questo myservice:8089è interno al cluster kubernetes e può essere utilizzato quando un'applicazione desidera comunicare con un'altra applicazione. Quindi, per colpire il servizio dall'esterno del cluster, qualcuno deve esporre la porta sulla macchina host su cui è in esecuzione kubernetes in modo che il traffico venga reindirizzato a una porta del contenitore. Questa è node port(porta esposta sulla macchina host). Dall'esempio sopra, puoi raggiungere il servizio dall'esterno del cluster (Postman o qualsiasi rest-client) dahost_ip:nodePort

Di 'la tua macchina host IP è 10.10.20.20si può colpire i protocolli HTTP, metriche, i servizi sanitari da parte 10.10.20.20:30475, 10.10.20.20:31261, 10.10.20.20:30013.

Modifiche: modificato secondo il commento di Raedwald .

Mi aiuta a pensare alle cose dalla prospettiva del servizio .

• nodePort: La porta sul nodo da cui entrerà il traffico esterno
• port: Il porto di questo servizio
• targetPort La porta di destinazione sui pod a cui inoltrare il traffico

Il traffico entra nodePort, inoltra al portservizio che poi si dirige verso targetPorti pod.

Vale la pena sottolineare di più che nodePortè per il traffico esterno. Gli altri pod nel cluster che potrebbero dover accedere al servizio utilizzeranno solo port, non nodePortpoiché è solo un accesso interno al servizio.

Vale anche la pena notare che se targetPortnon è impostato, verrà impostato automaticamente sullo stesso valore di port. Ad esempio, 80:80per la porta di servizio che 80mira alla porta del contenitore 80.

La risposta data sopra da @Manikanta P è corretta. Tuttavia, la spiegazione di "Port" potrebbe essere un po 'poco chiara a prima lettura. Spiegherò con un esempio:

Considera un'applicazione Web con il suo contenuto statico (front-page, immagini, ecc.) Ospitato da httpd e il contenuto dinamico (es. Risposta a richieste, ecc.) Ospitato da tomcat. Il Webserver (o il contenuto statico) è servito da httpd alla porta 80mentre Appserver (o il contenuto dinamico) è servito da Tomcat alla porta 8080.

Cosa vuole uno sviluppatore: l'utente dovrebbe essere in grado di accedere al server Web dall'esterno MA non all'Appserver dall'esterno.

Soluzione: il tipo di servizio di Webserver nel suo service.yml sarà NodePort mentre il tipo di servizio di Appserver nel suo service.yml sarà ClusterIP.

Codice per service.yml del server web:

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.

Codice per il service.yml di Appserver

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.

Nota anche, nel httpd.conffile del Webserver, scriveremo l'IP che reindirizza la richiesta di un utente al server delle app. Questo IP sarà: host_IP:5050.

Cosa sta succedendo esattamente qui? Un utente scrive hostIP:30475e vede la pagina del server web. Questo perché è servito da httpd sulla porta 80(targetport). Quando un utente fa clic su un pulsante, viene effettuata una richiesta. Questa richiesta viene reindirizzata ad Appserver perché nel httpd.conffile 5050viene menzionata la porta e questa è la porta dove comunicano internamente il contenitore di Appserver e il conatainer di Webserver. Quando il server app riceve la richiesta, è in grado di servire la richiesta perché tomcat è in esecuzione al suo interno alla porta 8080.

Questa risposta serve per fare riferimento alla documentazione di Kubernetes oltre alle altre risposte:

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

targetPort: è la porta su cui il container accetta il traffico,

port: è la porta del servizio astratta, che può essere qualsiasi porta utilizzata da altri pod per accedere al servizio

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

Le definizioni delle porte nei pod hanno nomi e puoi fare riferimento a questi nomi targetPortnell'attributo di un servizio. Funziona anche se nel Servizio è presente una combinazione di Pod che utilizzano un unico nome configurato, con lo stesso protocollo di rete disponibile tramite diversi numeri di porta.

In poche parole

nodeport: Ascolta la richiesta esterna su tutti i nodi di lavoro su nodeip: port e inoltra la richiesta alla porta.

port: Porta del servizio cluster interna per il contenitore e ascolta la richiesta in arrivo dal nodeport e inoltra a targetPort.

targetPort:Ricevi la richiesta dalla porta e inoltra al pod del contenitore (porta) dove è in ascolto. anche se non lo specifichi, per impostazione predefinita verranno assegnati gli stessi numeri di porta della porta.

"Porta di destinazione" è la porta su cui è in esecuzione il contenitore.

Porta: la porta reindirizza il traffico al container dal servizio.

Esporre la distribuzione

  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: è la porta che abilita il servizio ad accedere esternamente.

Spero che questo risponda.

se il contenitore è in ascolto sulla porta 9376, allora targetPort : 9376

se un servizio è in ascolto sulla porta 80, allora porta : 80

Quindi la configurazione delle porte del servizio appare come di seguito

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

Infine, richiesta ricevuta a quello del servizio di porto , e trasmessa sul TARGETPORT del baccello.