What is PodMonitoring and node-exporter in Kubernetes?

A PodMonitoring is a custom Kubernetes resource used by Google Cloud Managed Service for Prometheus to define how metric data from application pods is scraped and ingested.What It DoesTarget Scraping: Finds specific pods within a Kubernetes namespace using label selectors and scrapes their Prometheus-formatted metrics endpoints.Flow Control: Controls how metrics stream into Cloud Monitoring, allowing you to modify scrape intervals, apply time-series filtering, reduce data rates, and use Prometheus relabeling rules.Namespace Scoping: Scrapes targets strictly within the single namespace where the resource is deployed (you must deploy copies across multiple namespaces to scrape globally, or use a ClusterPodMonitoring resource instead)

Node Exporter acts as the data producer, while a monitoring custom resource acts as the data collector.When you want to monitor hardware and OS metrics (like CPU, memory, and disk usage) of your Google Kubernetes Engine (GKE) nodes, you deploy Node Exporter. To actually pull those metrics into Google Cloud, you use a target-scraping custom resource.Because Node Exporter tracks node-level infrastructure rather than isolated application workflows, it connects to Google Cloud Managed Service for Prometheus using two main strategies:1. The Global Connection (ClusterPodMonitoring)While you can use a standard PodMonitoring resource, Google Cloud recommends using a ClusterPodMonitoring resource for Node Exporter.The Problem: Node Exporter runs as a DaemonSet across all nodes, usually isolated in a system namespace (like kube-system or gmp-system). A standard PodMonitoring resource is strictly limited to looking inside its own namespace.The Connection: A ClusterPodMonitoring resource breaks past namespace boundaries. It identifies all Node Exporter pods running across your entire cluster using label selectors (e.g., app.kubernetes.io/name: node-exporter) and scrapes their metric endpoints (typically port 9100).2. The Isolated Connection (PodMonitoring)If you specifically choose to use a standard PodMonitoring resource instead, you must deploy it directly into the exact same namespace where your Node Exporter daemonset lives. It will selectively connect to and scrape only the Node Exporter pods within that specific namespace boundary.What the Configuration Looks LikeTo bridge the gap between Node Exporter and Google Cloud, you apply a manifest that explicitly targets the exporter. Here is the official setup pattern for the Google Cloud Node Exporter integration using a cluster-wide monitoring rule:yamlapiVersion: monitoring.gke.io/v1

kind: ClusterPodMonitoring

metadata:

  name: node-exporter

spec:

  selector:

    matchLabels:

      app.kubernetes.io/name: node-exporter # 1. Finds the Node Exporter pods

  endpoints:

  - port: metrics                         # 2. Targets the exporter's metric port

    interval: 30s                         # 3. Sets how frequently to scrape hardware data

Use code with caution.The Data Pipeline FlowNode Exporter gathers raw kernel, memory, and disk utilization data directly from the host GKE node.Google Cloud's Managed Collector reads your monitoring configuration, discovers the exporter pods via the labels, and scrapes the data.The metrics are forwarded to Google's Monarch database, allowing you to view node health using PromQL in Cloud Monitoring or Grafana.Are you setting up Node Exporter to build a custom cluster dashboard, or are you troubleshooting missing node-level metrics in Cloud Monitoring?