NPD原理解析

作者: 王勇1024 | 来源:发表于2021-08-19 16:10 被阅读0次

NPD 入门

简介

节点问题检测器（Node Problem Detector） 是一个守护程序，用于监视和报告节点的健康状况（包括内核死锁、OOM、系统线程数压力、系统文件描述符压力等指标）。你可以将节点问题探测器以 DaemonSet 或独立守护程序运行。节点问题检测器从各种守护进程收集节点问题，并以 NodeCondition 和 Event 的形式报告给 API Server。
您可以通过检测相应的指标，提前预知节点的资源压力，可以在节点开始驱逐 Pod 之前手动释放或扩容节点资源压力，防止 Kubenetes 进行资源回收或节点不可用可能带来的损失。

Git 仓库地址：https://github.com/kubernetes/node-problem-detector

Kubernetes 目前问题

基础架构守护程序问题：ntp服务关闭；
硬件问题：CPU，内存或磁盘损坏；
内核问题：内核死锁，文件系统损坏；
容器运行时问题：运行时守护程序无响应
...

当kubernetes中节点发生上述问题，在整个集群中，k8s服务组件并不会感知以上问题，就会导致pod仍会调度至问题节点。

为了解决这个问题，我们引入了这个新的守护进程node-problem-detector，从各个守护进程收集节点问题，并使它们对上游层可见。一旦上游层面发现了这些问题，我们就可以讨论补救措施。

NPD 使用

构建

NPD使用Go modules管理依赖，因此构建它需要Go SDK 1.11+：

cd $GOPATH/src/k8s.io
go get k8s.io/node-problem-detector
cd node-problem-detector

export GO111MODULE=on 
go mod vendor

# 设置构建标记
export BUILD_TAGS="disable_custom_plugin_monitor disable_system_stats_monitor"

# 在Ubuntu 14.04上需要安装
sudo apt install libsystemd-journal-dev
make all

安装

# add repo
helm repo add feisky https://feisky.xyz/kubernetes-charts
helm update

# install packages
helm install feisky/node-problem-detector --namespace kube-system --name npd

启动参数

--version: 在控制台打印 NPD 的版本号.
--hostname-override: 供 NPD 使用的自定义的节点名称，NPD 会优先获取该参数设置的节点名称，其次是从 NODE_NAME 环境变量中获取，最后从 os.Hostname() 方法获取。

system-log-monitor 相关参数

--config.system-log-monitor: system log monitor 配置文件路径，多个文件用逗号分隔, 如 config/kernel-monitor.json. NPD 会为每一个配置文件生成单独的 log monitor。你可以使用不同的 log monitors 来监控不同的系统日志。

system-stats-monitor 相关参数

--config.system-stats-monitor: system status monitor 配置文件路径，多个文件用逗号分隔, 如 config/system-stats-monitor.json. NPD 会为每一个配置文件生成单独的 status monitor。你可以使用不同的 status monitors 来监控系统的不同状态。

custom-plugin-monitor 相关参数

--config.custom-plugin-monitor: 用户自定义插件配置文件路径，多个文件用逗号分隔, 如 config/custom-plugin-monitor.json. NPD 会为每一个配置文件生成单独的自定义插件监视器。你可以使用不同的自定义插件监视器来监控不同的系统问题。

K8s exporter 相关参数

--enable-k8s-exporter: 是否开启上报信息到 API Server，默认为 true.
--apiserver-override: 一个URI参数，用于自定义node-problem-detector连接apiserver的地址。如果--enable-k8s-exporter为false，则忽略此内容。格式与Heapster的源标志相同。例如，要在没有身份验证的情况下运行，请使用以下配置： http://APISERVER_IP:APISERVER_PORT?inClusterConfig=false

请参阅 heapster 文档以获取可用选项的完整列表。
--address: 绑定 NPD 服务器的地址。
--port: NPD 服务端口，如果为0，表示禁用 NPD 服务。

Prometheus exporter 相关参数

--prometheus-address: 绑定Prometheus抓取端点的地址，默认为127.0.0.1。
--prometheus-port: 绑定Prometheus抓取端点的端口，默认为20257。使用0禁用。

Stackdriver exporter 相关参数

--exporter.stackdriver: Stackdriver exporter程序配置文件的路径，例如 config/exporter/stackdriver-exporter.json，默认为空字符串。设置为空字符串以禁用。

过期参数

--system-log-monitors: system log monitor 配置文件路径，多个文件用逗号分隔。该选项已过期, 被 --config.system-log-monitor 取代, 即将被移除. 如果在启动NPD时同时设置了 --system-log-monitors 和 --config.system-log-monitor，会引发panic。
--custom-plugin-monitors: 用户自定义插件配置文件路径，多个文件用逗号分隔。该选项已过期, 被 --config.custom-plugin-monitor 取代, 即将被移除. 如果在启动NPD时同时设置了 --custom-plugin-monitors 和 --config.custom-plugin-monitor，会引发panic。

覆盖配置文件

构建节点问题检测器的 docker 镜像时，会嵌入默认配置。

