-
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
📖 Add documentation around KubeadmControlPlane #2607
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chuckha 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 |
@@ -0,0 +1,28 @@ | |||
# Kubeadm control plane |
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.
This doc currently seems to be more around just the upgrade process. I'm wondering if it might be better to title it 'Upgrading workload clusters' and have a short blurb that the use of KubeadmControlPlane and MachineDeployment is a requirement for supported upgrades.
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.
The intent is that this is a place to put tasks related to kubeadm control plane. Upgrades just happen to be the most interesting feature. There should probably be some sentences about scaling up and down, fixing a busted control plane node and other tasks that kubeadm control plane allows us to do
|
||
To upgrade the Kubernetes control plane version, which will likely, depending on the provider, also upgrade the | ||
underlying machine image, make a modification to the `KubeadmControlPlane` resource's `Version` field. This will trigger | ||
a rolling upgrade of the control plane. |
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.
Might be good to add a statement along the lines of:
If the infrastructure provider used requires updating image IDs to update the Kubernetes version, the update for the MachineTemplate must be done at the same time as updating the KubeadmControlPlane.Spec.Version field to the appropriate version for the image. This is to ensure that the deployed control plane pods and additional upgrade steps, such as updating the kube-proxy daemonset for the workload cluster, will use the correct matching Kubernetes version as the on-disk binaries provided by the image.
Might be good to add a similar blurb related to image based overrides for the provided KubeadmConfig, but both of these can easily be done later and shouldn't necessarily be blocking for this PR.
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.
I added a paragraph around the infrastructure provider changes but not a section for the KubeadmConfig.
Let's add that along with how to upgrade etcd and add ons maybe after we get this in place?
/milestone v0.3.x |
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.
@chuckha thanks!
I was expecting something about etcd/core DNS upgrades as well, but I'm not in sync with the status of those changes...
@detiber @fabriziopandini Thank you so much for the feedback! I have updated the document incorporating your suggestions. Please take a look! |
Signed-off-by: Chuck Ha <[email protected]>
/lgtm |
Signed-off-by: Chuck Ha [email protected]
What this PR does / why we need it:
This PR adds basic upgrade instructions for kubeadm control plane resource.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Related to #2244
I'm opening this initially to give us a place to add more documentation as we need it. It doesn't quite close #2244 but it gets us closer.
/assign @detiber @randomvariable