apiserver endpointslice reconciler should be smarter about what slices it owns

[danwinship]

Currently the apiservers create an Endpoints object and an EndpointSlice object named "kubernetes", and ensure that those objects remain in sync with the actual set of running apiservers.

In particular, it only ever looks at the EndpointSlice named "kubernetes", and not any other EndpointSlices. This could lead to problems when trying introduce dual-stack support for the apiserver:

1. User creates a dual-stack 1.21 cluster; the "kubernetes" service is single-stack, and advertises only IPv4 endpoints in Endpoints and EndpointSlice.
2. User initiates an upgrade to release 1.22, where (hypothetically) dual-stack apiserver is supported
3. The first 1.21 apiserver stops, removing its IPv4 address from the "kubernetes" Endpoints and EndpointSlice
4. The first apiserver starts up again at version 1.22, adds its IPv4 address back to the "kubernetes" Endpoints and EndpointSlice, and creates a new "kubernetes-ipv6" EndpointSlice (or something) containing its IPv6 address.
5. The apiserver then crashes due to a bug. The upgrade stalls, and the user decides to abort and downgrade back to 1.21
6. The apiserver starts up again at version 1.21, finds that its IP is already in the "kubernetes" Endpoints and EndpointSlice, and so does nothing else
7. At this point, there is a stray "kubernetes-ipv6" EndpointSlice object which no one owns, pointing to an IPv6 address which may or may not actually be usable (and which will definitely not remain usable forever even if it is usable now).

It seems like the apiserver EndpointSlice reconciling code ought to be smarter, and consider itself the owner of all EndpointSlices that have an OwnerReference pointing to the apiserver Service. (Though note that it's not currently setting OwnerReference.) Then in step 6 above, the 1.21 apiserver would delete the stray "kubernetes-ipv6" EndpointSlice that had been created by its 1.22 self. (This approach would cause flapping during upgrade, where the old apiservers would keep deleting the IPv6 EndpointSlice created by the new apiservers, but that would only be a transient problem while the upgrade was in progress, and would eventually resolve (correctly) one way or the other once the cluster stabilizes at a single version.)

/cc @robscott
/sig network
/area apiserver

[k8s-ci-robot]

@danwinship: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[aojea]

related kubernetes/enhancements#2622

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[aojea]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[danwinship]

/remove-lifecycle rotten
/lifecycle frozen
/assign
(will end up fixing this as part of the dual-stack apiserver work)