不过，你可以像下面这样使用 ConfigMap 将其覆盖：

1、更改 config/ 中的配置文件

2、创建 ConfigMap node-strick-detector-config：

kubectl create configmap node-problem-detector-config --from-file=config/

3、更改 node-problem-detector.yaml 以使用 ConfigMap:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-problem-detector-v0.1
  namespace: kube-system
  labels:
    k8s-app: node-problem-detector
    version: v0.1
    kubernetes.io/cluster-service: "true"
spec:
  selector:
    matchLabels:
      k8s-app: node-problem-detector  
      version: v0.1
      kubernetes.io/cluster-service: "true"
  template:
    metadata:
      labels:
        k8s-app: node-problem-detector
        version: v0.1
        kubernetes.io/cluster-service: "true"
    spec:
      hostNetwork: true
      containers:
      - name: node-problem-detector
        image: k8s.gcr.io/node-problem-detector:v0.1
        securityContext:
          privileged: true
        resources:
          limits:
            cpu: "200m"
            memory: "100Mi"
          requests:
            cpu: "20m"
            memory: "20Mi"
        volumeMounts:
        - name: log
          mountPath: /log
          readOnly: true
        - name: config # Overwrite the config/ directory with ConfigMap volume
          mountPath: /config
          readOnly: true
      volumes:
      - name: log
        hostPath:
          path: /var/log/
      - name: config # Define ConfigMap volume
        configMap:
          name: node-problem-detector-config

4、使用新的配置文件重新创建节点问题检测器：

说明： 此方法仅适用于通过 kubectl 启动的节点问题检测器。

如果节点问题检测器作为集群插件运行，则不支持覆盖配置。插件管理器不支持 ConfigMap。

如何验证NPD捕获信息

通常这些错误是比较难真实测试，只能通过发送消息到journal来模拟。

发送一个kernel deadlock类型的condition：在对应的node节点上执行以下操作

echo "task docker:7 blocked for more than 300 seconds." |systemd-cat -t kernel

然后通过k8s控制台，你可以看到对应的信息：

发送一个event

echo "Error trying v2 registry: failed to register layer: rename /var/lib/docker/image/test /var/lib/docker/image/ddd: directory not empty.*" |systemd-cat -t docker

然后通过以下命令来对应的event

kubectl describe node/xxxx

image.png

实现原理

核心组件

Problem Daemon（Monitor）

Problem Daemon 是监控任务子守护进程，NPD 会为每一个 Problem Daemon 配置文件创建一个守护进程，这些配置文件通过 --config.custom-plugin-monitor、--config.system-log-monitor、--config.system-stats-monitor 参数指定。每个 Problem Daemon监控一个特定类型的节点故障，并报告给NPD。目前 Problem Daemon 以 Goroutine 的形式运行在NPD中，未来会支持在独立进程（容器）中运行并编排为一个Pod。在编译期间，可以通过相应的标记禁用每一类 Problem Daemon。

custom-plugin-monitor：用户自定义的 Problem Daemon
system-log-monitor：系统日志监控
system-stats-monitor：系统状态监控

ProblemDaemonHandler

ProblemDaemonHandler 定义了 Problem Daemon 的初始化方法

type ProblemDaemonHandler struct {
    // 初始化 Problem Daemon实例，如果初始化过程中出错，则抛出 panic
    CreateProblemDaemonOrDie func(string) Monitor
  // 说明了从命令行参数配置 Problem Daemon 的方式
    CmdOptionDescription string
}

在NPD启动时，init()方法中完成了 ProblemDaemonHandler 的注册：

var (
    // 在 NPD 启动过程中，通过 init() 方法注册
    handlers = make(map[types.ProblemDaemonType]types.ProblemDaemonHandler)
)

// 注册 problem daemon 工厂方法，将会用于创建 problem daemon
func Register(problemDaemonType types.ProblemDaemonType, handler types.ProblemDaemonHandler) {
    handlers[problemDaemonType] = handler
}

Exporter

Exporter 用于上报节点健康信息到某种控制面。在 NPD 启动时，会根据需求初始化并启动各种 Exporter。Exporter 分为三类：

K8s Exporter：会将节点健康信息上报到 API Server。
Prometheus Exporter：负责上报节点指标信息到 Prometheus。
Plugable Exporters：可插拔的 Exporter（如 Stackdriver Exporter），我们也可以自定义 Exporter，并在 init() 方法中注册，这样在 NPD 启动时就会自动初始化并启动。

ExporterHandler

ExporterHandler 和 ProblemDaemonHandler 功能类似，其定义了 Exporter 的初始化方法。也是在NPD启动时，init()方法中完成了 ExporterHandler 的注册

type ExporterHandler struct {
    // CreateExporterOrDie initializes an exporter, panic if error occurs.
    CreateExporterOrDie func(CommandLineOptions) Exporter
    // CmdOptionDescription explains how to configure the exporter from command line arguments.
    Options CommandLineOptions
}

Condition Manager

K8s Exporter 获取到的异常 Condition 信息会上报给 Condition Manager， Condition Manager 每秒检查 Condition 的变化，并同步到 API Server 的 Node 对象中。

