Understanding targetPort in Kubernetes

In Kubernetes, when defining a Service to expose your application, the concept of targetPort plays a crucial role in routing incoming traffic to the correct destination within your Pods.

What is targetPort?

• Definition: targetPort is a field in the Service definition that specifies the port on the Pod containers to which the traffic should be forwarded. It allows the Service to direct incoming requests to the specific port where the application inside the Pod is listening.

How does targetPort work?

• When a Service is created, it defines how to access a set of Pods. The targetPort is part of this definition, ensuring that the traffic reaching the Service is routed to the correct port on the Pods.
• The Service routes traffic from its own port (port field in the Service definition) to the targetPort on the Pods.
• targetPort can be specified as a numerical port value or as the name of a port defined in the Pod spec, providing flexibility in how Services route traffic.

Example Usage

Consider a web application running in a Pod, listening on port 8080. You want to expose this application through a Service:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

• selector: Determines which Pods will be part of this Service. In this case, all Pods with the label app=web-app.
• port: The port on which the Service is exposed within the cluster. Other components within the cluster will use this port to communicate with the Service.
• targetPort: The port on the Pod(s) to which the Service forwards traffic. Here, it’s set to 8080, matching the application’s listening port within the Pods.

Why is targetPort important?

• Flexibility: Allows Pods to use different port numbers, even if the Services exposing them use a common port. For example, multiple Services can expose port 80, while forwarding to different targetPort values on their respective Pods.
• Simplicity: By decoupling the Service port from the Pod port, Kubernetes services can remain consistent even if the internal configurations of Pods change.

Considerations

• Matching Ports: While targetPort provides flexibility, it’s common in simple setups for the port and targetPort to have the same value, especially when there’s a standard port used by the application across all Pods.
• Named Ports: Using named ports in the Pod spec can enhance clarity. When a port in a Pod template is named, the targetPort value in the Service definition can reference this name, making the Service’s purpose more understandable.

Understanding targetPort is fundamental for configuring network access to applications running in Kubernetes, ensuring that traffic is efficiently and accurately routed to the correct application instances within your Pods.

Diagram Explanation

• Internet: Represents external traffic coming into the cluster.
• Load Balancer: An optional component, typically used in cloud environments, that distributes incoming traffic across multiple nodes. This is relevant when the Service type is LoadBalancer.
• NodePort: A high port (30000-32767) opened on every node by the Kubernetes Service of type NodePort. Traffic to this port is forwarded to the port defined on the Service.
• Port (Service Port): The port on which the Service is exposed inside the cluster. Other components within the cluster communicate with the Service through this port.
• targetPort: The port on the Pod to which the Service forwards the traffic it receives. This is the port where your application is running inside the Pod.
• Pod: The smallest deployable unit in Kubernetes, running your application container(s).

Example Scenario

Imagine you have a web application running in a Pod, listening on port 8080. You create a Service of type NodePort to expose this application:

• NodePort: 32000 (The port opened on all nodes for external traffic)
• Port (Service Port): 80 (The port on which the Service is exposed inside the cluster)
• targetPort: 8080 (The port on the Pod where the web application is listening)

Traffic from the internet reaches the Load Balancer (if used), which then directs it to one of the nodes on port 32000. This traffic is then routed through the Service on port 80, which finally forwards it to the Pod on targetPort 8080, where the application processes the request.

This setup demonstrates how Kubernetes Services use NodePort, port, and targetPort to manage traffic flow from external sources to the application running inside Pods.