Kubernetes Node Problem Detector Helm Chart 部署与配置指南-优快云博客

【免费下载链接】charts

⚠️(OBSOLETE) Curated applications for Kubernetes

项目地址： https://gitcode.com/gh_mirrors/chart/charts

导读

本文基于当前仓库中的 stable/node-problem-detector Helm Chart，系统讲解如何在 Kubernetes 集群中部署 node-problem-detector——一个运行在每个节点上、负责探测节点问题（如内核死锁、磁盘损坏、OOM、Docker 异常等）并向 apiserver 上报的守护进程。通过阅读本文，你将掌握该 Chart 的安装、卸载、完整参数配置、自定义日志监控规则（custom monitor definitions）的编写方式，以及 RBAC、Prometheus 指标暴露等底层实现细节，可直接用于生产集群的节点健康监测实践。

说明：该 Chart 所在的 helm/charts 仓库已于 2020 年 11 月 13 日起停止更新并归档，node-problem-detector Chart 已迁移至 Delivery Hero 的 Helm 仓库，本文将基于当前仓库内保留的版本（Chart version 1.8.3，appVersion v0.8.1）展开。

一、Chart 定位与工作原理

node-problem-detector 的目标是让各类节点问题对集群管理层"可见"。它作为 DaemonSet 部署在集群中的每个节点上，持续监测节点状态，发现异常后将节点问题报告给 Kubernetes apiserver，从而使调度器、控制器等上层组件能够感知并做出响应（例如通过 NodeCondition 驱动驱逐或告警）。

从 Chart.yaml 中可以看到该 Chart 的元数据：

apiVersion: v1、engine: gotpl（使用经典的 Helm v2 模板引擎语法）；
version: "1.8.3"、appVersion: v0.8.1，即 Chart 版本与上游镜像版本对应；
keywords: node, problem, detector, monitoring；
镜像仓库默认 k8s.gcr.io/node-problem-detector:v0.8.1（见 values.yaml）。

1.1 工作流程概览

结合 daemonset.yaml 中容器启动命令，可以还原 node-problem-detector 的核心工作流程：

exec /node-problem-detector \
  --logtostderr \
  --config.system-log-monitor=/config/kernel-monitor.json,/config/docker-monitor.json \
  --prometheus-address=0.0.0.0 \
  --prometheus-port=20257 \
  --k8s-exporter-heartbeat-period=5m0s

即守护进程启动后：

依据系统日志监控配置（--config.system-log-monitor）从 /var/log 等宿主目录读取内核日志、Docker 日志；
匹配预定义的正则规则，识别出临时性（temporary）或永久性（permanent）节点问题；
通过 k8s-exporter 将问题同步上报至 apiserver（通过 patch 节点的 NodeCondition、创建 Event），同步周期由 heartBeatPeriod 控制；
同时在 0.0.0.0:20257/metrics 暴露 Prometheus 指标。

二、安装前准备（Prerequisites）

集群版本需为 Kubernetes 1.9+，并启用 Beta APIs（该 Chart 在编写时依赖 apps/v1 的 DaemonSet 与 RBAC API）；
使用 Helm 客户端执行安装命令，默认命名空间为安装时指定的命名空间（README 示例中常部署到 kube-system）。

三、安装 Chart

3.1 快速安装（默认配置）

$ helm install stable/node-problem-detector

3.2 指定 release 名称安装

$ helm install my-release stable/node-problem-detector

3.3 使用自定义 values 文件安装

$ helm install my-release stable/node-problem-detector --values values.yaml --namespace kube-system

该命令将：

使用 values.yaml 中覆盖的参数（如自定义监控规则、资源限制、容忍度等）；
将 release 安装到 kube-system 命名空间——这是节点级守护进程的常见部署位置。

安装完成后，可用 NOTES 中提示的命令验证 Pod 是否启动：

$ kubectl --namespace=<命名空间> get pods -l "app.kubernetes.io/name=node-problem-detector,app.kubernetes.io/instance=<RELEASE_NAME>"

（该提示由 NOTES.txt 模板在安装时渲染输出。）

3.4 卸载 Chart

$ helm delete my-release

