企业官网建设流程全解析

Laf 集群监控基石：prometheus-node-exporter Helm Chart 完整部署与配置指南

【免费下载链接】lafLaf is a vibrant cloud development platform that provides essential tools like cloud functions, databases, and storage solutions. It enables developers to quickly unleash their creativity and bring innovative ideas to life with ease.项目地址: https://gitcode.com/GitHub_Trending/la/laf

导读

本文以 Laf 开源云开发平台仓库内build/charts/kube-prometheus-stack图表集所依赖的prometheus-node-exporterHelm Chart 为主体，系统讲解如何在 Kubernetes 集群上通过 Helm 部署 node-exporter、配置其采集行为、启用 kube-rbac-proxy 端点保护以及对接 ServiceMonitor / PodMonitor 实现节点级硬件与操作系统指标采集。读完本文，你将掌握该 Chart（v4.21.0，node-exporter v1.6.0）的安装、升级、核心 values 调优与底层 DaemonSet 实现原理，并能在自有监控栈中直接复用以完成集群节点可观测性建设。

一、图表定位：它在 Laf 项目与监控体系中的角色

prometheus-node-exporter是 Prometheus 官方生态中的核心组件，其职责是采集 *NIX 内核暴露的硬件与操作系统指标（CPU、内存、磁盘、网络、文件系统等），并以 HTTP/metrics端点对外提供 Prometheus 文本格式的数据。项目自身采用 Go 语言编写，指标采集器（collector）采用可插拔设计，可按需启用或禁用。

在本仓库中，该图表以依赖子图的形式被 Vendored 在监控基础设施目录下：

• 图表主体：build/charts/kube-prometheus-stack/charts/prometheus-node-exporter/README.md
• 图表元数据：build/charts/kube-prometheus-stack/charts/prometheus-node-exporter/Chart.yaml（name: prometheus-node-exporter，version: 4.21.0，appVersion: 1.6.0，type: application，Apache-2.0 许可）

从 Chart.yaml 可知，当前默认对应的 node-exporter 二进制版本为1.6.0，默认镜像为quay.io/prometheus/node-exporter，tag 缺省时取v{{ .Chart.AppVersion }}（即v1.6.0，见 _helpers.tpl 中prometheus-node-exporter.image的定义）。

作为 DaemonSet 形态的采集器，它会在每个节点上运行一个 Pod，配合hostNetwork、hostPID以及宿主机/proc、/sys、根文件系统挂载，直接读取节点级指标。这也是 Kubernetes 集群“节点可观测性”最标准、最轻量的方案。

二、快速上手：仓库信息、安装、卸载与升级

2.1 添加 Helm 仓库并更新索引

在具备 Helm 的环境下，先添加官方社区仓库并刷新索引：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update

2.2 安装 Chart

helm install [RELEASE_NAME] prometheus-community/prometheus-node-exporter

安装后将得到一个以[RELEASE_NAME]命名的 Release，并默认创建 DaemonSet、Service、ServiceAccount 等 Kubernetes 资源（具体资源清单见下文源码剖析）。

2.3 卸载 Chart

helm uninstall [RELEASE_NAME]

该命令会移除与此 Chart 关联的所有 Kubernetes 组件并删除整个 Release。

2.4 升级 Chart

helm upgrade [RELEASE_NAME] [CHART] --install

--install表示如果 Release 尚不存在则直接执行安装，适合在 CI/CD 中幂等执行。

2.5 查看全部可配置项

helm show values prometheus-community/prometheus-node-exporter

本地开发时，可直接阅读仓库内带详细注释的默认值文件 values.yaml。

三、升级注意事项（跨大版本必读）

3.1 4.16 升级到 4.17+

从 4.17 开始，containerSecurityContext.readOnlyRootFilesystem默认值被设置为true（见 values.yaml 第 273-274 行）。如果你的自定义配置覆盖了容器安全上下文，升级后请确认容器根文件系统只读不会影响挂载的采集路径。

3.2 3.x 升级到 4.x

从4.0.0起，该 Chart 全面采用 Kubernetes 推荐标签体系（app.kubernetes.io/name、app.kubernetes.io/instance、app.kubernetes.io/version等）。由于标签变化会导致新旧 DaemonSet 并存或选择器不匹配，升级前必须先删除旧 DaemonSet：

kubectl delete daemonset -l app=prometheus-node-exporter helm upgrade -i prometheus-node-exporter prometheus-community/prometheus-node-exporter

如果你使用自定义的 ServiceMonitor 或 PodMonitor，请同步升级其selector字段以匹配新标签。图表自身生成的选择器标签定义在 _helpers.tpl 的prometheus-node-exporter.selectorLabels中，为app.kubernetes.io/name与app.kubernetes.io/instance的组合。

3.3 2.x 升级到 3.x

2.x 中启用宿主机根文件系统挂载的写法为：

hostRootFsMount: true

3.x 起必须改写为对象形式，以同时控制挂载传播模式：

hostRootFsMount: enabled: true mountPropagation: HostToContainer