Problem Client

Problem Client 负责与 API Server 交互，并将巡检过程中生成的 Events 和 Conditions 上报给 API Server。

type Client interface {
    // 从 API Server 获取当前节点所有指定类型的 Conditions
    GetConditions(conditionTypes []v1.NodeConditionType) ([]*v1.NodeCondition, error)
    // 调用 API Server 接口更新当前节点的 Condition 列表
    SetConditions(conditions []v1.NodeCondition) error
    // 上报 Event 信息到 API Server
    Eventf(eventType string, source, reason, messageFmt string, args ...interface{})
    // 从 API Server 获取当前 node-problem-detector 实例所在的节点信息
    GetNode() (*v1.Node, error)
}

Problem Detector

Problem Detector 是 NPD 的核心对象，它负责启动所有的 Problem Daemon（也可以叫做 Monitor），并利用 channel 收集 Problem Daemon中发现的异常信息，然后将异常信息提交给 Exporter，Exporter 负责将这些异常信息上报到指定的控制面（如 API Server、Prometheus、Stackdriver等）。

Status

Status 是 Problem Daemon 向 Exporter 上报的异常信息对象。

type Status struct {
    // problem daemon 的名称
    Source string `json:"source"`
    // 临时的节点问题 —— 事件对象，如果此Status用于Condition更新则此字段可以为空
  // 从老到新排列在数组中
    Events []Event `json:"events"`
    // 永久的节点问题 —— NodeCondition。PD必须总是在此字段报告最新的Condition
    Conditions []Condition `json:"conditions"`
}

Tomb

用于从外部控制协程的生命周期，它的逻辑很简单，准备结束生命周期时：

外部协作者发起一个通知
协作线程接收到通知，进行清理
清理完成后，协程反向通知外部协作者
外部协作者退出阻塞

启动过程

NPD启动过程

NPD 启动过程完成的工作有：

打印 NPD 版本号
设置节点名称，优先使用命令行中设置的节点名称，其次是环境变量 NODE_NAME 中的节点名称，最次是 os.Hostname()
校验命令行参数的合法性
初始化 problem daemons
初始化默认 Exporters（包含 K8s Exporter、Prometheus Exporter）和可插拔 Exporters（如 Stackdriver Exporter）
使用 problem daemons 和 Exporters 构建 Problem Detector，并启动

检测流程

NPD检测流程

节点自愈

采集节点的健康状态是为了能够在业务Pod不可用之前提前发现节点异常，从而运维或开发人员可以对Docker、Kubelet或节点进行修复。在NPDPlus中，为了减轻运维人员的负担，提供了根据采集到的节点状态从而进行不同自愈动作的能力。集群管理员可以根据节点不同的状态配置相应的自愈能力，如重启Docker、重启Kubelet或重启CVM节点等。同时为了防止集群中的节点雪崩，在执行自愈动作之前做了严格的限流，防止节点大规模重启。同时为了防止集群中的节点雪崩，在执行自愈动作之前做了严格的限流。具体策略为：

在同一时刻只允许集群中的一个节点进行自愈行为，并且两个自愈行为之间至少间隔1分钟

当有新节点添加到集群中时，会给节点2分钟的容忍时间，防止由于节点刚刚添加到集群的不稳定性导致错误自愈

custom-plugin-monitor

此Problem Daemon为NPD提供了一种插件化机制，允许基于任何语言来编写监控脚本，只需要这些脚本遵循NPD关于退出码和标准输出的规范。通过调用用户配置的脚本来检测各种节点问题

脚本退出码：

0：对于Evnet来说表示Normal，对于NodeCondition表示False
1：对于Evnet来说表示Warning，对于NodeCondition表示True

脚本输出应该小于80字节，避免给Etcd的存储造成压力

使用标记禁用：disable_custom_plugin_monitor

示例

{
  "plugin": "custom",  // 插件类型
  "pluginConfig": { // 插件配置
    "invoke_interval": "10s", // 执行时间间隔
    "timeout": "3m", // 健康检查超时时间
    "max_output_length": 80,
    "concurrency": 1 // 并行度
  },
  "source": "health-checker", // 事件源
  "metricsReporting": true,  // 是否上报指标信息
  "conditions": [ // 发现异常后在 Node 中设置的 Condition 信息
    {
      "type": "KubeletUnhealthy",
      "reason": "KubeletIsHealthy",
      "message": "kubelet on the node is functioning properly"
    }
  ],
  "rules": [ // 巡检规则
    {
      "type": "permanent",
      "condition": "KubeletUnhealthy",
      "reason": "KubeletUnhealthy",
      "path": "/home/kubernetes/bin/health-checker", // 二进制文件路径
      "args": [ // 二进制文件启动参数
        "--component=kubelet",
        "--enable-repair=true",// 是否启用自愈，自愈会尝试重启组件
        "--cooldown-time=1m", // 冷却时间，组件启动后的一段时间为冷却时间，冷却时间能如果发现异常，不会尝试自愈
        "--loopback-time=0",// 要回溯的 journal 日志的时间，如果为0，则从组件启动时间开始回溯
        "--health-check-timeout=10s" // 健康检查超时时间
      ],
      "timeout": "3m" // 巡检超时时间
    }
  ]
}