四、Chart 完整配置参数

以下参数表来自 README.md，并已与 values.yaml 中的默认值逐项核对。

参数	描述	默认值
`affinity`	节点/Pod 亲和性映射	`{}`
`annotations`	可选的 DaemonSet 注解	`{}`
`fullnameOverride`	覆盖 Chart 生成的完整名称	`nil`
`image.pullPolicy`	镜像拉取策略	`IfNotPresent`
`image.repository`	镜像仓库	`k8s.gcr.io/node-problem-detector`
`image.tag`	镜像标签	`v0.8.1`
`hostpath.logdir`	K8s 宿主上的日志目录路径	`/var/log`
`nameOverride`	覆盖 Chart 名称	`nil`
`rbac.create`	是否创建 RBAC 资源	`true`
`rbac.pspEnabled`	是否启用 PodSecurityPolicy	`false`
`hostNetwork`	是否以宿主网络运行 Pod	`false`
`priorityClassName`	优先级类名	`""`
`securityContext`	Pod 安全上下文	`{privileged: true}`
`resources`	Pod 资源请求与限制	`{}`
`settings.custom_monitor_definitions`	用户自定义监控规则定义	`{}`
`settings.log_monitors`	系统日志监控配置文件列表	`[/config/kernel-monitor.json, /config/docker-monitor.json]`
`settings.custom_plugin_monitors`	自定义插件监控配置文件列表	`[]`
`settings.prometheus_address`	Prometheus exporter 监听地址	`0.0.0.0`
`settings.prometheus_port`	Prometheus exporter 监听端口	`20257`
`settings.heartBeatPeriod`	与 apiserver 同步的间隔	`5m0s`
`serviceAccount.create`	是否创建 ServiceAccount	`true`
`serviceAccount.name`	要创建的 ServiceAccount 名称	模板生成值
`tolerations`	可选的 DaemonSet 容忍度	`[{effect: NoSchedule, operator: Exists}]`
`nodeSelector`	可选的 DaemonSet 节点选择器	`{}`
`env`	可选的 DaemonSet 环境变量	`[]`
`labels`	可选的 DaemonSet 标签	`{}`
`extraVolumes`	可选的附加卷	`[]`
`extraVolumeMounts`	可选的附加卷挂载	`[]`
`updateStrategy`	DaemonSet 更新策略	`RollingUpdate`
`maxUnavailable`	更新期间最大不可用 Pod 数	`1`

在 helm install 时，既可以使用 --set key=value[,key=value] 指定单个参数，也可以提供一个包含上述参数的 YAML 文件（--values）。

4.1 模板中的命名规则

从 _helpers.tpl 可以看到本 Chart 的名称生成逻辑：

name：default .Chart.Name .Values.nameOverride，截断至 63 字符；
fullname：优先使用 fullnameOverride；否则若 release 名已包含 chart 名则直接用 release 名，否则拼接为 <release>-<chart>；
serviceAccountName：serviceAccount.create=true 时默认使用 fullname，否则回退为 default；
自定义配置 ConfigMap 命名：<fullname>-custom-config。

这些命名规则决定了 Pod、ServiceAccount、ClusterRole 等资源的实际名称，排查问题时可在 kubectl get all -n <namespace> 中对照确认。

五、自定义监控规则（Custom Monitor Definitions）

5.1 机制说明

该 Chart 支持用户自定义节点问题监控规则。规则以 YAML 键值对的形式写在 settings.custom_monitor_definitions 下，会被 custom-config-configmap.yaml 渲染为一个 ConfigMap（名称为 <fullname>-custom-config），并通过 daemonset.yaml 中的 custom-config 卷以只读方式挂载到容器内的 /custom-config 路径。

自定义规则是对镜像内置规则（位于 /config）的补充，不会覆盖内置规则。

5.2 配置示例

以下是一个用于监控 Docker 日志的 filelog 插件自定义规则示例（来自 values.yaml 的注释示例）：

