kubernetes: Windows cannot resolve targetport name
What happened: Windows nodes do not correctly resolve targetport when it is specified as a name
What you expected to happen: Window a kube proxy should select the correct port from the port list in the Service object
How to reproduce it (as minimally and precisely as possible): deploy a ClusterIP service where the targetport is specified as the name of a port and not a port number. Loadbalancing will fail when the client is a Windows container regardless of where the service is deployed (Windows or Linux)
Anything else we need to know?:
Environment:
- Kubernetes version (use
kubectl version): Applicable since Windows GA - Cloud provider or hardware configuration:
- OS (e.g:
cat /etc/os-release): Windows - Kernel (e.g.
uname -a): - Install tools:
- Network plugin and version (if this is a network-related bug): n/a
- Others:
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (12 by maintainers)
@ksubrmnn
I am interested in this issue, can I follow up? I don’t know if my steps to reproduce are correct. A deployment of a windows container is created, the containerPort is specified by the name
http, and then thishttpis used for mapping in the service. Finally,as the picture shows access through nodeip:port. Everything looks normalSure
@JocelynBerrendonner @daschott Can you please assign this issue to someone in core net? This impacted AKS customers. I can explain the fix, it is fairly simple
@ksubrmnn: The label(s)
sig/cannot be applied, because the repository doesn’t have themIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/sig windows