plugin

plugin 是NPD或用户自定义的一些异常检查程序，可以用任意语言编写。custom-plugin-monitor 在执行过程中会执行这些异常检测程序，并根据返回结果来判断是否存在异常。NPD提供了三个 plugin，分别是：

health-check：检查kubelet、docker、kube-proxy、cri等进程是否健康。
log-counter：依赖的插件是 journald，其作用是统计指定的 journal 日志中近一段时间满足正则匹配的历史日志条数。
network_problem.sh：检查 conntrack table 的使用率是否超过 90%。

health-checker

命令行参数

参数名称	参数说明	默认值
systemd-service	与 --service 相同，已被 --service 取代
service	The underlying service responsible for the component. Set to the corresponding component for docker and kubelet, containerd for cri.
loopback-time	The duration to loop back, if it is 0, health-check will check from start time.	0min
log-pattern	The log pattern to look for in service journald logs. The format for flag value <failureThresholdCount>:<logPattern>
health-check-timeout	The time to wait before marking the component as unhealthy.	10s
enable-repair	Flag to enable/disable repair attempt for the component.	true
crictl-path	The path to the crictl binary. This is used to check health of cri component.	Linux：/usr/bin/crictl Windows：C:/etc/kubernetes/node/bin/crictl.exe
cri-socket-path	The path to the cri socket. Used with crictl to specify the socket path.	Linux：unix:///var/run/containerd/containerd.sock Windows：npipe:////./pipe/containerd-containerd
cooldown-time	The duration to wait for the service to be up before attempting repair.	2min
component	The component to check health for. Supports kubelet, docker, kube-proxy, and cri.

结构定义

type healthChecker struct {
    component       string // 要进行健康检查的组件名称，支持 kubelet、docker、kube-proxy 和 cri
    service         string // 组件的服务名称，需要通过 service 读取 journal 日志，并检查日志是否存在异常
    enableRepair    bool // 是否启动自动修复，如果启动自动修复，当发现异常时会调用 repairFunc 尝试自动修复
    healthCheckFunc func() (bool, error) // 组件健康检查方法
    repairFunc         func() // 组件自愈方法，这是一种”best-effort“形式的自愈，会尝试 kill 掉组件的进程，但可能失败
    uptimeFunc         func() (time.Duration, error)  // 获取组件的启动时间（启动后经过的时间）
    crictlPath         string // crictl 二进制文件路径，用于对 CRI(Container Runtime Interface) 组件执行健康检查
    healthCheckTimeout time.Duration // 健康检查超时时间
    coolDownTime       time.Duration // 服务启动后，在冷却时间内如果发现异常，不会尝试自动修复。超出冷却时间后才会尝试自动修复
    loopBackTime       time.Duration // 待检 journal 查日志的起始时间间隔，如果该值为0，则从组件启动的日志开始检查
    logPatternsToCheck map[string]int // 要检查的 journal 日志的正则表达式
}

执行流程

health-checker 的执行流程可以分为三个步骤：

调用 healthCheckFunc() 方法判断组件进程是否健康
获取组件近一段时间的 journal 日志，判断异常日志数量是否达到上限
如果前两步检查都未发现异常，则返回 true。否则，如果启动了自动修复机制，则调用 repairFunc() 尝试自愈

健康检查

func getHealthCheckFunc(hco *options.HealthCheckerOptions) func() (bool, error) {
    switch hco.Component {
    case types.KubeletComponent:
      // 访问 http://127.0.0.1:10248/healthz，判断 kubelet 是否健康
        return healthCheckEndpointOKFunc(types.KubeletHealthCheckEndpoint, hco.HealthCheckTimeout)
    case types.KubeProxyComponent:
      // 访问 http://127.0.0.1:10256/healthz，判断 kube-proxy 是否健康
        return healthCheckEndpointOKFunc(types.KubeProxyHealthCheckEndpoint, hco.HealthCheckTimeout)
    case types.DockerComponent:
        return func() (bool, error) { // 执行 docker ps 命令判断 Docker 是否健康
            if _, err := execCommand(hco.HealthCheckTimeout, getDockerPath(), "ps"); err != nil {
                return false, nil
            }
            return true, nil
        }
    case types.CRIComponent:
        return func() (bool, error) {// 执行 circtl --runtime-endpoint=unix:///var/run/containerd/containerd.sock --image-endpoint=unix:///var/run/containerd/containerd.sock
            if _, err := execCommand(hco.HealthCheckTimeout, hco.CriCtlPath, "--runtime-endpoint="+hco.CriSocketPath, "--image-endpoint="+hco.CriSocketPath, "pods"); err != nil {
                return false, nil
            }
            return true, nil
        }
    default:
        glog.Warningf("Unsupported component: %v", hco.Component)
    }

    return nil
}

组件自愈

