What's the version relationship of kubernetes between karmada control plane and member?

[carlory]

Please provide an in-depth description of the question you have:

I have two member clusters, one is kubernetes v1.25 and the other is kubernetes v1.18. I want to propagate an ingress to these two clusters. Those two member clusters don't share a possible ingress version. I don't known how to choose the right kuberentes version for karmada control plane.

# v1.25
~ kubectl api-resources | grep ingress
ingresses                         ing                  networking.k8s.io/v1               true         Ingress

# v1.18
~ kubectl api-resources | grep ingress
ingresses                         ing                  extensions/v1beta1                      true         Ingress
ingresses                         ing                  networking.k8s.io/v1beta1               true         Ingress

How does karmada control plane deal with the different versions of kubernetes when users want to propagate a ingress resource? I cannot find the answer in the office documentation.

when I want to propagate a ingress (v1beta1) into all the member clusters, the karmada-scheduler won't schedule it to the v1.25 cluster due to the AIPEnablement plugin limitation.

If I want to propagate a ingress (v1) into all the member clusters, the karmada-apiserver must contain the v1 ingress API according to the current implementation.

In this case, I cannot find a suitable kubernetes version for karmada control plane.

This link says the kubernetes-comaptibility of karmada. but I don't know that this kubernetes-comaptibility table is designed for karmada control plane or member cluster?

for example, the mcs feature requires that the karmada control plane and member clusters must be v1.21 or higher. However, according to the kubernetes-comaptibility table, the range of v1.16 - v1.20 is supported.

In summary, the core question is that the karmada how to handle the different versions of kubernetes between karmada control plane and member clusters?

What do you think about this question?:

Karmada should support the different versions of kubernetes between karmada control plane and member clusters. As karmada users, they should not care about the resoure version of member clusters. They just need to propagate the resource to all the member clusters that supports the resource.

[edit]:

• @RainbowMango: similar questions are #4081

[RainbowMango]

Good question. I think it'd be better to have a document to clarify this question. /assign

[RainbowMango]

As discussed at the community meeting, I'm going to add a document to explain the Kubernetes compatibility thing. Sorry for the delay, but it is still on my agenda and I hope to get back to this next month.

[dg424]

Is there a final answer to this question ?

[RainbowMango]

Not yet, so sorry for the delay. :(

I understand that there are indeed some users using alpha or beta APIs, but Karmada can only distribute one version at a time and can not follow the member clusters to convert versions.

If users encounter this problem, it is recommended to use the stable API, and if necessary upgrade the cluster to support the stable API.

I'm still considering whether it is possible to provide the ability to convert versions in Karmada, but there is no mature solution at present.

Any ideas, suggestions, and feedback are welcome. Thanks.