Description of problem:

In the current implementation, WMCO creates a windows-exporter serviceMonitor and exposes the endpoints for Windows nodes. However, based on recent changes in the design, there is an existing kubelet endpoint in the kube-system namespace which already contains all node IP addresses. This would mean WMCO should instead rely on this endpoint for scraping metrics, and not create a new one.

Version-Release number of selected component (if applicable):

    10.17.0

How reproducible:

    100%

Steps to Reproduce:

1. Ensure WMCO is running and Windows nodes are bootstrapped.
2. Check the servicemonitor and confirm it’s using the windows-exporter endpoint.
3. Restart the WMCO operator by deleting the pod.
4. Observe that the windows-exporter serviceMonitor still attempts to expose individual node endpoints.
5. Verify that the kubelet endpoint in the kube-system namespace contains all node IPs.

Actual results:

    Currently, WMCO creates a new serviceMonitor for windows-exporter and exposes individual node endpoints.

Expected results:

    WMCO should be modified to use the existing kubelet endpoint in the kube-system namespace instead of creating a new windows-exporter serviceMonitor.

Additional info:

• This behavior appears to conflict with the recent design change (as of 10.18).
• The existing kubelet endpoint is sufficient for scraping the metrics and eliminates the need for a new serviceMonitor.