func getRepairFunc(hco *options.HealthCheckerOptions) func() {
    switch hco.Component {
    case types.DockerComponent:
        // Use "docker ps" for docker health check. Not using crictl for docker to remove
        // dependency on the kubelet.
        return func() {
            execCommand(types.CmdTimeout, "pkill", "-SIGUSR1", "dockerd")
            execCommand(types.CmdTimeout, "systemctl", "kill", "--kill-who=main", hco.Service)
        }
    default:
        // Just kill the service for all other components
        return func() {
            execCommand(types.CmdTimeout, "systemctl", "kill", "--kill-who=main", hco.Service)
        }
    }
}

log-counter

依赖的插件是 journald，其作用是统计指定的 journal 日志中近一段时间满足正则匹配的历史日志条数。

命令行参数

参数名称	参数说明	默认值
journald-source	The source configuration of journald, e.g., kernel, kubelet, dockerd, etc
log-path	The log path that log watcher looks up
lookback	The log path that log watcher looks up
delay	The time duration log watcher delays after node boot time. This is useful when log watcher needs to wait for some time until the node is stable.
pattern	The regular expression to match the problem in log. The pattern must match to the end of the line.
count	The number of times the pattern must be found to trigger the condition	1

执行流程

log-counter执行流程

Count()

func (e *logCounter) Count() (count int, err error) {
    start := e.clock.Now()
    for {
        select {
        case log, ok := <-e.logCh:
            if !ok {
                err = fmt.Errorf("log channel closed unexpectedly")
                return
            }
            // 只统计 logCounter 启动之前的日志
            if start.Before(log.Timestamp) {
                return
            }
            e.buffer.Push(log)
            if len(e.buffer.Match(e.pattern)) != 0 {
                count++
            }
        case <-e.clock.After(timeout):
            // 如果超过一定时间没有新日志生成，则退出
            return
        }
    }
}

journal日志检查

func checkForPattern(service, logStartTime, logPattern string, logCountThreshold int) (bool, error) {
  // 从 journal 日志中匹配符合规则的错误日志
    out, err := execCommand(types.CmdTimeout, "/bin/sh", "-c",
        // Query service logs since the logStartTime
        `journalctl --unit "`+service+`" --since "`+logStartTime+
            // 正则匹配
            `" | grep -i "`+logPattern+
            // 计算错误发生次数
            `" | wc -l`)
    if err != nil {
        return true, err
    }
    occurrences, err := strconv.Atoi(out)
    if err != nil {
        return true, err
    }
  // 如果错误日志数量超过阈值，则返回 false
    if occurrences >= logCountThreshold {
        glog.Infof("%s failed log pattern check, %s occurrences: %v", service, logPattern, occurrences)
        return false, nil
    }
    return true, nil
}

network_problem.sh

检查 conntrack table 的使用率是否超过 90%

#!/bin/bash

# This plugin checks for common network issues.
# Currently only checks if conntrack table is more than 90% used.

readonly OK=0
readonly NONOK=1
readonly UNKNOWN=2

# "nf_conntrack" replaces "ip_conntrack" - support both
readonly NF_CT_COUNT_PATH='/proc/sys/net/netfilter/nf_conntrack_count'
readonly NF_CT_MAX_PATH='/proc/sys/net/netfilter/nf_conntrack_max'
readonly IP_CT_COUNT_PATH='/proc/sys/net/ipv4/netfilter/ip_conntrack_count'
readonly IP_CT_MAX_PATH='/proc/sys/net/ipv4/netfilter/ip_conntrack_max'

if [[ -f $NF_CT_COUNT_PATH ]] && [[ -f $NF_CT_MAX_PATH ]]; then
  readonly CT_COUNT_PATH=$NF_CT_COUNT_PATH
  readonly CT_MAX_PATH=$NF_CT_MAX_PATH
elif [[ -f $IP_CT_COUNT_PATH ]] && [[ -f $IP_CT_MAX_PATH ]]; then
  readonly CT_COUNT_PATH=$IP_CT_COUNT_PATH
  readonly CT_MAX_PATH=$IP_CT_MAX_PATH
else
  exit $UNKNOWN
fi

readonly conntrack_count=$(< $CT_COUNT_PATH) || exit $UNKNOWN
readonly conntrack_max=$(< $CT_MAX_PATH) || exit $UNKNOWN
readonly conntrack_usage_msg="${conntrack_count} out of ${conntrack_max}"

if (( conntrack_count > conntrack_max * 9 /10 )); then
  echo "Conntrack table usage over 90%: ${conntrack_usage_msg}"
  exit $NONOK
else
  echo "Conntrack table usage: ${conntrack_usage_msg}"
  exit $OK
fi

system-log-monitor

system-log-monitor 用于监控系统和内核日志，根据预定义规则来报告问题、指标。它支持基于文件的日志、Journald、kmsg。要监控其它日志，需要实现LogWatcher接口

LogMonitor