settings:
  custom_monitor_definitions:
    docker-monitor-filelog.json: |
      {
        "plugin": "filelog",
        "pluginConfig": {
          "timestamp": "^time=\"(\\S*)\"",
          "message": "msg=\"([^\n]*)\"",
          "timestampFormat": "2006-01-02T15:04:05.999999999-07:00"
        },
        "logPath": "/var/log/docker.log",
        "lookback": "5m",
        "bufferSize": 10,
        "source": "docker-monitor",
        "conditions": [],
        "rules": [
          {
            "type": "temporary",
            "reason": "CorruptDockerImage",
            "pattern": "Error trying v2 registry: failed to register layer: rename /var/lib/docker/image/(.+) /var/lib/docker/image/(.+): directory not empty.*"
          }
        ]
      }

规则字段含义：

plugin / pluginConfig：使用的日志插件（filelog）及其时间戳、消息字段的解析正则；
logPath：日志文件在宿主上的绝对路径；
lookback：回看窗口（如 5m 表示仅分析最近 5 分钟的日志）；
bufferSize：读取缓冲区大小；
rules[].type：问题类型，temporary（临时问题，恢复后自动清除状态）或 permanent（永久问题）；
rules[].reason：上报给 apiserver 的问题原因标识（如 CorruptDockerImage）；
rules[].pattern：用于匹配日志行的正则表达式。

5.3 激活自定义规则

定义好上述内容后，需要在 settings.log_monitors 或 settings.custom_plugin_monitors 中引用：

settings:
  log_monitors:
    - /config/kernel-monitor.json
    - /config/docker-monitor.json
    - /custom-config/docker-monitor-filelog.json

log_monitors：/config 下的内置监控配置 + /custom-config/ 下的自定义配置，通过启动参数 --config.system-log-monitor（逗号分隔）传入；
custom_plugin_monitors：自定义插件型监控配置（如 systemd 监控），通过 --custom-plugin-monitors 参数传入，默认 []。

从 daemonset.yaml 的启动命令可见，log_monitors 与 custom_plugin_monitors 列表会被拼接为逗号分隔的参数串。此外，DaemonSet Pod 的注解 checksum/config 会基于该 ConfigMap 内容计算 sha256 校验和，因此修改自定义规则后滚动更新 Pod 会自动触发，无需手动重启。

六、RBAC 与权限模型

6.1 默认 ClusterRole

当 rbac.create=true 时，Chart 会创建 clusterrole.yaml 中的 ClusterRole，包含三类权限：

API 组	资源	操作
`""`（core）	`nodes`	`get`
`""`（core）	`nodes/status`	`patch`
`""`（core）	`events`	`create`、`patch`、`update`

这三类权限与 node-problem-detector 的上报机制严格对应：

读取 nodes 获取节点信息；
patch nodes/status 更新节点 NodeCondition；
向 events 写入/更新事件，供上层控制器与运维系统感知。

同时还会创建 ClusterRoleBinding（clusterrolebinding.yaml）将 ClusterRole 绑定到 Chart 创建的 ServiceAccount（serviceaccount.yaml，由 serviceAccount.create 控制）。

6.2 PodSecurityPolicy

当 rbac.pspEnabled=true 时，Chart 会创建 psp.yaml 定义的 PodSecurityPolicy，其要点：

privileged: true、allowPrivilegeEscalation: true、允许所有 capabilities（'*'）；
允许 hostPath 等全部常见卷类型；
hostNetwork: false、hostIPC: false、hostPID: false；
runAsUser / seLinux / supplementalGroups / fsGroup 均采用 RunAsAny。

同时 Chart 会创建对应的 PSP ClusterRole 与绑定（psp-clusterrole.yaml、psp-clusterrolebinding.yaml）。PSP 的 apiVersion 根据集群版本自动选择（policy/v1beta1 或 extensions/v1beta1，见 _helpers.tpl 中的 podSecurityPolicy.apiVersion）。由于安全策略会在安全要求严格的环境中禁用 PSP，该选项默认关闭。

七、DaemonSet 行为细节

7.1 卷与挂载

daemonset.yaml 中声明了三个核心卷：

