Service can have a
port in the service definition:
kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376
What is the difference between the
Service: This directs the traffic to a pod.
TargetPort: This is the actual port on which your application is running inside the container.
Port: Some times your application inside container serves different services on a different port. Ex:- the actual application can run 8080 and health checks for this application can run on 8089 port of the container. So if you hit the service without port it doesn't know to which port of the container it should redirect the request. Service needs to have a mapping so that it can hit the specific port of the container.
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
if you hit the my-service:8089 the traffic is routed to 8080 of the container(targetPort). Similarly, if you hit my-service:8443 then it is redirected to 8085 of the container(targetPort).
But this myservice:8089 is internal to the kubernetes cluster and can be used when one application wants to communicate with another application. So to hit the service from outside the cluster someone needs to expose the port on the host machine on which kubernetes is running so that the traffic is redirected to a port of the container. In that can use nodePort.
From the above example, you can hit the service from outside the cluster(Postman or any restclient) by host_ip:Nodeport
Say your host machine ip is 10.10.20.20 you can hit the http,metrics,health services by 10.10.20.20:30475,10.10.20.20:31261,10.10.20.20:30013
Edits: Edited as per Raedwald comment.
The answer given above by @Manikanta P is correct. However, the explanation of "Port" might be a little unclear at first reading. I will explain with an example:
Consider a Web-Application with its static content (front-page, images etc) hosted by httpd and the dynamic content (eg. response to requests, etc.) hosted by tomcat. The Webserver (or the static content) is served by httpd at port 80 while Appserver (or the dynamic content) is served by tomcat at port 8080.
What a developer wants: User should be able to access the Webserver from outside BUT not the Appserver from outside.
Solution: The service-type of Webserver in its service.yml will be NodePort while the service-type of Appserver in its service.yml will be ClusterIP.
Code for webserver's 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.
Code for Appserver's service.yml
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.
Also Note, in the httpd.conf file of the Webserver, we will write the IP that redirects a user's request to the appserver. This IP will be: host_IP:5050.
What exactly is happening here? A user writes hostIP:30475 and sees the Webserver's page. This is because it is being served by httpd at port 80 (targetport). When a user clicks a button, a request is made. This request is redirected to the Appserver because in httpd.conf file, the port 5050 is mentioned and this is the port where Appserver's container and Webserver's conatainer communicate internally. When the appserver receives the request, it is able to serve the request because of tomcat running inside it at port 8080.
It me helps to think of things from the perspective of the service.
nodePort: The port on the node where external traffic will come in on
port: The port of this service
targetPortThe target port on the pod(s) to forward traffic to
Traffic comes in on
nodePort, forwards to
port on the service which then routes to
targetPort on the pod(s).
It's worth emphasizing more that
nodePort is for external traffic. Other pods in the cluster that may need to access the service will just use
nodePort as it's internal only access to the service.
Also worth noting that if
targetPort is not set, it will default to the same value as
80:80 for service port
80 targeting container port