type logMonitor struct {
    // 配置文件路径
    configPath string
    // 读取日志的逻辑委托给LogWatcher，这里解耦的目的是支持多种类型的日志
    watcher    watchertypes.LogWatcher
    // 日志缓冲，读取的日志在此等待处理
    buffer     LogBuffer
    // 对应配置文件中的字段
    config     MonitorConfig
    // 对应配置文件中的conditions字段
    conditions []types.Condition
    // 输入日志条目的通道
    logCh      <-chan *logtypes.Log
    // 输出状态的通道
    output     chan *types.Status
    // 用于控制此Monitor的生命周期
    tomb       *tomb.Tomb
}

LogWatcher

LogWatcher 的主要作用的监听文件更新，并将追加的文件内容写入 LogBuffer 中供 LogMonitor 处理。NPD 中提供了三种 LogWatcher 的实现：

filelog：监听任意文本类型日志。
journald：监听 journald 日志。
kmsg：监听内核日志设备，如 /dev/kmsg。

LogWatcher 也需要在 init() 方法中完成注册。

type LogWatcher interface {
    // 开始监控日志，并通过通道输出日志
    Watch() (<-chan *types.Log, error)
    // 停止，注意释放打开的资源
    Stop()
}

filelog

filelog 通过监控指定的文件更新，并对日志内容进行正则匹配，以发现异常日志，从而判断组件是否正常。

{
    "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.*"
        }
    ]
}

journald

journald 底层依赖 sdjournal 包，监控系统日志的更新，并且可以从指定的历史时间点开始读取。如果未指定 journal 日志路径，则从系统默认路径读取。读取到的日志会转换成 logtypes.Log 对象，并写入 logCh 通道中。journal 通过监控 journal 文件更新，并对日志内容进行正则匹配，以发现异常日志，从而判断组件是否正常。

{
    "plugin": "journald",
    "pluginConfig": {
        "source": "abrt-notification"
    },
    "logPath": "/var/log/journal", // journal 日志路径
    "lookback": "5m", // 日志回溯时长
    "bufferSize": 10, // log 缓存大小（日志条数）
    "source": "abrt-adaptor",
    "conditions": [],
    "rules": [ // 健康检查规则
        {
            "type": "temporary",
            "reason": "CCPPCrash",
            "pattern": "Process \\d+ \\(\\S+\\) crashed in .*"
        },
        {
            "type": "temporary",
            "reason": "UncaughtException",
            "pattern": "Process \\d+ \\(\\S+\\) of user \\d+ encountered an uncaught \\S+ exception"
        },
        {
            "type": "temporary",
            "reason": "XorgCrash",
            "pattern": "Display server \\S+ crash in \\S+"
        },
        {
            "type": "temporary",
            "reason": "VMcore",
            "pattern": "System encountered a fatal error in \\S+"
        },
        {
            "type": "temporary",
            "reason": "Kerneloops",
            "pattern": "System encountered a non-fatal error in \\S+"
        }
    ]
}

kmsg

kmsg 和 journald 的实现原理类似，它底层依赖 kmsgparser 包，实现内核日志的监控更新和回溯。默认的文件路径是 /dev/kmsg。kmsg 通过监控系统日志文件更新，并对日志内容进行正则匹配，以发现异常日志，从而判断组件是否正常。

{
    "plugin": "kmsg",
    "logPath": "/dev/kmsg", // 内核日志路径
    "lookback": "5m",  // 日志回溯时长
    "bufferSize": 10,  // 缓存大小（日志条数）
    "source": "kernel-monitor",
    "metricsReporting": true,
    "conditions": [
        {
            "type": "KernelDeadlock",
            "reason": "KernelHasNoDeadlock",
            "message": "kernel has no deadlock"
        },
        {
            "type": "ReadonlyFilesystem",
            "reason": "FilesystemIsNotReadOnly",
            "message": "Filesystem is not read-only"
        }
    ],
    "rules": [
        {
            "type": "temporary",
            "reason": "OOMKilling",
            "pattern": "Killed process \\d+ (.+) total-vm:\\d+kB, anon-rss:\\d+kB, file-rss:\\d+kB.*"
        },
        {
            "type": "temporary",
            "reason": "TaskHung",
            "pattern": "task [\\S ]+:\\w+ blocked for more than \\w+ seconds\\."
        },
        {
            "type": "temporary",
            "reason": "UnregisterNetDevice",
            "pattern": "unregister_netdevice: waiting for \\w+ to become free. Usage count = \\d+"
        },
        {
            "type": "temporary",
            "reason": "KernelOops",
            "pattern": "BUG: unable to handle kernel NULL pointer dereference at .*"
        },
        {
            "type": "temporary",
            "reason": "KernelOops",
            "pattern": "divide error: 0000 \\[#\\d+\\] SMP"
        },
        {
            "type": "temporary",
            "reason": "Ext4Error",
            "pattern": "EXT4-fs error .*"
        },
        {
            "type": "temporary",
            "reason": "Ext4Warning",
            "pattern": "EXT4-fs warning .*"
        },
        {
            "type": "temporary",
            "reason": "IOError",
            "pattern": "Buffer I/O error .*"
        },
        {
            "type": "temporary",
            "reason": "MemoryReadError",
            "pattern": "CE memory read error .*"
        },
        {
            "type": "permanent",
            "condition": "KernelDeadlock",
            "reason": "AUFSUmountHung",
            "pattern": "task umount\\.aufs:\\w+ blocked for more than \\w+ seconds\\."
        },
        {
            "type": "permanent",
            "condition": "KernelDeadlock",
            "reason": "DockerHung",
            "pattern": "task docker:\\w+ blocked for more than \\w+ seconds\\."
        },
        {
            "type": "permanent",
            "condition": "ReadonlyFilesystem",
            "reason": "FilesystemIsReadOnly",
            "pattern": "Remounting filesystem read-only"
        }
    ]
}

