✨ Add JSON log format and deprecate klog flags

[sbueringer]

What this PR does / why we need it:
This PR starts using components-base/logs. Through that we get the following changes:

• some klog flags are deprecated (like in core Kubernetes components: https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components#removed-klog-flags)
  • k/k is planning to drop them in their components in 1.26
  • Note: those flags are not deprecated in klog, only in Kubernetes through component-base/logs (more details in the KEP)
• there are new flags to enable JSON logging, e.g. --logging-format (default: text, can also be set to JSON)
  • JSON logging is currently alpha: https://kubernetes.io/docs/concepts/cluster-administration/system-logs/#json-log-format
  • Additional JSON flags can be seen here: https://github.com/kubernetes/component-base/blob/master/logs/config.go#L78-L79
• this also adds the --experimental-logging-sanitization flag which enables the klog SanitizingFilter. This sanitizes logging of types like crypto/x509.Certificate automatically

I think it makes sense to deprecate the klog flags in ClusterAPI too as the same reasons managed in the KEP also apply to us. I also think it makes sense to use component-base/logs as we get JSON logging for free, without having to implement it ourselves. Downside is that we depend on upstream k/component-base, but I think this should be fine.

Note: This PR does not enable JSON logging per default, which makes sense given that it's currently alpha upstream.

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 #5571
Related #6069
Related #3889

Some links:
* doc: klog
* doc: JSON log format
* KEP-1602: Structured Logging
* KEP-2845: Deprecate klog specific flags in Kubernetes Components

[sbueringer]

@dims Do you think it makes sense to use component-base/logs in CAPI instead of using the klog flags directly?

The main reasons for it in my opinion are to profit from upstream Kubernetes developments:

• decoupling & deprecation from klog flags
• JSON logging implementation

Not sure if it's problematic to depend on component-base/logs.

[enxebre]

+1, this seems a step in good direction towards converging with kube ecosystem common pattern.

[sbueringer]

/test pull-cluster-api-e2e-informing-ipv6-main
(just need feedback if this job works with main, we have at least issues on release-1.1)

[sbueringer]

+1, this seems a step in good direction towards converging with kube ecosystem common pattern.

I agree.

Just fyi, I moved further discussion to the issue (#5571 (comment)) and tried to summarize there what it would mean to adopt component-base/logs.

[vincepri]

Should we mark this as a breaking change?

[sbueringer]

Should we mark this as a breaking change?

I think there are no breaking changes in this PR. From a user perspective:

• There is an additional logging-format flag (and a few more, details in the issue))
• The default logging-format is still text
• The klog flags will be deprecated, but they are still there (k/k plans to drop them with v1.26)
  • fyi, they are added in logs.AddFlags(fs, logs.SkipLoggingConfigurationFlags())

I think what we should definitely do, if we decide to go ahead with this change, is document this as a recommendation (?) for providers in the v1.1=>v1.2 migration guide

[vincepri]

fyi, they are added in logs.AddFlags(fs, logs.SkipLoggingConfigurationFlags())

Got it, this was missed as it wasn't clear that this new line adds the same flags

[sbueringer]

/test pull-cluster-api-e2e-informing-ipv6-main

[fabriziopandini]

I'm definitely +1 to keep up with Kubernetes' new KEPs in this area.
/lgtm

Giving a little bit of time for people to review new dependency, but if no one raises concerns I'm going to get this merged sometimes next week

[killianmuldoon]

/lgtm

[sbueringer]

Just rebased onto current main to pull in latest changes on main.

[vincepri]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vincepri

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vincepri]

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