syncer in out-of-cluster mode forces me to configure in-cluster configuration

[nip1904]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

What happened:

With version 3.3.1 the syncer forces me to configure in-cluster configuration, even if I have a valid kubeconfig.
kubeconfig is correct and syncer is using it (see log snippet)
we use out-of-cluster

Now we must configure:
KUBERNETES_SERVICE_HOST via environment
KUBERNETES_SERVICE_PORT via environment
and
/run/secrets/kubernetes.io/serviceaccount/token
/run/secrets/kubernetes.io/serviceaccount/ca.crt

all these stuff is already in kubeconfig

What you expected to happen:
syncer works without in-cluster config like all older versions

How to reproduce it (as minimally and precisely as possible):
Just run syncer out-of-cluster with kubeconfig

Anything else we need to know?:

vsphere-syncer[426263]: {"level":"info","time":"2024-09-17T07:09:03.829749944+02:00","caller":"kubernetes/kubernetes.go:105","msg":"Kubeconfig path obtained from kubeconfig flag: \"/var/lib/kubernetes/csi-provisioner.kubeconfig\"","TraceId":"3e93f222-53ff-420f-9a66-dd046e56974e"} vsphere-syncer[426263]: {"level":"info","time":"2024-09-17T07:09:03.829757245+02:00","caller":"kubernetes/kubernetes.go:122","msg":"Final Kubeconfig path used: \"/var/lib/kubernetes/csi-provisioner.kubeconfig\"","TraceId":"3e93f222-53ff-420f-9a66-dd046e56974e"} vsphere-syncer[426263]: {"level":"info","time":"2024-09-17T07:09:03.829766765+02:00","caller":"kubernetes/kubernetes.go:75","msg":"k8s client using kubeconfig from /var/lib/kubernetes/csi-provisioner.kubeconfig","TraceId":"3e93f222-53ff-420f-9a66-dd046e56974e"} vsphere-syncer[426263]: {"level":"info","time":"2024-09-17T07:09:03.830562734+02:00","caller":"kubernetes/kubernetes.go:434","msg":"Setting client QPS to 100.000000 and Burst to 100.","TraceId":"3e93f222-53ff-420f-9a66-dd046e56974e"} vsphere-syncer[426263]: {"level":"error","time":"2024-09-17T07:09:03.830893072+02:00","caller":"syncer/main.go:302","msg":"failed to get InClusterConfig: unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined","TraceId":"3e93f222-53ff-420f-9a66-dd046e56974e","stacktrace":"main.main.initSyncerComponents.func8\n\t/root/vsphere-csi-driver/cmd/syncer/main.go:302\nmain.main.func5\n\t/root/vsphere-csi-driver/cmd/syncer/main.go:213"}

Environment:

• csi-vsphere version: 3.3.1
• vsphere-cloud-controller-manager version: 1.28.1
• Kubernetes version: 1.28.14
• vSphere version:
• OS (e.g. from /etc/os-release): Oracle Linux 8.10
• Kernel (e.g. uname -a): 5.15.0-209.161.7.2.el8uek.x86_64
• Install tools:
• Others:

[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

[k8s-triage-robot]

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

This bot triages 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:

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

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

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

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.