LogBuffer

LogBuffer 是一个可循环写入的日志队列，max 字段控制可记录日志的最大条数，当日志条数超过 max 时，就会从头覆盖写入。LogBuffer 也支持正则匹配 buffer 中的日志内容。

type LogBuffer interface {
    // 把日志写入 log buffer 中
    Push(*types.Log)
    // 对 buffer 中的日志进行正则匹配
    Match(string) []*types.Log
  // 把 log buffer 中的日志按时间由远到近连接成一个字符串
    String() string
}

实现原理

启动过程

执行过程

system-stats-monitor

将各种健康相关的统计信息报告为Metrics

目前支持的组件仅仅有主机信息、磁盘：

disk/io_time 设备队列非空时间，毫秒
disk/weighted_io 设备队列非空时间加权，毫秒
disk/avg_queue_len 上次调用插件以来，平均排队请求数

使用标记禁用：disable_system_stats_monitor

cpuCollector：采集 CPU 相关指标信息。
diskCollector：采集磁盘相关指标信息。
hostCollector：采集宿主机相关指标信息。
memoryCollector：采集内存相关指标信息。
osFeatureCollector：采集系统属性相关指标。
netCollector：采集网络相关指标信息。

检查规则

自定义插件规则

CustomRule

// 自定义规则（插件），描述CPM如何调用插件，分析调用结果
type CustomRule struct {
    // 报告永久还是临时问题
    Type types.Type `json:"type"`
    // 此问题触发哪种NodeCondition，仅当永久问题才设置此字段
    Condition string `json:"condition"`
    // 问题的简短原因，对于永久问题，通常描述NodeCondition的一个子类型
    Reason string `json:"reason"`
    // 自定义插件（脚本）的文件路径
    Path string `json:"path"`
    // 传递给自定义插件的参数
    Args []string `json:"args"`
    // 自定义插件执行超时
    TimeoutString *string `json:"timeout"`
    Timeout *time.Duration `json:"-"`
}

示例

health-checker-kubelet.json

系统日志监控规则

systemlogtypes.Rule

type Rule struct {
    // 报告永久还是临时问题
    Type types.Type `json:"type"`
    // 此问题触发哪种NodeCondition，仅当永久问题才设置此字段
    Condition string `json:"condition"`
    // 问题的简短原因，对于永久问题，通常描述NodeCondition的一个子类型
    Reason string `json:"reason"`
    // Pattern is the regular expression to match the problem in log.
    // Notice that the pattern must match to the end of the line.
    Pattern string `json:"pattern"`
}

示例

kernel-monitor.json

异常上报

node-problem-detector使用 Event 和 NodeCondition 将问题报告给apiserver。

NodeCondition：导致节点无法处理于Pod生命周期的的永久性问题应报告为NodeCondition。
Event：对pod影响有限的临时问题应作为event报告。

异常类型

temporary：致节点无法处理于Pod生命周期的的永久性问题
permanent：对pod影响有限的临时问题

指标上报

通过配置 metricsReporting 可以选择是否开启 System Log Monitor 的指标上报功能。该字段默认为 true。

临时异常只会上报 counter 指标，如下：

# HELP problem_counter Number of times a specific type of problem have occurred.
# TYPE problem_counter counter
problem_counter{reason="TaskHung"} 2

永久异常会上报 gauge 指标和 counter 指标，如下：

# HELP problem_counter Number of times a specific type of problem have occurred.
# TYPE problem_counter counter
problem_counter{reason="DockerHung"} 1
# HELP problem_gauge Whether a specific type of problem is affecting the node or not.
# TYPE problem_gauge gauge
problem_gauge{condition="KernelDeadlock",reason="DockerHung"} 1

Counter是一个累计类型的数据指标，它代表单调递增的计数器。
Gauge是可以任意上下波动数值的指标类型。

指标

NPD对指标这一概念也进行了封装，它依赖OpenCensus而不是Prometheus这样具体的实现的API。

所有指标如下：