卷名	类型	挂载点	用途
`log`	hostPath（`/var/log`，由 `hostpath.logdir` 控制）	`/var/log`	读取宿主节点日志
`localtime`	hostPath（`/etc/localtime`，`FileOrCreate`）	`/etc/localtime`（只读）	对齐节点时区，确保日志时间戳解析正确
`custom-config`	ConfigMap（`<fullname>-custom-config`）	`/custom-config`（只读）	注入自定义监控规则

hostpath.logdir 是 Pod 读取宿主日志的关键路径，若节点日志位于非标准路径，应调整此参数。

7.2 关键容器配置

自动注入 NODE_NAME 环境变量（来源 spec.nodeName 的 fieldRef），供节点问题上报时标识节点；
默认 securityContext: {privileged: true}，因为守护进程需要读取宿主系统日志；
暴露名为 exporter 的端口（默认 20257），供 Prometheus 抓取；
hostNetwork 默认 false（不推荐开启，仅特定场景需要）；
默认容忍度 [{effect: NoSchedule, operator: Exists}]，使 Pod 能够调度到所有节点（即使节点存在 NoSchedule 污点），这是节点级守护进程的典型配置；
默认 updateStrategy: RollingUpdate、maxUnavailable: 1，保证滚动更新时同一时刻至多一个节点上的实例不可用。

7.3 资源与调度

resources：默认 {}（无资源限制），生产环境建议显式设置 CPU/内存请求与限制；
affinity、nodeSelector：可分别通过亲和性与节点选择器将 DaemonSet 限定在特定节点池；
priorityClassName：可设置优先级类，确保节点级关键组件在资源紧张时优先调度；
extraVolumes / extraVolumeMounts / env / annotations / labels：提供通用的扩展入口，满足注入 sidecar 配置、追加环境变量等定制需求。

八、Prometheus 指标采集（ServiceMonitor）

该 Chart 额外提供了 Prometheus 指标暴露能力：

node-problem-detector 本身以 --prometheus-address / --prometheus-port 暴露 /metrics 端点（默认 0.0.0.0:20257）；
当 metrics.serviceMonitor.enabled=true 时，Chart 会创建：
- service.yaml：一个 ClusterIP: None 的 headless Service（端口名 exporter，端口即 settings.prometheus_port），用于发现各节点上的 exporter 端点；
- servicemonitor.yaml：一个 monitoring.coreos.com/v1 的 ServiceMonitor，抓取间隔 60s，路径 /metrics，并带有两个 relabel 规则：
  - 将 __meta_kubernetes_pod_node_name 映射为 node 标签；
  - 将 __meta_kubernetes_pod_host_ip 映射为 host_ip 标签。
通过 metrics.serviceMonitor.additionalLabels 可以附加自定义标签（例如 release: prometheus），便于被 Prometheus Operator 的 serviceMonitorSelector 选中。启用后即可在 Grafana 等面板中以 node、host_ip 维度观察各节点的 problem detector 指标。

九、仓库状态与迁移说明（重要）

当前仓库中的 node-problem-detector Chart 属于 Helm Charts 归档仓库的一部分，状态如下：

自 2020 年 11 月 13 日起，本仓库中的 Chart 不再更新；
该 Chart 已迁移至 Delivery Hero 的 Helm 仓库，Chart.yaml 中 deprecated: true 字段亦明确标记弃用。

若需继续获取该 Chart 的更新版本，可添加新仓库并改用新的 Chart 名称：

helm repo add deliveryhero https://charts.deliveryhero.io/public
helm search repo deliveryhero

后续所有 Helm 命令中的 Chart 名称由 stable/node-problem-detector 替换为 deliveryhero/node-problem-detector：

# 新安装
helm install --name <RELEASE_NAME> deliveryhero/node-problem-detector
# 升级既有安装
helm upgrade --name <RELEASE_NAME> deliveryhero/node-problem-detector

因此，若你正在规划新环境，建议直接使用迁移后的仓库；若你维护的存量集群仍在使用本仓库版本，则应结合升级路径评估迁移窗口。本文所描述的架构与配置逻辑在两个版本间保持连续，阅读本文对使用迁移后的 Chart 同样具有参考价值。

十、实战配置速查

10.1 最小生产化 values.yaml 示例

