Diferencia entre targetPort y puerto en la definición del servicio Kubernetes

Un Kubernetes Servicepuede tener un targetPorty porten la definición del servicio:

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

¿Cuál es la diferencia entre porty targetPort?

Servicio: Esto dirige el tráfico a un pod.

TargetPort: este es el puerto real en el que se ejecuta su aplicación dentro del contenedor.

Puerto: algunas veces su aplicación dentro del contenedor sirve diferentes servicios en un puerto diferente.

Ejemplo: la aplicación real puede ejecutarse 8080y las comprobaciones de estado de esta aplicación pueden ejecutarse en el 8089puerto del contenedor. Entonces, si ingresa al servicio sin puerto, no sabe a qué puerto del contenedor debe redirigir la solicitud. El servicio debe tener una asignación para que pueda llegar al puerto específico del contenedor.

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 golpea el my-service:8089tráfico se enruta al 8080contenedor (targetPort). Del mismo modo, si golpea my-service:8443, se redirige al 8085contenedor (targetPort). Pero esto myservice:8089es interno al clúster de kubernetes y se puede usar cuando una aplicación quiere comunicarse con otra aplicación. Entonces, para acceder al servicio desde fuera del clúster, alguien necesita exponer el puerto en la máquina host en la que se está ejecutando kubernetes para que el tráfico se redirija a un puerto del contenedor. Esto es node port(puerto expuesto en la máquina host). En el ejemplo anterior, puede acceder al servicio desde fuera del clúster (Cartero o cualquier otro cliente de descanso) mediantehost_ip:nodePort

Digamos que su máquina host IP es 10.10.20.20que puede golpear los protocolos HTTP, las métricas, los servicios de salud 10.10.20.20:30475, 10.10.20.20:31261, 10.10.20.20:30013.

Ediciones: Editado según el comentario de Raedwald .

Me ayuda a pensar en las cosas desde la perspectiva del servicio .

• nodePort: El puerto en el nodo donde entrará el tráfico externo
• port: El puerto de este servicio
• targetPort El puerto de destino en los pod para reenviar el tráfico a

El tráfico entra nodePort, reenvía al portservicio que luego se dirige a targetPortla (s) cápsula (s).

Vale la pena enfatizar más nodePortsobre el tráfico externo. Otros pods en el clúster que pueden necesitar acceder al servicio simplemente lo usarán port, no nodePortporque es solo acceso interno al servicio.

También vale la pena señalar que si targetPortno se establece, el valor predeterminado será el mismo port. Por ejemplo, 80:80para el puerto de servicio 80dirigido al puerto de contenedores 80.

La respuesta dada anteriormente por @Manikanta P es correcta. Sin embargo, la explicación de "Puerto" podría ser un poco confusa en la primera lectura. Explicaré con un ejemplo:

Considere una aplicación web con su contenido estático (portada, imágenes, etc.) alojado por httpd y el contenido dinámico (por ejemplo, respuesta a solicitudes, etc.) alojado por tomcat. El 80servidor web (o el contenido estático) es atendido por httpd en el puerto mientras que el servidor de aplicaciones (o el contenido dinámico) es servido por tomcat en el puerto 8080.

Lo que quiere un desarrollador: el usuario debe poder acceder al servidor web desde afuera PERO no al servidor de aplicaciones desde afuera

Solución: El tipo de servicio del servidor web en su service.yml será NodePort, mientras que el tipo de servicio del servidor de aplicaciones en su service.yml será ClusterIP.

Código para el servidor web service.yml:

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.

Código para el service.yml de 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.

También httpd.conftenga en cuenta que, en el archivo del servidor web, escribiremos la IP que redirige la solicitud de un usuario al servidor de aplicaciones. Esta IP será: host_IP:5050.

¿Qué está pasando exactamente aquí? Un usuario escribe hostIP:30475y ve la página del servidor web. Esto se debe a que httpd lo sirve en el puerto 80(targetport). Cuando un usuario hace clic en un botón, se realiza una solicitud. Esta solicitud se redirige al servidor de aplicaciones porque en el httpd.confarchivo, 5050se menciona el puerto y este es el puerto donde el contenedor del servidor de aplicaciones y el contenedor del servidor web se comunican internamente. Cuando el servidor de aplicaciones recibe la solicitud, puede atender la solicitud debido a que Tomcat se ejecuta dentro de él en el puerto 8080.

Esta respuesta es para hacer referencia a la documentación de Kubernetes además de las otras respuestas:

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

targetPort: es el puerto en el que el contenedor acepta tráfico,

port: es el puerto de servicio abstraído, que puede ser cualquier puerto que otros pods usen para acceder al servicio

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

Las definiciones de puerto en Pods tienen nombres, y puede hacer referencia a estos nombres en el targetPortatributo de un Servicio. Esto funciona incluso si hay una mezcla de Pods en el Servicio que usa un solo nombre configurado, con el mismo protocolo de red disponible a través de diferentes números de puerto.

En pocas palabras

nodeport: Escucha la solicitud externa en todos los nodos de trabajo en nodeip: port y reenvía la solicitud al puerto.

port: Puerto de servicio de clúster interno para contenedor y escucha la solicitud entrante desde el puerto de nodo y reenvía a targetPort.

targetPort:Reciba la solicitud del puerto y reenvíela al contenedor pod (puerto) donde está escuchando. incluso si no especifica esto, se le asignarán por defecto los mismos números de puerto que el puerto.

El "puerto de destino" es el puerto en el que se está ejecutando su contenedor.

Puerto: el puerto redirige el tráfico al contenedor desde el servicio.

Exponiendo el despliegue

  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: es el puerto que permite que el servicio acceda externamente.

Espero que esto responda.

si el contenedor escucha en el puerto 9376, entonces targetPort : 9376

si un servicio escucha en el puerto 80, entonces el puerto : 80

Entonces la configuración de los puertos de servicio se ve a continuación

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

Finalmente, solicitud recibida en el puerto del servicio y enviada al puerto TargetPort del pod.