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?
Respuestas:
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 .
porty targetPortser diferente? Entonces, por ejemplo, mirando su healthejemplo, ¿por qué hacer el en port 8443lugar de 8085? Básicamente, ¿por qué hay dos parámetros en lugar de exponer todos los targetPorts en el servicio?
Me ayuda a pensar en las cosas desde la perspectiva del servicio .
nodePort: El puerto en el nodo donde entrará el tráfico externoport: El puerto de este serviciotargetPort El puerto de destino en los pod para reenviar el tráfico aEl 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.
porty targetPort. Realmente despejaste la confusión.
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.
httpd.confen "porque en el archivo httpd.conf, se menciona el puerto 5050"
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.