need a conformance test for named ports in Services
#132,954 opened on 2025年7月15日
説明
The service docs say:
Port definitions in Pods have names, and you can reference these names in the
targetPortattribute of a Service. For example, we can bind thetargetPortof the Service to the Pod port in the following way:...
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. This offers a lot of flexibility for deploying and evolving your Services. For example, you can change the port numbers that Pods expose in the next version of your backend software, without breaking clients.
But we don't actually explicitly test this functionality (and it apparently does not work with the winkernel kube-proxy backend, discussed here.)
There should be an e2e test (which should eventually be promoted to conformance) that does:
- Create 2 agnhost pods listening on some port which is exposed as a
ContainerPort(eg,{ name: "test", containerPort: 8000 } - Create a Service that targets those pods, referring to the
targetPortby name rather than number. (eg{ port: 80, targetPort: "test" }) - Confirm that the service reaches both pods.
- Delete 1 pod and replace it with a pod listening on a different-numbered port, but with the same name. (eg,
{ name: "test", containerPort: 8080 }) - Confirm that the service still reaches both pods.
- Delete the other pod and replace it with one using the same new port
- Confirm that the service still reaches both pods.
(We don't actually want to use a Deployment in the test, because we need to ensure that we test reachability in the middle of the "roll-out".)
("make sure the service reaches both endpoints" is essentially equivalent to "make sure that the service does not have session affinity" and so the helpers for the affinity tests can be used there.)
/sig network /priority important-longterm /help