-
Notifications
You must be signed in to change notification settings - Fork 716
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
Implement support for Kubelet Dynamic Configuration #28
Comments
From @luxas on October 5, 2016 19:28 cc @kubernetes/sig-cluster-lifecycle |
From @errordeveloper on October 5, 2016 20:25 Is this feature already usable? |
From @luxas on October 5, 2016 20:29 I don't know actually, but I think an alpha version of it exists |
From @axsuul on October 7, 2016 6:58 Is this related to customizing arguments for the kubernetes API server? I'm trying to customize the secure port it listens on ( |
From @errordeveloper on October 7, 2016 7:15 James, no this is not related. To your question, please try editing On Fri, 7 Oct 2016, 08:59 James Hu, [email protected] wrote:
|
From @axsuul on October 7, 2016 7:58 @errordeveloper Thanks, I've opened up issue #34307 with more questions |
From @mtaufen on October 7, 2016 17:3 There is an alpha version of the dynamic settings feature, but it still needs a lot of work. I'm going to be mostly focused on GCI-related things for v1.5, but am planning be giving it high-priority focus for v1.6. I wouldn't recommend building on top of dynamic settings just yet, as it will undergo some significant changes (e.g. we will move to telling a node which configmap to use via annotations rather than creating configmaps with a per-node naming convention). As it stands you would have to create a configmap for every node in the cluster anyway, and based on @luxas's first comment in this issue, it looks like you are trying to avoid per-node work, so that might be another reason to wait. Granted, this per-node work is still probably less effort than modifying systemd conf across a cluster... |
We are blocked on this one from other persons/sigs: kubernetes/kubernetes#27980 |
This might be possible for v1.8. |
@mtaufen Will the alpha version of Kubelet Dynamic Configuration be easily upgradeable? kubeadm could be a good way to test these things out on real clusters during the cycle and then we can decide whether we want to enable it or not in v1.8 |
It depends on how confident we are that the API types for the Kubelet won't change after 1.8. It's too early to say right now. |
…config Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Add kubeadm support for Kubelet Dynamic Configuration **What this PR does / why we need it**: This PR will make kubeadm support for Kubelet Dynamic Configuration. This is still WIP (and the code seems ugly). Creating the PR for now to let reviewers see if I understand the feature correctly and am on the right path and what else I'm missing. **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes kubernetes/kubeadm#28 **Special notes for your reviewer**: This feature is targeting for 1.9 as alpha. /cc @luxas @mtaufen @mikedanese **Release note**: ```release-note Kubeadm now supports for Kubelet Dynamic Configuration. ```
We have some things to fix up yet:
|
Automatic merge from submit-queue (batch tested with PRs 56008, 56013). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. KubeletConfiguration.BaseConfig.ClusterDNS defaults to the tenth address of MasterConfiguration.Networking.ServiceSubnet **What this PR does / why we need it**: If can get DNS IP from MasterConfiguration.Networking.ServiceSubnet, defaults to it. Otherwise defaults to DefaultClusterDNSIP **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: ref: kubernetes/kubeadm#28 (comment) **Special notes for your reviewer**: /cc @luxas **Release note**: ```release-note NONE ```
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Re-engineer the kubeadm join logic. **What this PR does / why we need it**: - wait for the kubelet to create `/etc/kubernetes/kubelet.conf` - use those credentials to PATCH the node **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: ref: kubernetes/kubeadm#28 (comment) **Special notes for your reviewer**: /cc @kubernetes/sig-cluster-lifecycle-pr-reviews **Release note**: ```release-note NONE ```
FYI |
Yeah, we'll accommodate accordingly when we move out of alpha with this on the kubeadm side. |
FYI @timothysc ^ |
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Write marshalled kubeletconfig object to init-config-dir **What this PR does / why we need it**: from @luxas : >Write the the marshalled kubeletconfig object to /var/lib/kubelet/config/init/kubelet so that the kubelet will start up with the right params on init/join. The only params expected in the kubelet command-line after this is kubelet --init-config-dir /var/lib/kubelet/config/init --dynamic-config-dir /var/lib/kubelet/config/dynamic **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: ref: kubernetes/kubeadm#28 (comment) **Special notes for your reviewer**: /cc @kubernetes/sig-cluster-lifecycle-pr-reviews **Release note**: ```release-note NONE ```
…te-kc Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Add validation of kubelet and kube-proxy configuration in kubeadm. **What this PR does / why we need it**: kubeadm has implemented the support for Kubelet Dynamic Configuration. This PR adds validation on the kubelet configuration. kube-proxy validation also added in this PR. **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: ref: kubernetes/kubeadm#28 **Special notes for your reviewer**: /cc @luxas @kubernetes/sig-cluster-lifecycle-pr-reviews **Release note**: ```release-note NONE ```
I think all the tasks needed to be performed were merged last week, so closing this as fixed for an alpha state now. The design of this feature is covered in design doc update of v1.9 #573. We'll open new issues later for graduating this feature to beta on the kubeadm side. Thanks @xiangpengzhao for the awesome work on this 🎉! |
Is #83 supposed to work for v1.11? Because I still need to set
in
Without setting |
@bronger but assuming you have transitioned to the kubeadm config
this will help you to not have to update the ref: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/ |
@bronger check the |
@luxas No, it says
|
@bronger please open a new issue with all the required information to debug that. Might be a bug. |
@bronger have you reported one? could you refer to it please, I can confirm on a latest stable kubeadm |
I think #83 perfectly fits, the new one would be identical |
From @luxas on October 5, 2016 19:26
We should use Kubelet Dynamic Settings by pushing values given to
kubeadm init
to the apiserver when started, and that will make all kubelets in the cluster reload and pick up those configuration values.That's much better than having to modify every
10-kubeadm.conf
systemd dropin file in the whole cluster.Copied from original issue: kubernetes/kubernetes#34132
The text was updated successfully, but these errors were encountered: