Change:
I came across a cluster where it has 2 services with port collision. One service looks like this: The other looks like: I checked the logic that allocates nodeport and healthcheck nodeport. They went thru the same node port allocator. Port allocation mainly happens in , and . The file in question is
cc
/cc
I'm not clear on your context. Which case were you facing? config and create the two services as you mentioned manifests, then get errors due to the collided ports? create the two services without specifying the two ports, then get the services and find they have collided ports? Also, what is the expected behavior you were thinking of?
When I checked the cluster, there were 2 services with colliding ports. I am not sure what brought the cluster into this state.
It's strange... I will try to dig into it later.
Seems like there is a race condition. PR sent. PTAL.
I first thought there was a race condition too. But I checked the API log. The operation on the 2 services are quite separated. Then I am not sure.
Oh... So strange. I will take another look at the code to try to find some clues. Btw, does the lock to make any sense? It doesn't fix this issue though.
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /assign /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
/assign
Found the issue. It's due to the nodeport repair controller ignoring the healthCheckNodePort.
Will send a PR and cherrypicks.

Discussion:
servicePorts = append(servicePorts, int(servicePort.NodePort)) } } <ins> if service.Spec.HealthCheckNodePort != 0 { servicePorts = append(servicePorts, int(service.Spec.HealthCheckNodePort)) } </ins> return servicePorts }

Ports: []api.ServicePort{{NodePort: 111}}, }, }, <ins> &api.Service{ ObjectMeta: metav1.ObjectMeta{Namespace: "six", Name: "six"}, Spec: api.ServiceSpec{ HealthCheckNodePort: 144, }, }, </ins> ) registry := &mockRangeRegistry{

if err != nil { t.Fatal(err) } <del> if !after.Has(111) || !after.Has(122) || !after.Has(133) { </del> <ins> if !after.Has(111) || !after.Has(122) || !after.Has(133) || !after.Has(144) { </ins> t.Errorf("unexpected portallocator state: %#v", after) } <del> if free := after.Free(); free != 98 { </del> <ins> if free := after.Free(); free != 97 { </ins> t.Errorf("unexpected portallocator state: %d free", free) } }