image:
  repository: k8s.gcr.io/node-problem-detector
  tag: v0.8.1
  pullPolicy: IfNotPresent

rbac:
  create: true
  pspEnabled: false

serviceAccount:
  create: true

hostpath:
  logdir: /var/log/

settings:
  log_monitors:
    - /config/kernel-monitor.json
    - /config/docker-monitor.json
  custom_monitor_definitions: {}
  custom_plugin_monitors: []
  prometheus_address: 0.0.0.0
  prometheus_port: 20257
  heartBeatPeriod: 5m0s

tolerations:
  - effect: NoSchedule
    operator: Exists

updateStrategy: RollingUpdate
maxUnavailable: 1

保存为 values.yaml 后执行：

$ helm install my-release stable/node-problem-detector --values values.yaml --namespace kube-system

10.2 常用 `--set` 示例

# 仅修改镜像版本与心跳周期
$ helm install my-release stable/node-problem-detector \
  --set image.tag=v0.8.1 \
  --set settings.heartBeatPeriod=2m0s

# 开启 ServiceMonitor 并附加标签
$ helm install my-release stable/node-problem-detector \
  --set metrics.serviceMonitor.enabled=true \
  --set metrics.serviceMonitor.additionalLabels.release=prometheus

10.3 验证与排障

查看 Pod：kubectl -n kube-system get pods -l "app.kubernetes.io/name=node-problem-detector"
查看节点条件：kubectl describe node <NODE_NAME>（重点检查 NodeProblemDetector 相关 Condition 与 Event）；
查看日志：kubectl -n kube-system logs <POD_NAME>
拉取指标：curl <NODE_IP>:20257/metrics

结语

node-problem-detector 通过 DaemonSet 在每个节点上运行，将内核日志、Docker 日志中的异常转化为可被 Kubernetes 上层感知的 NodeCondition 与 Event，是节点级可观测性建设中不可或缺的一环。本仓库中的 Helm Chart 虽已归档，但其参数模型、RBAC 设计、自定义监控规则注入机制与 Prometheus 集成方式仍极具参考价值，可直接对照 values.yaml、daemonset.yaml、clusterrole.yaml 与 servicemonitor.yaml 深入研读，并将其迁移思路应用到迁移后的 deliveryhero/node-problem-detector Chart 中。

【免费下载链接】charts

⚠️(OBSOLETE) Curated applications for Kubernetes

项目地址： https://gitcode.com/gh_mirrors/chart/charts

点击查看免费下载

上一篇： Traceur Compiler对象展开：属性复制与合并实现

下一篇： react-native-skia 运行时着色器图像滤镜（RuntimeShader）完全指南：自定义像素处理与超采样实践

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Kubernetes Node Problem Detector Helm Chart 部署与配置指南

【免费下载链接】charts

导读

一、Chart 定位与工作原理

1.1 工作流程概览

二、安装前准备（Prerequisites）

三、安装 Chart

3.1 快速安装（默认配置）

3.2 指定 release 名称安装

3.3 使用自定义 values 文件安装

3.4 卸载 Chart

四、Chart 完整配置参数

4.1 模板中的命名规则

五、自定义监控规则（Custom Monitor Definitions）

5.1 机制说明

5.2 配置示例

5.3 激活自定义规则

六、RBAC 与权限模型

6.1 默认 ClusterRole

6.2 PodSecurityPolicy

七、DaemonSet 行为细节

7.1 卷与挂载

7.2 关键容器配置

7.3 资源与调度

八、Prometheus 指标采集（ServiceMonitor）

九、仓库状态与迁移说明（重要）

十、实战配置速查

10.1 最小生产化 values.yaml 示例

10.2 常用 --set 示例

10.3 验证与排障

结语

【免费下载链接】charts

相关推荐

Kubernetes Node Problem Detector 安装与配置指南

用 Helm 在 Kubernetes 部署 Substrate 节点：DataHaven node Chart（v5.15.0）配置与实战指南

.NET 测试项目脚手架与接线修复实战指南：让 CI 从"零测试发现"到稳定运行（scaffold-dotnet-test-project）

10.2 常用 `--set` 示例