Différence entre targetPort et port dans la définition du service Kubernetes

Un Kubernetes Servicepeut avoir un targetPortet portdans la définition de service:

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

Quelle est la différence entre portet targetPort?

Service: Ceci dirige le trafic vers un pod.

TargetPort: il s'agit du port réel sur lequel votre application s'exécute à l'intérieur du conteneur.

Port: Parfois, votre application à l'intérieur du conteneur sert différents services sur un port différent.

Exemple: l' application réelle peut s'exécuter 8080et les vérifications de l'état de cette application peuvent s'exécuter sur le 8089port du conteneur. Donc, si vous frappez le service sans port, il ne sait pas vers quel port du conteneur il doit rediriger la demande. Le service doit avoir un mappage pour pouvoir atteindre le port spécifique du conteneur.

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 

si vous atteignez le, my-service:8089le trafic est acheminé vers 8080le conteneur (targetPort). De même, si vous frappez, my-service:8443il est redirigé vers 8085du conteneur (targetPort). Mais cela myservice:8089est interne au cluster kubernetes et peut être utilisé lorsqu'une application souhaite communiquer avec une autre application. Donc, pour accéder au service depuis l'extérieur du cluster, quelqu'un doit exposer le port sur la machine hôte sur laquelle Kubernetes s'exécute afin que le trafic soit redirigé vers un port du conteneur. C'est node port(port exposé sur la machine hôte). À partir de l'exemple ci-dessus, vous pouvez accéder au service depuis l'extérieur du cluster (Postman ou tout autre client de repos) enhost_ip:nodePort

Dites votre machine hôte ip est que 10.10.20.20vous pouvez frapper les http, les mesures, les services de santé 10.10.20.20:30475, 10.10.20.20:31261, 10.10.20.20:30013.

Modifications: Modifié selon le commentaire de Raedwald .

Cela m'aide à penser les choses du point de vue du service .

• nodePort: Le port sur le nœud où le trafic externe entrera
• port: Le port de ce service
• targetPort Le port cible du ou des pod (s) vers lequel transférer le trafic

Le trafic entre en marche nodePort, redirige vers portle service qui est ensuite acheminé vers targetPortle ou les pod (s).

Cela vaut la peine de mettre davantage l'accent nodePortsur le trafic externe. Les autres pods du cluster qui peuvent avoir besoin d'accéder au service utiliseront simplement port, pas nodePortcar il s'agit d'un accès interne uniquement au service.

Il convient également de noter que s'il targetPortn'est pas défini, il aura par défaut la même valeur que port. Par exemple, 80:80pour le port de service 80ciblant le port de conteneurs 80.

La réponse donnée ci-dessus par @Manikanta P est correcte. Cependant, l'explication de «Port» peut être un peu floue en première lecture. J'expliquerai avec un exemple:

Considérons une application Web avec son contenu statique (page d'accueil, images, etc.) hébergé par httpd et le contenu dynamique (par exemple, réponse aux demandes, etc.) hébergé par tomcat. Le serveur Web (ou le contenu statique) est servi par httpd au port 80tandis qu'Appserver (ou le contenu dynamique) est servi par tomcat au port 8080.

Ce que veut un développeur: l'utilisateur doit pouvoir accéder au serveur Web de l'extérieur MAIS pas au serveur d'applications de l'extérieur.

Solution: Le type de service de Webserver dans son service.yml sera NodePort tandis que le type de service d'Appserver dans son service.yml sera ClusterIP.

Code pour le service.yml du serveur 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.

Code pour le service.yml d'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.

Notez également que dans le httpd.conffichier du serveur Web, nous écrirons l'adresse IP qui redirige la demande d'un utilisateur vers le serveur d'applications. Cette adresse IP sera: host_IP:5050.

Que se passe-t-il exactement ici? Un utilisateur écrit hostIP:30475et voit la page du serveur Web. C'est parce qu'il est servi par httpd au port 80(targetport). Lorsqu'un utilisateur clique sur un bouton, une demande est effectuée. Cette requête est redirigée vers l'Appserver car dans le httpd.conffichier, le port 5050est mentionné et c'est le port où le conteneur d'Appserver et le conteneur de Webserver communiquent en interne. Lorsque le serveur d'applications reçoit la demande, il est capable de servir la demande car Tomcat s'exécute à l'intérieur au port 8080.

Cette réponse consiste à référencer la documentation de Kubernetes en plus des autres réponses:

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

targetPort: est le port sur lequel le conteneur accepte le trafic,

port: est le port de service abstrait, qui peut être n'importe quel port utilisé par d'autres pods pour accéder au service

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

Les définitions de port dans les pods ont des noms et vous pouvez référencer ces noms dans l' targetPortattribut d'un service. Cela fonctionne même s'il existe un mélange de pods dans le service utilisant un seul nom configuré, avec le même protocole réseau disponible via différents numéros de port.

En résumé

nodeport: Écoute la demande externe sur tous les nœuds de travail sur nodeip: port et transfère la demande au port.

port: Port de service de cluster interne pour le conteneur et écoute les demandes entrantes du nodeport et les transfère vers targetPort.

targetPort:Recevez la demande du port et la transmet au pod conteneur (port) où il écoute. même si vous ne spécifiez pas, cela obtiendra par défaut les mêmes numéros de port que le port.

«Port cible» est le port sur lequel votre conteneur s'exécute.

Port: le port redirige le trafic vers le conteneur depuis le service.

Exposer le déploiement

  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: est le port qui permet au service d'accéder au.

J'espère que cela répond.

si le conteneur écoute sur le port 9376, alors targetPort : 9376

si un service écoute sur le port 80, alors port : 80

Ensuite, la configuration des ports de service ressemble à ci-dessous

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

Enfin, la demande est reçue sur le port du service et transmise sur le targetPort du pod.