-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
Feat: kubeadm v1beta4 support #11674
Feat: kubeadm v1beta4 support #11674
Conversation
Skipping CI for Draft Pull Request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments/suggestions.
roles/kubernetes/control-plane/templates/kubeadm-controlplane.v1beta4.yaml.j2
Outdated
Show resolved
Hide resolved
roles/kubernetes/kubeadm/templates/kubeadm-client.conf.v1beta4.j2
Outdated
Show resolved
Hide resolved
If kube_version is v1.31 or higher, it will be v1beta4, otherwise it will be v1beta3. Signed-off-by: ChengHao Yang <[email protected]>
d12a89c
to
9188cf6
Compare
/label tide/merge-method-merge |
/retest |
1 similar comment
/retest |
9188cf6
to
9682baf
Compare
v1beta4 has changed a lot in this file (e.g. ExtraArgs etc.), so it was implemented in separate files. Signed-off-by: ChengHao Yang <[email protected]>
I added the kubeadm_config_api_version variable in the previous commit, and remove kubeadm api version condition. Signed-off-by: ChengHao Yang <[email protected]>
Remove kubeadm api version condition. Currently there is not much difference between the files, if there are more changes in the future, please use different files to distinguish them (you can use the kubeadm_config_api_version variable) Signed-off-by: ChengHao Yang <[email protected]>
Currently there is not much difference between the files, if there are more changes in the future, please use different files to distinguish them (you can use the kubeadm_config_api_version variable) Signed-off-by: ChengHao Yang <[email protected]>
Currently there is not much difference between the files, if there are more changes in the future, please use different files to distinguish them (you can use the kubeadm_config_api_version variable) Signed-off-by: ChengHao Yang <[email protected]>
9682baf
to
bf01b73
Compare
Looking at that diff makes me think we should definitely not template it this way but juste mostly mirror the data struct and feed it to /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tico88612, VannTen The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Adds revised support for: - The previously removed `--config` argument for `kubeadm upgrade apply` - Changes to `ClusterConfiguration` as part of the `upgrade-cluster.yml` playbook lifecycle (Fixes kubernetes-sigs#11552) - kubeadm-config `v1beta4` `UpgradeConfiguration` for the `kubeadm upgrade apply` command: [UpgradeConfiguration v1beta4](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta4/#kubeadm-k8s-io-v1beta4-UpgradeConfiguration). Background: PR kubernetes-sigs#11352 removed the --config flag from `kubeadm upgrade apply` to address the upgrade issues with kubeadm v1.30 identified in kubernetes-sigs#11350. Before this change, kubespray upgrades depended on `kubeadm upgrade apply --config=...` to make ClusterConfiguration changes with the upgrade. However, this reconfiguration was deprecated in `kubeadm upgrade apply` some time ago, and is no longer supported by the `kubeadm upgrade apply` config command. To ensure `ClusterConfiguration` changes are still applied during upgrades in a supportable way, the new solution in this PR reconfigures ClusterConfiguration separately after upgrade with distinct upload-config and control plane static pod rewrite tasks that run immediately after a successful upgrade. See [this comment from @VannTen](kubernetes-sigs#11871 (comment)) for more discussion on why the expectation is to fix reconfiguration as part of the upgrade lifecycle, as well as issue kubernetes-sigs#11552. Additionally, kubeadm v1.31 added back support for `--config`, along with UpgradeConfiguration when using v1beta4. This PR adds support for the `UpgradeConfiguration` in the kubeadm-config file, which is required to fully implement upgrades with `kubeadm.k8s.io/v1beta4`. This addition was omitted from the original v1beta4 implementation in kubernetes-sigs#11674, but it is required to use `--config` correctly during kubeadm upgrades with v1beta4.
Adds revised support for: - The previously removed `--config` argument for `kubeadm upgrade apply` - Changes to `ClusterConfiguration` as part of the `upgrade-cluster.yml` playbook lifecycle (Fixes kubernetes-sigs#11552) - kubeadm-config `v1beta4` `UpgradeConfiguration` for the `kubeadm upgrade apply` command: [UpgradeConfiguration v1beta4](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta4/#kubeadm-k8s-io-v1beta4-UpgradeConfiguration). kubeadm upgrade apply --config support PR kubernetes-sigs#11352 removed the --config flag from all usages of `kubeadm upgrade apply` to address the upgrade issues with kubeadm v1.30 identified in kubernetes-sigs#11350. This PR enables support for the scenarios in which `--config` can and should still be used with `kubeadm upgrade apply`, with some version specific handling that still avoid kubeadm v1.30's upgrade failures. Control plane reconfiguration during upgrade Before PR kubernetes-sigs#11352, kubespray upgrades depended on `kubeadm upgrade apply --config=...` to make ClusterConfiguration changes during a cluster upgrade. However, this reconfiguration was deprecated from `kubeadm upgrade apply` some time ago, and is [no longer supported](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/#additional-information) by the `kubeadm upgrade apply` command. To ensure `ClusterConfiguration` changes are still applied during upgrades in a supportable way, the new solution in this PR reconfigures `ClusterConfiguration` separately with distinct `kubeadm init phase upload-config kubeadm --config=...` and control plane static pod rewrite tasks that run immediately after a successful upgrade. See [this comment from @VannTen](kubernetes-sigs#11871 (comment)) for more discussion on why the expectation is to fix reconfiguration as part of the upgrade lifecycle, as well as issue kubernetes-sigs#11552. This approach is in line with kubeadm's [recommendations for cluster reconfiguration](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/). kubeadm-config v1beta4 `UpgradeApplyConfiguration` support Additionally, kubeadm v1.31 added back support for `--config` while introducing support for `UpgradeConfiguration` in the kubeadm-config file, which is required to fully implement upgrades with `kubeadm.k8s.io/v1beta4`. UpgradeConfiguration was not added in kubespray's initial v1beta4 implementation (PR kubernetes-sigs#11674), but it is required to use `--config` correctly during kubeadm upgrades with v1beta4. This PR uses UpgradeConfiguration for v1beta4 kubeadm upgrades, while still retaining support for v1beta3.
Adds revised support for: - The previously removed `--config` argument for `kubeadm upgrade apply` - Changes to `ClusterConfiguration` as part of the `upgrade-cluster.yml` playbook lifecycle - kubeadm-config `v1beta4` `UpgradeConfiguration` for the `kubeadm upgrade apply` command: [UpgradeConfiguration v1beta4](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta4/#kubeadm-k8s-io-v1beta4-UpgradeConfiguration). kubeadm upgrade apply --config support PR kubernetes-sigs#11352 removed the --config flag from all usages of `kubeadm upgrade apply` to address the upgrade issues with kubeadm v1.30 identified in kubernetes-sigs#11350. This PR enables support for the scenarios in which `--config` can and should still be used with `kubeadm upgrade apply`, with some version specific handling that still avoid kubeadm v1.30's upgrade failures. Control plane reconfiguration during upgrade Before PR kubernetes-sigs#11352, kubespray upgrades depended on `kubeadm upgrade apply --config=...` to make ClusterConfiguration changes during a cluster upgrade. However, this reconfiguration was deprecated from `kubeadm upgrade apply` some time ago, and is [no longer supported](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/#additional-information) by the `kubeadm upgrade apply` command. To ensure `ClusterConfiguration` changes are still applied during upgrades in a supportable way, the new solution in this PR reconfigures `ClusterConfiguration` separately with distinct `kubeadm init phase upload-config kubeadm --config=...` and control plane static pod rewrite tasks that run immediately after a successful upgrade. See [this comment from @VannTen](kubernetes-sigs#11871 (comment)) for more discussion on why the expectation is to fix reconfiguration as part of the upgrade lifecycle, as well as issue kubernetes-sigs#11552. This approach is in line with kubeadm's [recommendations for cluster reconfiguration](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/). kubeadm-config v1beta4 `UpgradeApplyConfiguration` support Additionally, kubeadm v1.31 added back support for `--config` while introducing support for `UpgradeConfiguration` in the kubeadm-config file, which is required to fully implement upgrades with `kubeadm.k8s.io/v1beta4`. UpgradeConfiguration was not added in kubespray's initial v1beta4 implementation (PR kubernetes-sigs#11674), but it is required to use `--config` correctly during kubeadm upgrades with v1beta4. This PR uses UpgradeConfiguration for v1beta4 kubeadm upgrades, while still retaining support for v1beta3.
What type of PR is this?
/kind feature
What this PR does / why we need it:
Starting from Kubernetes v1.31, kubeadm v1beta4 is supported, and all subsequent versions use v1beta4 for deploying clusters.
Which issue(s) this PR fixes:
Fixes #10935
Special notes for your reviewer:
This is currently a draft PR, and the changes may conflict with #11633, so #11633 needs to be reviewed first.
Does this PR introduce a user-facing change?: