Ref counting is only applicable to Remote endpoints #101358
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
k8s-ci-robot
added
sig/network
|
/sig windows |
k8s-ci-robot
added
sig/windows
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
/ok-to-test |
k8s-ci-robot
added
the
ok-to-test
|
/retest |
1 similar comment
|
/retest |
|
/assign @Keith-Mange |
|
@sbangari: GitHub didn't allow me to assign the following users: Keith-Mange. Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In 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. |
|
/assign Keith-Mange |
|
@sbangari: GitHub didn't allow me to assign the following users: Keith-Mange. Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In 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. |
|
/lgtm |
|
@sbangari: you cannot LGTM your own PR. In 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. |
|
/lgtm |
|
@Keith-Mange: changing LGTM is restricted to collaborators In 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. |
|
/assign elweb9858 |
| @@ -354,7 +354,7 @@ func newSourceVIP(hns HostNetworkService, network string, ip string, mac string, | |||
|
|
|||
| func (ep *endpointsInfo) Cleanup() { | |||
| Log(ep, "Endpoint Cleanup", 3) | |||
| if ep.refCount != nil { | |||
| if !ep.GetIsLocal() && ep.refCount != nil { | |||
There was a problem hiding this comment.
just double-checking: we do not want to decrement the endpoint ref count if the endpoint is local?
| @@ -354,7 +354,7 @@ func newSourceVIP(hns HostNetworkService, network string, ip string, mac string, | |||
|
|
|||
| func (ep *endpointsInfo) Cleanup() { | |||
| Log(ep, "Endpoint Cleanup", 3) | |||
| if ep.refCount != nil { | |||
| if !ep.GetIsLocal() && ep.refCount != nil { | |||
| *ep.refCount-- | |||
|
|
|||
| // Remove the remote hns endpoint, if no service is referring it | |||
There was a problem hiding this comment.
Having trouble with the git UI, so this comment is really for line 363, but I think the !ep.GetIsLocal() check there is now redundant
There was a problem hiding this comment.
also having more trouble with the UI, but I am wondering why 'ep.refCount = nil' is not within that if block on lines 363-371. If we don't attempt to delete a remote endpoint because the refCount is above zero, why set the refCount to nil? This may be outside the scope of this change, but just doesn't make sense to me
There was a problem hiding this comment.
Consider two services with endpoint objects:
Service1 -> Endpoint1, Endpoint2, Endpoint3
Service2 -> Endpoint1, Endpoint2
And, Service1_Endpoint1 and Service2_Endpoint2 are referring to the same HNS remote endpoint
Original behavior:
Service1_Endpoint1 -> HNSRemoteEndpoint1RefCount
Service1_Endpoint2 -> HNSRemoteEndpoint1RefCount
Deleting Service1 would drop (Service1_Endpoint1 -> HNSRemoteEndpoint1RefCount) to zero and corresponding HNS remote endpoint was deleted, though Service 2 was still using it
Modified behavior:
Service1_Endpoint1 -> *HNSRemoteEndpoint1RefCount ------>
Shared_HNSRemoteEndpoint1RefCount
Service1_Endpoint2 -> *HNSRemoteEndpoint1RefCount ------>
HNSRemoteEndpoint1RefCount is a shared counter and actual refcount's in the endpoint objects are pointers to this shared refcount. Everytime endpoint for a service is cleaned shared refcount is decremented and the refcount pointer on the endpoint is set to nil, so that it can no longer accidentally modify the shared refcount. Once the shared refcount drops to 0 (i.e. no service is using it anylonger) we delete the HNSRemoteEndpoint
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: elweb9858, sbangari The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/kind bug |
k8s-ci-robot
added
kind/bug
|
/retest |
|
@sbangari thanks for fixing this. Is it possible to backport this to 1.21 and 1.20? |
|
/triage accepted |
k8s-ci-robot
added
triage/accepted
…1358-upstream-release-1.20 Automated cherry pick of #101358: Ref counting is only applicable to Remote endpoints
…1358-upstream-release-1.21 Automated cherry pick of #101358: Ref counting is only applicable to Remote endpoints
…1358-upstream-release-1.19 Automated cherry pick of #101358: Ref counting is only applicable to Remote endpoints
What type of PR is this?
/kind bug
What this PR does / why we need it:
The ref counting logic in Windows kube-proxy is only applicable to remote endpoints. There are instances where the nonessential ref counting on local endpoints is causing a panic in kube-proxy due to ref count object being nil. This PR scopes the ref counting logic only to remote endpoints.
Which issue(s) this PR fixes:
Fixes #100384
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: