It is generally not recommended to install the standalone Prometheus Node Exporter on OpenShift (RHCOS) nodes.

OpenShift already includes node-level monitoring as part of the platform, and adding another Node Exporter can create duplicate metrics, unnecessary resource usage, and management complexity.

What OpenShift Already Provides

OpenShift installs a complete monitoring stack:

                   OpenShift Monitoring

           Prometheus (Platform)
                    │
    ┌───────────────┼─────────────────┐
    │               │                 │
    ▼               ▼                 ▼
 kube-state    kubelet/cAdvisor   node-exporter
 metrics          metrics          (DaemonSet)

The platform monitoring stack includes:

• Prometheus
• Alertmanager
• Grafana (developer preview or external)
• Prometheus Operator
• kube-state-metrics
• kubelet metrics
• Node Exporter (managed by OpenShift)
• Telemetry components

So, Node Exporter is already deployed as a DaemonSet in the openshift-monitoring namespace.

You can verify it:

oc get daemonset -n openshift-monitoring

Example:

NAME
node-exporter

Or:

oc get pods -n openshift-monitoring | grep node-exporter

What Metrics Does It Collect?

The built-in Node Exporter collects host metrics such as:

• CPU utilization
• Memory usage
• Disk I/O
• Filesystem usage
• Network traffic
• Load average
• Context switches
• Processes
• Kernel statistics
• Filesystem inodes
• Disk latency
• NUMA information

Examples:

node_cpu_seconds_total

node_memory_MemAvailable_bytes

node_filesystem_avail_bytes

node_disk_io_time_seconds_total

node_network_receive_bytes_total

Why You Shouldn’t Install Another Node Exporter

If you deploy another Node Exporter yourself:

OpenShift
Node Exporter (built-in)
+
Custom Node Exporter

Problems include:

• Duplicate metrics (node_cpu_seconds_total, etc.)
• Metric name collisions
• Higher Prometheus cardinality
• Extra CPU and memory usage
• Additional ports to manage (typically 9100)
• Unsupported configuration drift
• More maintenance during upgrades

When Would You Install Your Own?

There are valid exceptions.

1. External Prometheus

Suppose you have:

Corporate Monitoring
Prometheus
↓
OpenShift Cluster

If the external Prometheus cannot scrape the OpenShift-managed Node Exporter due to network or security constraints, you might deploy a separate exporter specifically for that monitoring system.

2. Air-Gapped Monitoring

Some organizations maintain a completely separate monitoring platform that does not rely on OpenShift’s built-in monitoring.

3. Non-OpenShift Servers

For example:

Linux VM
Windows Server
Oracle DB Server
Load Balancer
Storage Appliance

Those systems can run standalone Node Exporter (or equivalent exporters) because they are not OpenShift nodes.

How OpenShift Collects Node Metrics

RHCOS Node
│
├── kubelet
├── CRI-O
├── node-exporter
└── cAdvisor
↓
Prometheus
↓
Alertmanager
↓
Grafana

Node Exporter complements kubelet and cAdvisor:

Can You Customize Node Exporter?

Not by editing the DaemonSet directly.

In OpenShift, monitoring components are managed by the Cluster Monitoring Operator (CMO). Direct modifications are overwritten.

Supported customization is done through the cluster monitoring configuration, for example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config

Enterprise Best Practice

For production OpenShift clusters:

Use OpenShift Monitoring
↓
Use built-in Node Exporter
↓
Do NOT deploy another Node Exporter

For the rest of your infrastructure:

Linux Servers
↓
Node Exporter
↓
Prometheus

A common enterprise architecture looks like this:

                    Enterprise Monitoring

                   Grafana
                      │
               Thanos / Prometheus
                      │
      ┌───────────────┴────────────────┐
      │                                │
      ▼                                ▼
OpenShift Monitoring           Linux VMs
(Node Exporter built-in)       (Node Exporter installed)

Interview Answer

I would not install a standalone Node Exporter on OpenShift worker or control-plane nodes because OpenShift already deploys and manages Node Exporter as part of the Cluster Monitoring Operator. The built-in exporter collects host metrics such as CPU, memory, filesystem, disk I/O, and network statistics, which are scraped by the platform Prometheus. Installing a second Node Exporter would create duplicate metrics, increase cardinality, and complicate supportability. If I need to monitor external Linux servers, I install Node Exporter there. For OpenShift itself, I rely on the Red Hat-managed monitoring stack and customize it only through supported configuration mechanisms.

This is the approach recommended for production OpenShift environments and is what most enterprise customers follow.