Change:
portMapping(v1.ProtocolTCP, 1234, 5678, ""), }, }, <ins> { // The same container port can be mapped to different host ports &v1.Container{ Name: "fooContainer", Ports: []v1.ContainerPort{ port("", v1.ProtocolTCP, 443, 4343, "192.168.0.1"), port("", v1.ProtocolTCP, 4343, 4343, "192.168.0.1"), }, }, []PortMapping{ portMapping(v1.ProtocolTCP, 443, 4343, "192.168.0.1"), portMapping(v1.ProtocolTCP, 4343, 4343, "192.168.0.1"), }, }, { // The same container port AND same container host is not OK &v1.Container{ Name: "fooContainer", Ports: []v1.ContainerPort{ port("", v1.ProtocolTCP, 443, 4343, ""), port("", v1.ProtocolTCP, 443, 4343, ""), }, }, []PortMapping{ portMapping(v1.ProtocolTCP, 443, 4343, ""), }, }, { // multihomed nodes - multiple IP scenario &v1.Container{ Name: "fooContainer", Ports: []v1.ContainerPort{ port("", v1.ProtocolTCP, 443, 4343, "192.168.0.1"), port("", v1.ProtocolTCP, 443, 4343, "172.16.0.1"), }, }, []PortMapping{ portMapping(v1.ProtocolTCP, 443, 4343, "192.168.0.1"), portMapping(v1.ProtocolTCP, 443, 4343, "172.16.0.1"), }, }, </ins> } for i, tt := range tests {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: A container ports spec such as: Results in this error: From . Because of this, the port mappings are not setup correctly on the host when using a CNI-compliant portmap solution. What you expected to happen: Auto-generated port names should never result in duplicates How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig node Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-01-16T21:59:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.11", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-04-05T17:16:46Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: VirtualBox OS (e.g. from /etc/os-release): Ubuntu Kernel (e.g. ): Linux node2 4.4.0-104-generic -Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with .

Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
I see that the problem is legit, but is this setup frequently used? why not using services instead of hostports? I mean, it will complicate more the solution but will provide a good abstraction and remove the dependency on the node.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Why is this still an issue?
Issues go stale after 90d of inactivity.

Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale