Provide an option in the clusterctl library to suppress API server warnings

[dlipovetsky]

What would you like to be added (User Story)?

As an developer, I want to suppress API server warnings when I use the clusterctl library.

Detailed Description

As an developer, I want to suppress API server warnings when I use the clusterctl library.

More precisely, I want to suppress warnings when I create the clusterctl client here:

cluster-api/cmd/clusterctl/client/cluster/client.go

Lines 187 to 189 in 85d2880

	func New(kubeconfig Kubeconfig, configClient config.Client, options ...Option) Client {
	return newClusterClient(kubeconfig, configClient, options...)
	}

So that, whenever clusterctl creates a "proxy" client, that client is configured to suppress API server warnings.

Clusterctl creates Kubernetes clients in at least 3 places, and it probably makes sense to suppress warnings in all of them.

1. cluster-api/cmd/clusterctl/client/cluster/proxy.go

   Line 170 in d6afeb8

   c, err = client.New(config, client.Options{Scheme: localScheme})

2. cluster-api/cmd/clusterctl/client/cluster/proxy.go

   Line 195 in d6afeb8

   _, err := client.New(config, client.Options{Scheme: localScheme})

3. cluster-api/cmd/clusterctl/client/cluster/proxy.go

   Line 407 in d6afeb8

   cs, err = kubernetes.NewForConfig(config)

Anything else you would like to add?

Warnings can appear due to factors outside of my users' control. For example, as of Kubernetes v1.29.0 and newer, users begin seeing new warnings related to finalizer names during every "move" operation. Those warnings will continue to appear until all projects in the Cluster API have finalizers that conform to requirements (see #10914).

clusterctl move output with warnings

> ./clusterctl move --kubeconfig=src.kubecconfig --to-kubeconfig=dst.kubeconfig
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Moving Cluster API objects ClusterClasses=1
Waiting for all resources to be ready to move
Creating objects in the target cluster
[KubeAPIWarningLogger] metadata.finalizers: "addons.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "addons.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "addons.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "addons.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "cluster.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "dockercluster.infrastructure.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "kubeadm.controlplane.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflictswith other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "machine.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "machine.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "dockermachine.infrastructure.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
[KubeAPIWarningLogger] metadata.finalizers: "dockermachine.infrastructure.cluster.x-k8s.io": prefer a domain-qualified finalizer name to avoid accidental conflicts with other finalizer writers
Deleting objects from the source cluster 

As a developer, if I choose to suppress warnings, I take responsibility for acknowledging, and addressing them, as needed.

We may also consider providing this option in the clusterctl CLI, but I think that's a separate topic.

Label(s) to be applied

/kind feature

[dlipovetsky]

/area clusterctl

[dlipovetsky]

Some implementation notes for later:

We instantiate the default Proxy implementation in

cluster-api/cmd/clusterctl/client/cluster/client.go

Line 203 in 85d2880

client.proxy = newProxy(client.kubeconfig)

We have a chance to pass some options at this time.

However, we also instantiate the default Proxy implementation in

cluster-api/cmd/clusterctl/client/cluster/ownergraph.go

Line 71 in 99866da

p := newProxy(Kubeconfig{Path: kubeconfigPath, Context: ""})

And we don't currently pass accept options here. We don't even use the InjectProxy pattern we established in the client package.

[sbueringer]

I didn't look into implementation details, but agree with the goal

/triage accepted

[sbueringer]

@dlipovetsky You saw this only during clusterctl move until now?

[sbueringer]

Okay also saw it in controller logs. Not sure if I like it :)

[sbueringer]

@dlipovetsky Do you know if there are any discussions about rolling back this warning?

It will be very very nosiy everywhere and almost everyone won't be able to just change the name of the finalizer (i.e. they can't do anything about it, for years usually, I think)

[dlipovetsky]

@dlipovetsky Do you know if there are any discussions about rolling back this warning?

That's a great question. I'll look around and report back.

Started a thread: https://kubernetes.slack.com/archives/C0EG7JC6T/p1721923881095799

[sbueringer]

@dlipovetsky Will definitely review your PR in controller-runtime tomorrow, so that we get the ability to suppress warnings ASAP

[dlipovetsky]

It turned out that controller-runtime, when configured to suppress warnings, was not doing so. That's now fixed, and should be in the next controller-runtime release.