1.29-apiserver based aggregated APIServer does not work against 1.28 kube-apiserver about kubernetes HOT 11 OPEN

/sig api-machinery

from kubernetes.

cc @tkashem @MikeSpreitzer

from kubernetes.

Has this skew direction (aggregated apiserver newer than kube-apiserver) been supported historically?

from kubernetes.

That's a good point, when I looked at the official doc we didn't mention it anywhere so I guess that it might just not be supported? Thinking about it again, it would make more sense to me that we would not support this.

Feel free to close if we don't support this skew direction

from kubernetes.

IIUC, at least for Kube components, nothing can be newer than the kube-apiserver (or newer than the oldest kube-apiserver, if there is skew between kube-apiserver instances): https://kubernetes.io/releases/version-skew-policy/. I would feel better about closing if someone else can +1 my understanding.

from kubernetes.

We can tweak the docs to clarify the situation, whichever way we decide / confirms it goes.

from kubernetes.

nothing can be newer than the kube-apiserver (or newer than the oldest kube-apiserver, if there is skew between kube-apiserver instances)

I think you mean “no component other than the API server can be newer than the API server, and API servers that are not the oldest API server version can be at most one minor version newer than the oldest API server version”. Does that sound right @benluddy?

from kubernetes.

I'm not sure. The language needs to distinguish between the kube-apiserver and aggregated apiservers. The existing docs are clear about skew between kube-apiserver instances:

In highly-available (HA) clusters, the newest and oldest kube-apiserver instances must be within one minor version.

And the supported skew between kube-apiserver and the named components in the doc is relative to the version of the oldest kube-apiserver instance.

The ambiguity here is with the supported skew between kube-apiserver and any aggregated apiserver based on a particular version of k8s.io/apiserver.

from kubernetes.

Controller clients outside kube-apiserver can't be newer than the kube-apiserver they are talking to (true for kubelet, kube-controller-manager and kube-scheduler, true for aggregated apiservers as well)

kube-apiserver supports -1 skew because it talks to itself for APIs it needs for running admission stuff like flowcontrol and webhook/CEL admission, so it is guaranteed to have access to the latest API version.

Controllers that talk to kube-apiserver have to wait until kube-apiserver is upgraded to have the same guarantee.

We should describe that better in skew docs

/remove-kind bug
/kind documentation

from kubernetes.

This was discussed at length today in the SIG meeting: https://www.youtube.com/watch?v=0TXm-DGcK1k, starting at minute 33:00

from kubernetes.

/triage accepted

from kubernetes.