Change:
This is a Feature Request The says as follows When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet and set it in the file during runtime. If you are using a different CRI, you have to modify the file with your value, like so: This sounds like saving the yaml file in IS used in but it actually isn't. You need to specify the --config option when running Ref. What would you like to be Add kubeadm config and pass it to command. Example: Why is this needed To avoid confusion Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
the command reference page has this block: it links to: on the godoc page there is an example like so:
with the above documentation links / examples i have not seen any recent reports of users being confused. /priority awaiting-more-evidence /sig cluster-lifecycle
I get your point but this page should be one-stop place where you can find all the basic information enough to create a single cluster with the given condition; this case it mentions about when using different container runtime, so it should be more clear about that. My point is that even adding reference link to the config option would be better. What do you think?
proposing a minor change to the above: please send a PR for this if you can.
Created it!
Hi , on above - ok there is at least one user of that kind now, myself. See my confusion here: I was totally sure that for just adding systemd as cgroup driver (and nothing more different to the default ), tells me to print the default config into a file, add the three lines there required for , and supply it to kubeadm. As you can imagine, I was quite puzzled by the result... Fortunately, I found this page, and realised what a silly sausage I was. The initial suggestion by , with his config snippet, really helped (thanks!!) - that was exactly what I needed. Since the recommended runtime now is , and most recommended way is to use as a cgroup driver for kubelet, I think his suggestion is very right and this snippet should be mentioned right at the page that tells about how to install , and its footnote telling about . Honestly, it's really confusing without it.
hi, we have a new WIP page that will be dedicated to cgroup drivers entirely:
Agreed: I have been confused also for the last couple of hours, and searching finally led to this issue.
Issue like this should not be closed. /reopen
Reopened this issue. <detailsIn response to : Issue like this should not be closed. /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
When talking about the config-file for , we should explain this more generally - not specific to the cgroup-driver. In my case, I need to set the parameter. For about 8 hours I searched for a way to do that with . Now I found So I can implicate that this is a gerenal solution. However, the docs should mention this explicitly.
This is also very confusing for me. I could not find how to use the kubelet-configuration with kubeadm in this docs. seems to help in this case.
did you see this section for kubeadm init? both the kubeadm init and join documentation pages link to the kubeadm API from where you can pick e.g. v1beta2 and it has examples how to pass KubeletConfiguration to kubeadm init: from there users need to understand what fields the KubeletConfiguration has. the KubeletConfiguration is not managed by the kubeadm team - it's located here:
and to respond to the original issue (again) here the "installing kubeadm" guide now also has: most users understand what they need to do after clicking that link, but some would still get confused. due to the cgroup driver configuration issue this PR: adds new page explicitly for cgroup divers and after that this issue feels resolved to me. unless users have more specific requests on how to organize the docs?
yes, but that site does not tell anything about the syntax and structure for that config file. For me as an system engineer I am not able to create a config file with the information included on that site. I must admit that I have never scrolled to the end of that page. For me, it was not transparent that I have to use "Directories" to get the link to v1beta2, which will finally lead me to the information I wanted. That's why I asked for the link to itself. the KubeletConfiguration is not managed by the kubeadm team - it's located here: Here is no link to "Directories". Where do I find the syntax for the KubeletConfiguration within the yaml-config-file? I was confused because that link does not explain how to use the KubeletConfiguration with ... This was my suggestion: . Another solution would be here: Maybe someone else can check what will be helpful here. EDIT: Could we also have the 3 or 4 steps to create a configuration file instead of linking to the command, which is in fact , pipe them to a file and then run with ?
For me as an system engineer I am not able to create a config file with the information included on that site. it's an API presented to the user in a standard godoc format. structure fields map to JSON / YAML, e.g.: i'm surprised that you as a system engineer are having trouble parsing this aspect. what is the exact change you would like to see? that's actually a bug. prior to the new godoc we design it was possible to HTML anchor link to the subdirectories. i've just logged this issue it's not a directory because the KubeletConfiguration is not a kubeadm structure, it's a kubelet structure. kubeadm just allows you pass it to the kubelet, because kubeadm manages a kubelet. the kubeadm v1beta2 page links to the KubeletConfiguration, did you see this? here currently users must navigate to or directly. a number of kubeadm pages link to that already. this is a bit vague to me, still. this change seems fine to me, but i cannot approve it since it's for the kubelet pages. sure, we can keep this issue open until that happens. one problem that i have with similar requests is that users want a change, but they are not exactly sure what they want to be changed. the feedback is vague. its not "config view", but rather "config print init-defaults". including a placeholder stub seems OK to me in the lines of: but nothing more, just the link to which is already there. PRs welcome.
First, thank you for taking so much time and your questions to understand that! I also want to help with my point of view so I hope this will be transparent. First, I want to answer your points. Then, in my next comment, I'd like to describe my "jouney" through the docs on the wrong tracks... itself. I've just commented it... Ok, thanks. You see, this is the "inner" way to see it. For administrating it, it is not that easy to see why it's so complicated to find those simple things (see also my next comment) To be honest: No. But after so many hours lost in space, I did not take the time to have a look at that in detail. So this definitely was my fault. Sorry. I already knew that I have to use the config file instead of the command-line-tools. So I know this page, but do not read it for my actual problem. (see next comment: lost in space) This did not seem to be a syntax for me which can be used for my kubelet configuration. Yes, this is perfect! This is what I was looking for for 2 days :) This seems to be the biggest barrier here. Do you find one of them when searching for kubelet config :) ? I will add a new comment or maybe another issue to discuss that. Thanks. I see. Ok, I will try to help more precisely. The thing for me is to understand the way it works without having the docs I would have needed - and the give the feedback what would have been helpful. I would never have the idea that I have to do that to create the config I need to change, when I have to change the kubelet-config. Yes, this exactly should be explained on a page like and broken ;) Will you make one to fix the link to ? If not, I can do that.
For me as an system engineer I am not able to create a config file with the information included on that site. This refered to , not to the API documentation. what is the exact change you would like to see? I'll try to show you my confusing way through the docs. I hope we see wenn I got lost :) have 3 small clusters running created with kubeadm. For the provisioning I use . I know that we have to switch to a kubelet-config-file instead of the command line because of deprecation for most arguments. I am starting with zero knowledge about this config-file. am starting with . I have no idea that what I have to do has anything to do with kubadm. I read the example for the config file and know that I have to start kubelet with and this file. EDIT: Fixed with This is the first time I get lost - where I created this issue: . So you see I was on the very wrong way. confusing thing is here: For now I am still using docker, so I have no idea that this is also the solution for my case. BUT: editing is not a good idea... . I know that this is NOT the solution. Lost in space... to EDIT: hopefully better with This really does NOT sound that it could be the solution for my problem. However, if I had a full example of the config file meant here, I would have seen that it also had a -part. So I had no idea why I should print my kubeadm config and migrate it ... The link with the list is broken, we talked about that... I am still lost ... EDIT: fixed the web again I finally find and the link to this issue.... and get the idea that this could be a way for me, although changing the cgroup-Driver is not my problem... (Thanks to your comments there! and the PR of I am :)
no problem, but i don't have much time to debate this close to a kubernetes release (1.21). your feedback seems like a story in the lines of "hey, i saw a bunch of problems in your docs". if you have any suggestions just log separate issues / send PRs. EOD, every single change gets approved by the kubernetes/website maintainers and not by component maintainers like me. you can update the link in k/website. i will try to fix the general problem at
Oh, I thought you were a docs maintainer. Thanks for your help. still.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet and set it in the `/var/lib/kubelet/config.yaml` file during runtime. <del> If you are using a different CRI, you have to modify the file with your `cgroupDriver` value, like so: </del> <ins> If you are using a different CRI, you must pass your `cgroupDriver` value to `kubeadm init`, like so: </ins> ```yaml apiVersion: kubelet.config.k8s.io/v1beta1

cgroupDriver: <value> ``` <ins> For further details, please read [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). </ins> Please mind, that you **only** have to do that if the cgroup driver of your CRI is not `cgroupfs`, because that is the default value in the kubelet already.