The Version Skew Policy does not mention aggregated apiservers

[MikeSpreitzer]

What happened?

Someone opened #124533 saying

I expected 1.29 libraries to still be compatible with Kubernetes 1.28 based on the kube-apiserver version skew.

I think that is not what the version skew policy (https://kubernetes.io/releases/version-skew-policy/) is trying to say. I think that the guiding principle is that you must first upgrade the servers that store objects of a given API group and resource/kind, then upgrade the clients of those servers.

In particular, the existing version skew policy document explicitly discusses several kinds of components, but does not mention aggregated apiservers. I think that these should be explicitly mentioned.

What did you expect to happen?

Everybody agrees on what to expect.

How can we reproduce it (as minimally and precisely as possible)?

Read the cited doc and Issue.

Anything else we need to know?

Nope

Kubernetes version

All of them.

Cloud provider

N/A

OS version

N/A

Install tools

N/A

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

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.

[MikeSpreitzer]

@kubernetes/sig-api-machinery-bugs

[sftim]

@MikeSpreitzer if you agree, I suggest you transfer this to k/website. The Prow command for that is /transfer website.

[sftim]

AIUI Kubernetes release versioning doesn't apply to any aggregated API servers, although some of the components you might run use library code that we release.

You can implement an API server in any language and you don't need to have any Kubernetes code in your implementation. However, your aggregated API server should ideally to be compatible with every API server in your control plane at any point during an upgrade. We can still document more about compatibility than we do right now.

[dims]

wasn't this talked about recently @MikeSpreitzer ? #124533 (comment)

[seans3]

I think the other issue #124533 has been transitioned to a docs issue. I will close this one in favor of the other one. Please re-open if I am mistaken.

/close

[k8s-ci-robot]

@seans3: Closing this issue.

In response to this:

I think the other issue #124533 has been transitioned to a docs issue. I will close this one in favor of the other one. Please re-open if I am mistaken.

/close

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-sigs/prow repository.