A Kubernetes Service can have a targetPort and 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 port and targetPort?
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.
Example: 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. This is node port(port exposed on the host machine).
From the above example, you can hit the service from outside the cluster(Postman or any rest-client) 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.
port and targetPort to be different? So for example looking at your health example, why make the port 8443 instead of 8085? Basically, why are there two parameters instead of just exposing all the targetPorts on the service? –
Leelah It helps me to think of things from the perspective of the service.
nodePort: The port on the node where external traffic will come in onport: The port of this servicetargetPort The target port on the pod(s) to forward traffic toTraffic comes in on nodePort, forwards to port on the service which then routes to targetPort on the pod(s).
It's worth emphasizing that nodePort is for external traffic. Other pods in the cluster that may need to access the service will just use port, not 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 port. E.g. 80:80 for service port 80 targeting container port 80.
In nutshell
nodeport: Listens for external request on all worker nodes on nodeip:nodeport and forwards the request to port.
ClusterIP: Request comes through ingress and points to service name and port.
port: Internal cluster service port for container and listens for incoming request from the nodeport and forwards to targetPort.
targetPort: Receives the request from port and forwards to container pod(port) where it's listening. Even if you don't specify this will get by default assigned the same port numbers as port.
So the traffic flows Ingress-->Service-->Endpoint(Basically has POD IP)-->POD
if container listens on port 9376, then targetPort: 9376
if a service listens on port 80, then port: 80
Then service ports config looks like below
ports:
- protocol: TCP
port: 80
targetPort: 9376
Finally, request received to the service’s port, and forwarded on the targetPort of the pod.
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.
httpd.conf in "because in httpd.conf file, the port 5050 is mentioned " –
Vikiviking 80 and 8080. –
Vikiviking Since people have explained port and targetPort in Kubernetes Service definition, I'll add information on how Dockerfile, Kubernetes Deployment and Kubernetes Ingress come into picture because they are part of a common workflow.
DockerfileLets say you're running a Flask server on port 3000 and a Golang server on port 4000. When you containerize these applications using Docker, you'll have to expose ports 3000 and 4000 in their Dockerfiles:
Application
...
...
if __name__ == "__main__":
app.run(host='0.0.0.0', port=3000)
Dockerfile
FROM python:3.10-alpine
...
...
EXPOSE 3000
CMD ...
Application
...
...
func main() {
...
log.Fatal(http.ListenAndServe(":4000", nil))
}
Dockerfile
FROM golang:1.18-alpine
...
...
EXPOSE 4000
CMD ...
Dockerfiles and Kubernetes DeploymentsThe exposed ports in Dockerfiles will have to match the containerPort in the deployment manifests.
Python Deployment Manifest
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: python-flask-api
spec:
...
...
app: flask-api
template:
metadata:
labels:
app: flask-api
spec:
containers:
- name: flask-api
image: ...
ports:
- containerPort: 3000
...
...
Golang Deployment Manifest
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: go-backend-api
spec:
...
...
app: go-api
template:
metadata:
labels:
app: go-api
spec:
containers:
- name: go-api
image: ...
ports:
- containerPort: 4000
...
...
The containerPort in the deployment manifests will have to match the targetPort in the service manifests
Python Service Manifest
apiVersion: v1
kind: Service
metadata:
name: flask-api-service
spec:
type: NodePort
selector:
app: flask-api
ports:
- port: 80
targetPort: 3000
Golang Service Manifest
apiVersion: v1
kind: Service
metadata:
name: go-api-service
spec:
type: NodePort
selector:
app: go-api
ports:
- port: 443
targetPort: 4000
The port in the service manifest will have to match the port number in the ingress
AWS Ingress for Python and Golang application
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: microservice-app-ingress
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
rules:
- host: foo.biz.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: go-api-service
port:
number: 443
- host: bar.biz.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: flask-api-service
port:
number: 80
An incoming request hits the ingress on a port number
The ingress forwards this request to the service port
The service port maps the port to a targetPort
From the service targetPort the request goes to the deployment containerPort
The deployment containerPort is the application's Docker image, which has this corresponding port exposed in its Dockerfile
And finally, the exposed port in Dockerfile sends the request to the application
Case 1:
Let's assume that there is no nodPort or port, now you want to run your aplication and expose it to outside, what you will need:
So, to get access from outside we found three port needed.
to work everything properly : servicePort === targetPort === networkPort
Case 2: Now assume that one service communicate with another service in our cluster, or let's assume one service received a request from out side and it emits an event which triggered another service inside of our cluster.
Suppose Service X is exposed outside by using nodePort Service, after receving a request, X service want to communicate with Y service.
Y service need following ports
port === any
targetPort === application port
Inside Service 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 and Inside of 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');
});
This answer is to reference Kubernetes' documentation in addition to the other answers:
https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/:
targetPort: is the port the container accepts traffic on,
port: is the abstracted Service port, which can be any port other pods use to access the Service
https://kubernetes.io/docs/concepts/services-networking/service/:
Port definitions in Pods have names, and you can reference these names in the
targetPortattribute of a Service. This works even if there is a mixture of Pods in the Service using a single configured name, with the same network protocol available via different port numbers.
targetport: One or more ports on which a container listens within a pod.
nodeport: Used primarily to accept consumer requests. (Eg: HTTP request from consumers to a webserver running in a container)
nodeport is listened on all nodes on all interfaces i.e 0.0.0.0:nodeport. Consumer service requests sent to nodeport is routed to container's targetport so that the container can fulfill the request.
port: Port used within the kubernetes pod network, primarily used to exchange requests between pods. Here as well, requests to a pod from another, is routed to the corrosponding pod's container targetport.
Summary: all requests end up in the targetport. nodeport is used if request from outside k8s network & port if from within.
Ref- Difference between kubernetes service types
ClusterIP Service Type Flow
Here the internal client will call the service port 80 on which the kubernetes service is deployed and then finally to target port 8080 which is the port on which the pod application
is running.
The configuration for above will be -
apiVersion: v1
kind: Service
metadata:
name: employee-producer-service
spec:
selector:
app: boot-jar
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP
Nodeport Service Type Flow
Here the external client will call the nodeport 30080 which has been exposed to the external client. This request will then be forwarded to service port 80 on which the kubernetes service is deployed and then finally to target port 8080 which is the port on which the pod application is running.
The configuration for above will be -
apiVersion: v1
kind: Service
metadata:
name: employee-producer-service
spec:
selector:
app: boot-jar
ports:
- protocol: TCP
port: 80
targetPort: 8080
nodePort: 30080
type: NodePort
"Target port" is the port on which your container is running.
Port : port redirects the traffic to the container from the service.
Exposing the deployment
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 : is the port that enables the service to access the externally.
Hope this answers.
Let's clarify the differences between port, targetPort, and nodePort in Kubernetes:
port: It is used in the Service specification to define the port number that the Service will listen on.It represents the port that other components within the cluster can use to communicate with the Service. When traffic reaches the Service, it will be forwarded to the appropriate targetPort on the Pods backing the Service.
targetPort: It is used in the Service specification to specify the port on the Pods to which the traffic should be forwarded.It represents the port number on the Pod's container that is accepting the traffic. When traffic reaches the Service, it is redirected to the targetPort of the Pods that match the Service's selector.
nodePort:It is used in the Service specification of type NodePort to specify the port number that is exposed on each node in the cluster. It allows external traffic to access the Service by forwarding traffic from that port on the node to the Service.The nodePort value must be within the range of 30000-32767 by default, although you can specify a specific port within that range or let Kubernetes assign one automatically.
In summary, port is the port number that the Service listens on, targetPort is the port number on the Pods where the traffic is forwarded, and nodePort is the port number exposed on each node for external access when using the NodePort type Service.
FOR REFFERENCE in docker-compose we specify
ports:
- 8080:80
from top you can compare 8080 which is host port represents Port and 80 as TargetPort
Target Port Explanation
# pod file
apiVersion: v1
kind: Pod
metadata:
name: pod_name
labels:
name: pod_ref
spec:
containers:
- name: docker-container
image: python:3:11
ports:
- containerPort: 5000 # this is the target port which we need to access (target) from service file
---
apiVersion: v1
kind: Service
metadata:
name: service_config
labels:
name: service_config_ref
spec:
type: NodePort
selector:
name: pod_ref # same as pod metadata match labels
ports:
- targetPort: 5000 # this is where the pod is listening
port: 80 # this is where this service (this file) is going to listen.
# If you call the port 80, it will reach the service, then the service will forward the port to port:5000
A service is an abstraction that is used to redirect traffic to the underlying pod. Hence:
port: 80 --> identifies the port where the service is listening targetPort: 8080 --> identifies the target port where the underlying pod is deployed
a call to my_service:80 will redirect the traffic to the the underlying pod on 8080 (as per the given example).
© 2022 - 2024 — McMap. All rights reserved.