-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove usage of the kubeadm ClusterStatus object in Cluster API. #4423
Comments
/assign @fabriziopandini /kind deprecation feature |
@neolit123 Thanks for opening this issue. It is on my agenda for the next week |
The implementation of an alternative approach of Given that and the fact that Cluster API must support the latest three Kubernetes releases for workload clusters (as of today v1.21, v1.20, v1.19), there are no blockers for dropping This will allow some cleanups in KCP
The downside of this change is that Cluster API / KCP v1alpha4 won't be able to manage Kubernetes clusters < v1.17, but this should not be a problem given that this release is out of the support skew. Another important thing to notice is that dropping @vincepri @detiber @CecileRobertMichon opinions ^^ ? |
👍
Would that be breaking back compat rules for beta, ie. support for the last 3 release and/or up to a year ? Not sure if supporting new k8s versions is part of the contract. |
We should definitely document this bit and potentially block and upgrade to v0.4 if a cluster is older than 1.18
Up until today the Kubernetes version support for workload clusters has been pretty wide, we've allowed the supported version range to be quite wide. As an end user, I'd probably want some guarantees on which k8s versions are expected to be supported for a given series, and what are possible exceptions that have to make users upgrade. If we maintain a stable release, we should always strive to support the latest Kubernetes versions, as these come with important patches most of the times, and it's generally a good practice to upgrade especially from versions that fall out of support. Thoughts? |
Not sure if we want to go there, but if I'm not mistaken we don't necessarily need kubeadm v1.22 to create a v1.22 Kubernetes clusters (or at least something like this worked in the past). So if other workarounds for v1alpha3 are more complicated, maybe we can use a kubeadm version < v1.22 to create Kubernetes clusters >= 1.22. But not sure if that's a good idea. EDIT: Forgot that the kubeadm/kubelet/kubectl versions are kept in sync and are coupled to the OS images, so this would be a pretty bad hack. |
As per discussion at the Apr 7th CAPI office hours:
|
@CecileRobertMichon @vincepri @detiber I have investigated a possible workaround for allowing CAPI v1alpha3 to manage Kubernetes clusters >= v1.22. This is possible, but it requires dedicated PR targeting release-0.3 branch given the number of changes landed in this area for v1alpha4. As a result starting from CAPI v0.3.16, it will be possible to install v1.22 clusters (older version can't do this given the changes in kubeadm) |
I'm fine with the approach described, @CecileRobertMichon @detiber thoughts? |
@fabriziopandini awesome news, I'm a +1 for adding support to v0.3.x for k8s v1.22+ |
SGTM, looks like this will be true for v0.3.17+ though as we'll most likely release v0.3.16 earlier. |
Ok, I will start working on this and try to get this into the v0.3.x train ASAP |
/assign |
/kind release-blocking |
/milestone v0.4 |
ClusterStatus is an API structure present in kubeadm v1beta and v1beta2 that was used to track what API endpoints are available in the cluster. in 1.18 we deprecated it and implemented another method of doing the same, by applying annotations to the kube-apiserver pods. this already the default method in kubeadm, but ClusterStatus is still maintained as the second deprecated method.
the object is stored in the kubeadm-config CM.
https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2506-Remove-ClusterStatus-from-kubeadm-config
we had a discussion about this in the kubeadm office hours and @fabriziopandini mentioned that there could be impact on cluster API:
https://youtu.be/SZuK87bCfqI?t=1192
i see there there is some usage here:
https://github.com/kubernetes-sigs/cluster-api/search?q=clusterstatus
kubeadm has a plan to remove this API in v1beta3, which means Cluster API would not be able to use v1beta3 if it also uses ClusterStatus.
this issue is to migrate Cluster API to the new method of annotations and backport the change if needed.
The text was updated successfully, but these errors were encountered: