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


Réponses:


82

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 .


4
Quel est l'avantage de permettre portet targetPortd'être différent? Donc, par exemple en regardant votre healthexemple, pourquoi faire la port 8443place de 8085? Fondamentalement, pourquoi y a-t-il deux paramètres au lieu de simplement exposer tous les targetPorts sur le service?
Dan

Salut Dan, vous pouvez utiliser 8443 comme port et port cible pour la santé. J'ai utilisé des nombres différents pour une meilleure explication.
Manikanta P

Merci pour la réponse. Je voulais dire, dans quelles situations serait-il utile de les différencier?
Dan

"courir sur le conteneur" signifie? Le port utilisé par le serveur à l' intérieur du conteneur? Ou le port que les clients en dehors du conteneur utilisent?
Raedwald du

Pouvons-nous supposer une adresse IP fixe pour la machine hôte comme 10.10.20.20 dans les services cloud? e, g, Azure AKS avec situation de déploiement multi-nœuds?
Jaish Mathews

17

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.


4
bon résumé qui en quelques mots répond bien à la question, merci!
Wolfson le

Se mettre d'accord. J'ai trouvé d'autres réponses déroutantes, mais celle-ci touche le clou.
Nikola Malešević le

Les gens veulent connaître la différence entre portet targetPort. Vous avez vraiment dissipé la confusion.
Ankur Gautam le

1
Je suis d'accord, je pense que c'est "la" réponse et les réponses ci-dessus ouvrent des champs supplémentaires et des sujets plus larges, ce qui rend la compréhension plus difficile. Vive Julz.
Worp

10

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.


4
Pourquoi les spécifications du serveur Web définissent-elles «port: 5050»? Si j'ai bien compris, le serveur Web appelle le serveur d'applications: 5050, pas l'inverse ...?
Everton

1
En plus de la question d'Everton, quel est l'intérêt pour Tomcat d'ouvrir le port 8080 s'il traite les requêtes internes sur le port 5050?
Stephen

Cette réponse prête à confusion. De plus, où est httpd.conf"car dans le fichier httpd.conf, le port 5050 est mentionné"
Polymerase

Le fichier @Polymerase httpd.conf est fourni avec le package httpd que vous installez sur votre système. C'est un fichier interne que vous devez configurer. Chemin: /etc/httpd/conf/http.conf
matak8s

@Stephen dans tomcat / conf / server.xml, nous spécifions un port sur lequel le service tomcat fonctionnera. C'est le même numéro de port que nous écrivons comme port cible afin que kubernetes comprenne qu'il doit activer le service Tomcat sur ce port. Corrigez-moi si je me trompe.
matak8s

1

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.


Merci pour la réponse concise
Ankur Gautam

1

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.


0

«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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.