const (
    CPURunnableTaskCountID  MetricID = "cpu/runnable_task_count"
    CPUUsageTimeID          MetricID = "cpu/usage_time"
    CPULoad1m               MetricID = "cpu/load_1m"
    CPULoad5m               MetricID = "cpu/load_5m"
    CPULoad15m              MetricID = "cpu/load_15m"
    ProblemCounterID        MetricID = "problem_counter"
    ProblemGaugeID          MetricID = "problem_gauge"
    DiskIOTimeID            MetricID = "disk/io_time"
    DiskWeightedIOID        MetricID = "disk/weighted_io"
    DiskAvgQueueLenID       MetricID = "disk/avg_queue_len"
    DiskOpsCountID          MetricID = "disk/operation_count"
    DiskMergedOpsCountID    MetricID = "disk/merged_operation_count"
    DiskOpsBytesID          MetricID = "disk/operation_bytes_count"
    DiskOpsTimeID           MetricID = "disk/operation_time"
    DiskBytesUsedID         MetricID = "disk/bytes_used"
    HostUptimeID            MetricID = "host/uptime"
    MemoryBytesUsedID       MetricID = "memory/bytes_used"
    MemoryAnonymousUsedID   MetricID = "memory/anonymous_used"
    MemoryPageCacheUsedID   MetricID = "memory/page_cache_used"
    MemoryUnevictableUsedID MetricID = "memory/unevictable_used"
    MemoryDirtyUsedID       MetricID = "memory/dirty_used"
    OSFeatureID             MetricID = "system/os_feature"
    SystemProcessesTotal    MetricID = "system/processes_total"
    SystemProcsRunning      MetricID = "system/procs_running"
    SystemProcsBlocked      MetricID = "system/procs_blocked"
    SystemInterruptsTotal   MetricID = "system/interrupts_total"
    SystemCPUStat           MetricID = "system/cpu_stat"
    NetDevRxBytes           MetricID = "net/rx_bytes"
    NetDevRxPackets         MetricID = "net/rx_packets"
    NetDevRxErrors          MetricID = "net/rx_errors"
    NetDevRxDropped         MetricID = "net/rx_dropped"
    NetDevRxFifo            MetricID = "net/rx_fifo"
    NetDevRxFrame           MetricID = "net/rx_frame"
    NetDevRxCompressed      MetricID = "net/rx_compressed"
    NetDevRxMulticast       MetricID = "net/rx_multicast"
    NetDevTxBytes           MetricID = "net/tx_bytes"
    NetDevTxPackets         MetricID = "net/tx_packets"
    NetDevTxErrors          MetricID = "net/tx_errors"
    NetDevTxDropped         MetricID = "net/tx_dropped"
    NetDevTxFifo            MetricID = "net/tx_fifo"
    NetDevTxCollisions      MetricID = "net/tx_collisions"
    NetDevTxCarrier         MetricID = "net/tx_carrier"
    NetDevTxCompressed      MetricID = "net/tx_compressed"
)

其中ProblemCounterID 和 ProblemGaugeID 是针对所有Problem的Counter/Gauge，其他都是SystemStatsMonitor暴露的指标。

治愈系统

在NPD的术语中，治愈系统（Remedy System）是一个或一组进程，负责分析NPD检测出的问题，并且采取补救措施，让K8S集群恢复健康状态。

目前官方提及的治愈系统有只有Draino。NPD项目并没有提供对Draino的集成，你需要手工部署和配置Draino。

Draino

Draino是Planet开源的小项目，最初在Planet用于解决GCE上运行的K8S集群的持久卷相关进程（mkfs.ext4、mount等）永久卡死在不可中断睡眠状态的问题。Draino的工作方式简单粗暴，只是检测到NodeCondition并Cordon、Drain节点。

基于Label和NodeCondition自动的Drain掉故障K8S节点：

具有匹配标签的的K8S节点，只要进入指定的NodeCondition之一，立即禁止调度（Cordoned）
在禁止调度之后一段时间，节点被Drain掉

Draino可以联用Cluster Autoscaler，自动的终结掉Drained的节点。

在Descheduler项目成熟以后，可以代替Draino。

参考文档

kubernetes addons之node-problem-detector

Kubernetes故障检测和自愈

NPD原理解析

NPD 入门

简介

Kubernetes 目前问题

NPD 使用

构建

安装

启动参数

system-log-monitor 相关参数

system-stats-monitor 相关参数

custom-plugin-monitor 相关参数

K8s exporter 相关参数

Prometheus exporter 相关参数

Stackdriver exporter 相关参数

过期参数

覆盖配置文件

如何验证NPD捕获信息

实现原理

核心组件

Problem Daemon（Monitor）

ProblemDaemonHandler

Exporter

ExporterHandler

Condition Manager

Problem Client

Problem Detector

Status

Tomb

启动过程

检测流程

节点自愈

custom-plugin-monitor

示例

plugin

health-checker

命令行参数

结构定义

执行流程

健康检查

组件自愈

log-counter

命令行参数

执行流程

Count()

journal日志检查

network_problem.sh

system-log-monitor

LogMonitor

LogWatcher

filelog

journald

kmsg

LogBuffer

实现原理

启动过程

执行过程

system-stats-monitor

检查规则

自定义插件规则

CustomRule

示例

系统日志监控规则

systemlogtypes.Rule

示例

异常上报

异常类型

指标上报

指标

治愈系统

Draino

参考文档

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Kubernetes