Add root-dir to kubeletExtraArgs

[gonfva]

Description

What problem are you trying to solve?

kubelet allows to pass a lot of extra parameters, using the kubeletExtraArgs. In particular there is one arg called root-dir that allows to specify the directory that kubelet uses for volumes and other stuff https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#:~:text=root%2ddir

How important is this feature to you?

Linux can probably be bypassed, but we use a special disk (ephemeral instance) for Windows and we need to point kubelet to it.

I've looked at the code and it doesn't seem hugely difficult to modify it for our personal use case. But obviously kubeletExtraArgs has a lot of possibilities ( i.e. another example #683 ) and it would be good to know what's the planned approach for this.

---

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[bwagner5]

Adding any extra kubelet args to user-data is the best approach. The current KubeletConfiguration exposed in the Provisioner maps to a subset of the KubeletConfiguration file rather than the EKS bootstrap script arguments where kubeletExtraArgs are passed. I think it would be weird to overload that config with kubelet arguments. A lot of the kubelet args have been moved to KubeletConfiguration but root-dir appears to just be an argument and not in the kubelet configuration file.

[sftim]

@gonfva if this is really important to you, I think you'll get the best outcome by adding a way to set the kubelet directory through its configuration file. Kubernetes v1.28 (due out tomorrow) is likely to add an alpha feature to support config.d drop ins, and that's a mechanism that could work well for configuring a custom kubelet directory per node.

[gonfva]

Adding any extra kubelet args to user-data is the best approach. The current KubeletConfiguration exposed in the Provisioner maps to a subset of the KubeletConfiguration file rather than the EKS bootstrap script arguments where kubeletExtraArgs are passed. I think it would be weird to overload that config with kubelet arguments. A lot of the kubelet args have been moved to KubeletConfiguration but root-dir appears to just be an argument and not in the kubelet configuration file.

Sorry, I might be missing something. I was assuming the actual joining the cluster is part of the merging semantics, and I cannot add extra variables to kubeletExtraArgs using user-data. Is there a different mechanism? Could you clarify?

[gonfva]

@gonfva if this is really important to you, I think you'll get the best outcome by adding a way to set the kubelet directory through its configuration file. Kubernetes v1.28 (due out tomorrow) is likely to add an alpha feature to support config.d drop ins, and that's a mechanism that could work well for configuring a custom kubelet directory per node.

Thank you for this. I assume it is this. I will take a look.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[jonathan-innis]

Closing this one for AWS in favor of aws/karpenter-provider-aws#5833