mountPropagation的取值与 Kubernetes 卷挂载传播语义一致：None、HostToContainer、Bidirectional，缺省为None（当前 Chart 默认值即HostToContainer，见 values.yaml 第 299-306 行）。

四、核心配置：values.yaml 深度解读

以下按功能域拆解 values.yaml 中的关键参数。

4.1 镜像与拉取策略

镜像拼接逻辑在 _helpers.tpl 的prometheus-node-exporter.image中实现：优先global.imageRegistry，tag 缺省为v{AppVersion}，并支持 digest 锁定。

4.2 服务暴露

Service 模板见 service.yaml，默认携带注解prometheus.io/scrape: "true"，便于传统 Prometheus 注解发现。ci/port-values.yaml展示了通过覆盖service.port与service.targetPort自定义端口的 CI 用例。

4.3 宿主机访问与采集路径

结合 daemonset.yaml，容器默认启动参数为：

--path.procfs=/host/proc --path.sysfs=/host/sys --path.rootfs=/host/root --path.udev.data=/host/root/run/udev/data # 仅当 node-exporter >= 1.4.0 --web.listen-address=[$(HOST_IP)]:9100

其中HOST_IP环境变量的取值策略：启用 kube-rbac-proxy 时为127.0.0.1；否则若service.listenOnAllInterfaces为true则取0.0.0.0，反之取status.hostIP（宿主机 IP）。

常见extraArgs示例（如屏蔽部分磁盘设备、启用 textfile 采集器）：

extraArgs: - --collector.diskstats.ignored-devices=^(ram|loop|fd|(h|s|v)d[a-z]|nvme\d+n\d+p)\d+$ - --collector.textfile.directory=/run/prometheus

4.4 安全上下文与 RBAC

注意 daemonset.yaml 中的细节：automountServiceAccountToken仅在serviceAccount.automountServiceAccountToken或启用kubeRBACProxy时为true，避免默认情况下无谓地把集群凭证注入到每个节点的采集器容器中。

4.5 调度与生命周期

4.6 扩展挂载、Sidecar 与额外清单

• extraHostVolumeMounts：从宿主机额外挂载路径到 node-exporter 容器（可自定义mountPropagation）。
• configmaps/secrets：向容器挂载配置与密钥。
• sidecars/sidecarVolumeMount/sidecarHostVolumeMounts：注入旁路容器（如nvidia-dcgm-exporter）及其挂载。
• extraInitContainers：初始化容器。
• extraManifests：以数组形式追加任意 Kubernetes 清单（如额外 ConfigMap），由 extra-manifests.yaml 渲染。
• endpoints：当 node-exporter 部署在集群外部时，手动列出其地址供 Service 引用。
• verticalPodAutoscaler：默认关闭；开启后可配置maxAllowed/minAllowed/updatePolicy等。
• networkPolicy：默认关闭；开启后仅允许 Service 端口的入站流量且禁止出站（模板见 networkpolicy.yaml）。

五、端点安全保护：kube-rbac-proxy 集成

5.1 启用方式

将kubeRBACProxy.enabled设为true，Chart 会在 DaemonSet 中追加一个kube-rbac-proxy容器（镜像默认quay.io/brancz/kube-rbac-proxy:v0.14.0），保护 node-exporter 的 HTTP 端点，请求经同一 Service 转发但改为HTTPS（详见 daemonset.yaml 第 181-220 行）。

启用后内部端口联动：node-exporter 容器监听8100（由$servicePort := ternary 8100 .Values.service.port .Values.kubeRBACProxy.enabled决定），kube-rbac-proxy 以--secure-listen-address=:9100对外提供 HTTPS，并--upstream=http://127.0.0.1:8100/反代到本机采集端点，同时暴露8888端口的healthz就绪检查。

RBAC 授权由 rbac-configmap.yaml 生成的 ConfigMap 提供：kube-rbac-proxy 以resourceAttributes模式校验请求者对被保护 Service 的get权限。

5.2 授权访问示例

要访问被保护的端点，请求方（例如一个 ServiceAccount）需要被授予类似下面的 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus-node-exporter-read rules: - apiGroups: [ "" ] resources: ["services/node-exporter-prometheus-node-exporter"] verbs: - get

其中resources中的名称需替换为你实际的 Service 全名（<release>-prometheus-node-exporter）。同时，图表自身在启用该功能时会创建 ClusterRole（见 clusterrole.yaml），为 kube-rbac-proxy 授予tokenreviews与subjectaccessreviews的create权限，这是其完成身份认证与鉴权的前提。更丰富的用法可参考 kube-rbac-proxy 官方的resource-attributes示例。

5.3 相关可调参数

kubeRBACProxy.extraArgs可追加额外 CLI 参数（如 TLS 密码套件、日志文件）；kubeRBACProxy.resources与kubeRBACProxy.containerSecurityContext可分别定制代理容器的资源与安全上下文。

六、对接 Prometheus：ServiceMonitor 与 PodMonitor 双通道

6.1 ServiceMonitor（推荐）

启用：

prometheus: monitor: enabled: true

模板见 servicemonitor.yaml，渲染出的资源默认使用monitoring.coreos.com/v1API 版本，关键字段包括：

