Stale information in page “Control CPU Management Policies on the Node”

[zackaria-12]

Dear Kubernetes,

Based on the prototyping, I have discovered that there are some aspects that do not correspond to the documentation I followed and are not fully described. I would like to share this experience with you, and I believe that addressing these points will improve the documentation as a whole.

Regarding my assignment, I have been working on prototyping a requirement that was quite challenging to implement CPU-control based on the documentation, which also took a lot of time. Here are the points that i would like to share:

• The use of Kubernetes flags mentioned in the documentation as arguments is not supported, as the current version does not support this approach.

• When configuring the CPU manager in the Kubelet configuration file, it is important to set the values for "systemReserved" and "kubeReserved". When configuring the CPU manager in the Kubelet configuration file, However, this is not mentioned in the documentation, despite the fact that the proper functioning of the kubelet service depends on it.

• In addition, it may be helpful to indicate where the kubelet configuration file can be found. In Ubuntu, this file is located at /var/lib/kubelet/config.yaml.

[utkarsh-singh1]

Related Doc - https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/

/sig docs /language en

[sftim]

/retitle Stale information in page “Control CPU Management Policies on the Node” /kind bug

/triage accepted /sig node /priority backlog

[mmiranda96]

/triage accepted /remove-kind bug /kind documentation

[mmiranda96]

/help /good-first-issue

[zackaria-12]

I can see that the documentation has been updated :)

[mrgiles]

@zackaria-12, I see the updates on the page but I also see in the Configuration section that it shows these options being passed as either command-line flags or config file options.

But in the kubelet ref docs docs, I see that all these command line flags have been deprecated.

(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag.

So the doc still appears to be outdated in that respect. What do you think?

FYI @sftim

[tengqm]

There are still some configuration options that can only be specified with command line flags. There are some new settings that can only be configured in the kubelet config file. Those warnings can be safely ignored at the moment. But if you are cautious about this, feel free to raise a question on the #sig-node slack channel.

[mrgiles]

Thanks @tengqm. What about adding a link to the ref doc which lists all the available options (command line flags and config file options) and includes the deprecation notices, so that the user can see which are the valid options, all in one place?

[tengqm]

@mrgiles The command line options were parsed from the source code, then the kubelet command implementation was heavily revised, we were no longer able to peek into the command line arguments. Since then, we have been maintaining the kubelet reference manually, by cross-checking the output from kubelet --help.

The config file options is generated from the upstream source code as well. There are options not covered by the command line options, e.g.

    configMapAndSecretChangeDetectionStrategy
    enableSystemLogHandler
    enableSystemLogQuery
    enableDebugFlagsHandler
    enableProfilingHandler
    maxParallelImagePulls (nil)
    memorySwap
    memoryThrottlingFactor
    nodeStatusReportFrequency
    nodeLeaseDurationSeconds (40)
    showHiddenMetricsForVersion
    shutdownGracePeriod
    tracing

It is a design and implementation issue, not a documentation problem we can fix.

[ghost]

Hey @zackaria-12 . I am completely new to open source and looking forward to make my fist open source contribution. Can you please say more about this issue and what i have to solve because i am unable to understand

[sftim]

Hi @aritraxchatterjee

You mentioned that you are completely new to open source. Well done for specifically looking for issues with the good-first-issue label. I actually am not sure this is was ever a good first issue. I will remove the label that made you think it was. /remove-good-first-issue /remove-help

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted