fix: honor -stderrthreshold flag with klog v2 default -logtostderr=true

[pierluigilenoci]

What this PR does

klog v2 defaults to -logtostderr=true, which silently causes the -stderrthreshold flag to be ignored. This is a long-standing issue tracked in kubernetes/klog#212.

klog v2.140.0 introduced the legacy_stderr_threshold_behavior flag to fix this behavior (kubernetes/klog#432).

Changes

1. Bump k8s.io/klog/v2 from v2.130.1 to v2.140.0
2. Set legacy_stderr_threshold_behavior=false in AddKlogFlags() (pkg/utils/global.go) so that -stderrthreshold is honored even when -logtostderr=true (the default)
3. Set stderrthreshold=INFO as the default threshold, matching the expected behavior

Why

Without this fix, operators cannot use -stderrthreshold to filter log output by severity because klog's legacy behavior unconditionally copies everything to stderr when -logtostderr is true (which it is by default).

How to test

go build ./pkg/utils/

The only klog.InitFlags call in non-vendor, non-test code is in pkg/utils/global.go, which is where the fix is applied.

Note

This PR was created with the assistance of AI tooling (Claude Code).

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: pierluigilenoci
Once this PR has been reviewed and has the lgtm label, please assign huww98 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[huww98]

How is this related to -v flag?

[pierluigilenoci]

Good question! The -v flag and -stderrthreshold are both klog flags registered by klog.InitFlags(), but they serve different purposes:

• -v controls the verbosity level (which log messages are generated)
• -stderrthreshold controls which severity levels (INFO, WARNING, ERROR, FATAL) are sent to stderr

They are related because both are part of the same klog flag set initialized in AddKlogFlags(), and an operator might reasonably set both (e.g., -v=4 -stderrthreshold=WARNING to generate verbose logs but only send warnings and errors to stderr).

The bug (kubernetes/klog#212) is that -stderrthreshold is silently ignored when -logtostderr=true (the default). This fix opts into the corrected behavior so -stderrthreshold actually works as documented. It does not change -v behavior at all — it just fixes -stderrthreshold so operators can filter which severity levels reach stderr, regardless of the verbosity level set via -v.

[pierluigilenoci]

Good question @huww98. They're orthogonal:

• -v (verbosity): Controls which log messages are generated. -v=3 means klog.V(3) messages are produced; higher levels are suppressed entirely.
• -stderrthreshold (severity threshold): Controls which severity levels are written to stderr. For example, stderrthreshold=WARNING means only WARNING and ERROR messages appear on stderr; INFO messages are suppressed from stderr output.

The bug this PR fixes: klog v2 defaults to logtostderr=true with a legacy behavior mode that silently ignores -stderrthreshold. So even if a user passes --stderrthreshold=ERROR, all log levels still appear on stderr. The fix opts out of the legacy behavior so -stderrthreshold actually works as documented.

See kubernetes/klog#432 for the upstream context.

[huww98]

OK. But I think we don't care this much.
As per https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components . Most kubernetes components only supports output to stderr now. and already deprecated stderrthreshold flag. For this project, I haven't seen anyone using log file.

WARNING severity level even not exist in the new structured logging API. We now only have ERROR and INFO severity level, making stderrthreshold not very useful.

[pierluigilenoci]

@huww98 You're right — with KEP-2845 deprecating klog-specific flags and the move to structured logging, the stderrthreshold fix doesn't add practical value here. Thanks for the explanation and for taking the time to review!

Closing this PR.