• jobLabel：默认app.kubernetes.io/name；
• podTargetLabels：把 Pod 标签转移到目标上（可用于携带节点相关信息）；
• scheme：默认http；启用 kube-rbac-proxy 时应改为https并配置tlsConfig/authorization；
• basicAuth/bearerTokenFile：抓取时的认证方式；
• interval/scrapeTimeout：默认抓取间隔跟随 Prometheus 全局配置，scrapeTimeout默认10s；
• attachMetadata.node: true：把节点元数据附加到发现的目标（要求 Prometheus ≥ 2.35.0）；
• 抓取限额：sampleLimit、targetLimit、labelLimit、labelNameLengthLimit、labelValueLengthLimit（由 _helpers.tpl 中的servicemonitor.scrapeLimits模板渲染）；
• relabelings/metricRelabelings：抓取前/入库前的标签重写。

6.2 PodMonitor（大规模集群场景）

对于 node-exporter 端点数量极多（如超过 1000 个）的环境，可改用 PodMonitor 绕过单一 Service 的聚合，模板见 podmonitor.yaml：

prometheus: podMonitor: enabled: true

PodMonitor 默认以/metrics路径、httpscheme 抓取，并额外提供honorTimestamps、honorLabels、enableHttp2、filterRunning、followRedirects、params、authorization、oauth2等 endpoint 级选项。切换注意：从 ServiceMonitor 切到 PodMonitor 后，时间序列不再携带service标签，依赖该标签的 PromQL 查询需要同步调整。

6.3 标签联动：releaseLabel 的作用

若你的 Prometheus 通过release: <name>标签选择 ServiceMonitor（kube-prometheus-stack 的常见做法），可将releaseLabel: true打开，让图表在资源标签中加入release: {{ .Release.Name }}，从而开箱即用地被 kube-prometheus-stack 抓取。

七、Laf 项目中的实际落地方式

在本仓库中，该 Chart 作为 build/charts/kube-prometheus-stack 整套监控图表集的一个依赖子图被管理。父图表 build/charts/kube-prometheus-stack/values.yaml（第 1887 行起）展示了在 Laf 部署场景下的典型覆盖配置：

prometheus-node-exporter: namespaceOverride: "" podLabels: jobLabel: node-exporter releaseLabel: true extraArgs: - --collector.filesystem.mount-points-exclude=^/(dev|proc|sys|var/lib/docker/.+|var/lib/kubelet/.+)($|/)

要点解读：

• podLabels.jobLabel: node-exporter：为 Pod 打上jobLabel: node-exporter标签，使 ServiceMonitor 发现后生成的 job 名与官方告警规则、Grafana 大盘中的job="node-exporter"查询习惯保持一致；
• releaseLabel: true：确保 ServiceMonitor 携带release标签，可直接被 kube-prometheus-stack 的默认选择器命中；
• extraArgs中的挂载点排除规则：过滤掉/dev、/proc、/sys、Docker 与 kubelet 数据目录下的伪文件系统挂载点，避免文件系统指标出现海量噪声，这是生产集群非常实用的瘦身技巧。

八、从模板到资源：一次 Helm 渲染会产出什么

根据templates/目录，该 Chart 默认渲染的 Kubernetes 资源包括：

从 daemonset.yaml 的卷定义可以看出其“直读宿主机”的核心机制：/proc、/sys以hostPath方式挂载，宿主机根目录/以只读方式挂载到/host/root，配合hostPID: true与hostNetwork: true，使每个节点上的 node-exporter 都能以最小的权限面读取完整的系统指标。

九、运维最佳实践小结

1. 控制指标噪声：通过extraArgs排除容器运行时与 kubelet 数据目录的挂载点、忽略ram/loop/fd等虚拟磁盘设备，可显著降低基数与存储成本。
2. 按需关闭默认开启项：rbac.pspEnabled在已启用 Pod Security Admission 的新集群可关闭；hostNetwork在强调网络隔离的环境可按需评估。
3. 安全抓取优先：生产环境建议开启kubeRBACProxy.enabled，并以https+tlsConfig或authorization方式对接 ServiceMonitor，配合上文的最小权限 ClusterRole 完成鉴权。
4. 升级前做标签审计：跨 3.x → 4.x 升级必须删除旧 DaemonSet，并同步检查自定义 ServiceMonitor/PodMonitor 的 selector。
5. 验证抓取链路：安装后先kubectl get daemonset确认每节点就绪，再直接curl节点 9100 端口的/metrics或/（探针路径）验证采集端点健康，最后确认 Prometheus 侧 ServiceMonitor 的目标列表。

结合 Laf 仓库中父图表的调优案例（jobLabel: node-exporter与挂载点排除规则），这套方案可以直接作为自建集群“节点级可观测性”的标准化模板投入使用。

【免费下载链接】lafLaf is a vibrant cloud development platform that provides essential tools like cloud functions, databases, and storage solutions. It enables developers to quickly unleash their creativity and bring innovative ideas to life with ease.项目地址: https://gitcode.com/GitHub_Trending/la/laf