educative.io

Doubt regarding how targetPort works and should be specified

Courses
,
#1 
apiVersion:  apps/v1
kind: ReplicaSet
metadata:
  name: go-demo-2-db
spec:
  selector:
    matchLabels:
      type: db
      service: go-demo-2
  template:
    metadata:
      labels:
        type: db
        service: go-demo-2
        vendor: MongoLabs
    spec:
      containers:
      - name: db
        image: mongo:3.3
        ports:
        - containerPort: 28017

---

apiVersion: v1
kind: Service
metadata:
  name: go-demo-2-db
spec:
  ports:
  - port: 27017
  selector:
    type: db
    service: go-demo-2

In the spec file mentioned in this and the previous lesson, the containerPort in the pod template is set to 28017 (mondoDB) and for the service there is no targetPort, but the service’s port is set 27017. I am not sure how a request to go-demo-2-db service at port 27017 gets routed correctly to the container’s 28017 port. Can you please explain?

Thanks!

Course: https://www.educative.io/courses/a-practical-guide-to-kubernetes
Lesson: Educative: Interactive Courses for Software Developers

#2

Hi @Sanjay_George !!
In Kubernetes, when you define a Service, you associate it with a set of Pods using labels and selectors. The key to understanding how requests to the go-demo-2-db Service at port 27017 get correctly routed to the container’s port 28017 lies in the way Services and Endpoints work together.

Here’s how it works:

  1. Service Definition: In your provided YAML for the go-demo-2-db Service, you specify the ports section with port: 27017. This means that the Service itself listens on port 27017.

  2. Selector: You also specify a selector in the Service definition with type: db and service: go-demo-2. This selector is used to match Pods that should be part of this Service.

  3. Endpoint Discovery: When you create this Service, Kubernetes looks for Pods that match the selector labels (type: db and service: go-demo-2). In your case, you have a ReplicaSet (go-demo-2-db) with Pods that have these labels. The Service automatically discovers the endpoints (IP addresses and ports) of these Pods.

  4. Request Routing: When a request is made to the go-demo-2-db Service on port 27017, Kubernetes’ internal networking system takes care of routing the request to one of the Pod endpoints that match the selector labels. It does this by using IP tables rules to perform the network address translation (NAT).

  5. Pod Communication: Inside the Pod, your MongoDB container is configured to listen on port 28017. However, from the perspective of the container, it appears as if the request is coming to port 27017, thanks to the Kubernetes networking magic.

In summary, the key is that Kubernetes uses the Service definition to discover the endpoints (Pods) that should receive traffic. It then handles the routing of incoming requests to those endpoints, even if the ports don’t match exactly between the Service and the Pod containers. This decoupling of the Service port and the Pod container port allows you to abstract away the specifics of each Pod’s configuration and easily manage the communication between different parts of your application.
I hope it helps. Happy Learning :blush:

1 Like