kubernetes: Services allow duplicate targetPort

It is possible to express a Service where multiple front-side ports target the same back-side port. This is not very useful and may cause trouble for implementations of Services.

apiVersion: v1
kind: Service
metadata:
  name: hostnames-2
spec:
  ports:
  - name: a
    port: 80
    targetPort: 9376
  - name: b
    port: 81
    targetPort: 9376
  selector:
    run: hostnames

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 22 (15 by maintainers)

Commits related to this issue

Most upvoted comments

@thockin what problems did this cause with services? This change broke backwards compatibility for services that depended on this feature.

For example, lets take the load balancer service

kind: Service
apiVersion: v1
metadata:
  name: nginx-service
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
spec:
  selector:
    app: nginx
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80

The load balancer here terminates SSL so the backend is always port 80; however, you want to make sure you support both protocols so having the same targetPort here is a valid use case.

I think that should probably be rejected at validation unless we have a good reason WHY we need that.

On Thu, Jun 8, 2017 at 11:21 PM, Emmanuel T Odeke notifications@github.com wrote:

@thockin https://github.com/thockin just for the purpose of clarity, are you requesting that duplicate targetPorts should be rejected or the opposite? PS: I am new to Kubernetes so please pardon the dumb question 😃

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/kubernetes/issues/47222#issuecomment-307305784, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVH6eTLB4Z_QYaAdxrdqqJy_NgVtNks5sCOR6gaJpZM4N07AA .

This is not an abuse of Service, but a quite common and wide-adopted pattern, especially in the AWS world.