Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
kubeadm: Write kubelet config file to disk and persist in-cluster #63887
What this PR does / why we need it:
The kubelet dropin file I used now looks like this:
Which issue(s) this PR fixes (optional, in
Special notes for your reviewer:
changed the title
kubeadm: Write kubelet config file to disk and persist in-cluster
May 15, 2018
The addition of an environment file is great here, but if we go forward with this it would probably be a good idea to stick with standard env file paths for the OSs we ship packages for. I know for CentOS/Fedora this would be
An aside while I'm on the topic of systemd unit configuration managed by the packaging, we really shouldn't be placing packaged managed unit files and drop-in files in
I'm still concerned with how we handle this transition during upgrades, since there is a bit of chicken/egg involved between the package managed dropin and the configuration done by kubeadm upgrade. If we force the update with the package upgrade of kubeadm, then we risk breaking the running kubelet prior to install. However, we could transition the ownership of the drop-in file to kubeadm, which would allow for kubeadm itself to mutate the drop-in, perform a
Agree that we should follow the distribution standards for placement for environment files and using
There's a potential issue at present in that the docs ask people to modify
Moving management of that particular config to something kubeadm controls so that the drop-ins are truly static makes more sense.
referenced this pull request
May 16, 2018
the already modified kubelet config by the user (e.g. cgroup driver updated) is a problem. i think the documentation and the suggested workflow for the kubelet would have been to never modify the kublet config but handle extra arguments from the environment only. if the same location is written to, a backup of the user config should be created - e.g.
do you have something in mind on how the mutator would work? if the user has modified his kubelet config a lot, doing a
One option that we have is to have the upgrade scripts in packaging preserve the existing file and create the new version of the file under /usr/lib/systemd and require the user to reconcile the differences. This is a more manual step, but would get us to the place that we want to be... We could also tell users that if they haven't modified the file that it is safe to just blow it away.
As for documentation on how to modify the unit config, we could tell users to just use
going back to this:
this is so true.
i think the files should be placed in the same folder and for the old one a suffix should be appended, like
this seems like a good solution.
so in terms of the docs and
This was referenced
May 16, 2018
I do agree that it is confusing, but it would ensure that the existing drop-in would override the package provided one... We could always attempt to do a diff against the known previous version and only leave the diff as a drop-in under /etc/systemd/system/kubelet.service.d. We could also provide a preflight check to force the user to take some action prior to upgrade as well.
I think anything we do for the transition is going to be awkward, but as long as we provide sufficient documentation and tooling to assist the user through the transition then we can limit the impact.
2 times, most recently
May 17, 2018
2 similar comments
[APPROVALNOTIFIER] This PR is APPROVED
Approval requirements bypassed by manually added approval.
The full list of commands accepted by this bot can be found here.
The pull request process is described here