283 votes

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

Un système Kubernetes Service peut avoir une targetPort y port dans la définition du 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 le port y targetPort ?

0 votes

Vous pouvez vous référer à cette question stackoverflow.com/questions/41963433/

218voto

Manikanta P Points 461

Service : Cela permet de diriger le trafic vers un pod.

Port cible : Il s'agit du port sur lequel votre application s'exécute à l'intérieur du conteneur.

Port : Il arrive que votre application dans un conteneur serve différents services sur un port différent.

Exemple : L'application proprement dite peut être exécutée 8080 et les contrôles de santé pour cette application peuvent être exécutés sur 8089 port du conteneur. Ainsi, si vous frappez le service sans port, il ne sait pas vers quel port du conteneur il doit rediriger la requête. Le service doit disposer d'un mappage lui permettant d'accéder au 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 touchez le my-service:8089 le trafic est acheminé vers 8080 du conteneur (targetPort). De même, si vous appuyez sur my-service:8443 il est alors redirigé vers 8085 du conteneur (targetPort). Mais cette myservice:8089 est interne au cluster kubernetes et peut être utilisé lorsqu'une application souhaite communiquer avec une autre application. Pour accéder au service depuis l'extérieur du cluster, il faut donc exposer le port sur la machine hôte sur laquelle tourne kubernetes. afin que le trafic soit redirigé vers un port du conteneur. Il s'agit de node port (port exposé sur la machine hôte). Dans l'exemple ci-dessus, vous pouvez accéder au service depuis l'extérieur du cluster (Postman ou n'importe quel client rest) en procédant comme suit host_ip:nodePort

Supposons que l'adresse IP de votre machine hôte soit 10.10.20.20 vous pouvez accéder aux services http, métriques et de santé en 10.10.20.20:30475 , 10.10.20.20:31261 , 10.10.20.20:30013 .

Modifications : Modifié conformément à Raedwald commentaire.

10 votes

Quel est l'avantage de permettre port y targetPort d'être différent ? Par exemple, si vous regardez votre health par exemple, pourquoi faire de la port 8443 au lieu de 8085 ? En fait, pourquoi y a-t-il deux paramètres au lieu d'exposer simplement tous les targetPort sur le service ?

1 votes

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

5 votes

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

162voto

julz256 Points 1092

Cela m'aide à envisager les choses sous l'angle de la du service .

  • nodePort : Le port du nœud par lequel le trafic externe entrera.
  • port : Le port de ce service
  • targetPort Le port cible sur le(s) pod(s) vers lequel le trafic doit être transféré

Le trafic arrive sur nodePort et le transmet à l'adresse suivante port sur le service qui s'adresse ensuite à targetPort sur le(s) pod(s).

Il convient de souligner que nodePort est destiné au trafic externe. Les autres pods du cluster qui pourraient avoir besoin d'accéder au service utiliseront simplement l'option port , pas nodePort car il s'agit du seul accès interne au service.

Il convient également de noter que si targetPort n'est pas défini, il prendra par défaut la même valeur que port . Par exemple 80:80 pour le port de service 80 cibler le port à conteneurs 80 .

32voto

En bref

nodeport: Écoute des requêtes externes sur tous les nœuds de travail sur nodeip:nodeport et transmet la demande au port.

ClusterIP: La demande arrive par l'entrée et pointe vers le nom du service et le port.

port: Port interne du service de cluster pour le conteneur et écoute les requêtes entrantes provenant du nodeport et les transmet au targetPort.

targetPort: Reçoit la demande du port et la transmet au pod conteneur (port) où il est à l'écoute. Même si vous ne le spécifiez pas, les mêmes numéros de port que port lui seront attribués par défaut.

Le trafic s'écoule donc Ingress-->Service-->Endpoint(Basically has POD IP)-->POD

19voto

user3651946 Points 41

Si le conteneur écoute sur le port 9376, alors port cible : 9376

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

La configuration des ports de service ressemble alors à ce qui suit

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

Enfin, les demandes reçues par le service port et transmis sur le site port cible de la nacelle.

9voto

Lord Points 2720

Cas 1 :

Supposons qu'il n'y ait pas de nodPort ou de port, maintenant vous voulez exécuter votre application et l'exposer à l'extérieur, ce dont vous aurez besoin :

  1. Un contrôleur d'entrée qui utilisera un servicePort pour rediriger vers le service souhaité en fonction du routage.
  2. Un service IP de cluster avec une cible définie pour votre port d'application (également appelé targetPort).
  3. Un port réseau qui identifie l'application ou le service fonctionnant sur l'ordinateur (en d'autres termes, le port d'application).

Ainsi, pour accéder à l'extérieur, nous avons trouvé trois ports nécessaires.

  1. servicePort (contrôleur d'entrée)
  2. targetPort (Service Ip de cluster)
  3. networkPort (port d'application)

pour que tout fonctionne correctement : servicePort === targetPort === networkPort

Cas 2 : Supposons maintenant qu'un service communique avec un autre service dans notre cluster, ou supposons qu'un service reçoive une requête de l'extérieur et qu'il émette un événement qui déclenche un autre service à l'intérieur de notre cluster.

Supposons que le service X soit exposé à l'extérieur en utilisant le service nodePort. Après avoir reçu une requête, le service X souhaite communiquer avec le service Y.

Le service Y nécessite les ports suivants

  1. Un port ClusterIP, par lequel le service X transmettra la demande.
  2. Un port cible ClusterIP par lequel le service Y déterminera dans quel port l'application s'exécute.
  3. Un port d'application

port === quelconque

targetPort === port d'application

Service interne X :

app.post('/posts/create', async (req, res) => {
  const id = randomBytes(4).toString('hex');
  const { title } = req.body;

  posts[id] = {
    id,
    title
  };

  await axios.post('http://event-bus-srv:4010/events', {
    type: 'PostCreated',
    data: {
      id,
      title
    }
  });

  res.status(201).send(posts[id]);
});

Configuration et intérieur du service Y

apiVersion: v1
kind: Service
metadata:
  name: event-bus-srv
spec:
  selector:
    app: event-bus
  type: ClusterIP
  ports:
    - name: event-bus
      protocol: TCP
      port: 4010
      targetPort: 4009

app.listen(4009, () => {

  console.log('Listening on 4009');
});

enter image description here

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X