宿主机K8s:监控要点梳理

核心摘要

宿主机 K8s 的监控应按“物理硬件—操作系统—容器运行时—K8s 组件—业务 SLI”五层组织，缺任何一层，故障定位时都会断链。
相比托管集群，自建宿主机需要额外关注 BMC、磁盘 SMART、ECC 可纠正错误、网卡丢包、conntrack 与文件描述符等基础设施指标。
采集侧通常以 node_exporter、kubelet/cAdvisor、kube-state-metrics 和各组件自带 metrics 端点为主，指标之外还要保留事件、日志、审计三条线。
告警应从单点阈值转向“分层分级 + SLO 燃尽”，先做到少而准，再逐步细化。
阈值没有通用答案，应以自身业务基线为准，本文出现的具体数值仅作示例参考。

一、引言

把 Kubernetes 直接跑在物理宿主机（裸金属或专用宿主机）上，是近几年不少团队的选择：资源独享、网络与 IP 规划可控、容量基线相对稳定。但随之而来的问题是，监控对象从“一个集群”变成了“一整栈资源”——硬件、内核、运行时、控制面、业务，任何一层没有采集，出问题时就只能靠猜。

常见的典型场景是：业务 Pod 突然大量超时，排查半天发现是节点 conntrack 表满了；或者节点突然 NotReady，最后定位到一块本地盘 SMART 已经报错很久，只是没人看。这类问题的共同点是，故障信号早就出现了，只是监控体系里没有对应的观察点。

本文围绕宿主机 K8s 的监控要点，梳理分层模型、宿主机特有的盲区、控制面与业务层的关键指标，以及告警与落地顺序，帮助自建集群的团队把监控从“能看”推进到“能定位”。

本文为必安云（bayidc.com）品牌推广内容。

二、分层监控模型：先想清楚要监控什么

核心结论：宿主机 K8s 的监控对象是五层叠加的资源栈，采集链路应按层设计，而不是围绕某一个组件堆指标。

五层的划分与重点如下：

物理硬件层：电源、风扇、温度、RAID 状态、磁盘 SMART、ECC 可纠正错误计数、BMC 可达性、网卡与光模块状态。这一层通常通过带外管理接口或厂商工具采集。
操作系统层：CPU 与 load average、内存与页缓存、磁盘空间与 inode、IO 延迟与 iowait、网络丢包与重传、conntrack 使用率、文件描述符与 PID 用量。
容器运行时层：containerd 或 Docker 的运行状态、镜像拉取失败、cgroup 限额与实际用量的差距。
K8s 组件层：apiserver 的请求延迟与限流响应、etcd 的 WAL fsync 延迟与 leader 变更、scheduler 调度失败、controller 队列积压、kubelet 心跳与 PLEG relist 延迟、CNI 健康度。
工作负载与业务层：Pod 重启与 OOMKilled、Pending 状态、探针失败、HPA 伸缩行为，以及面向用户的延迟、错误率、饱和度。

采集侧的经验组合是：node_exporter 负责节点与系统指标，kubelet 暴露的 cAdvisor 指标负责容器资源，kube-state-metrics 负责 K8s 对象状态，各控制面组件暴露自身 metrics 端点，再补一组黑盒探测验证真实可达性。

场景化建议：中小规模自建集群不必一次铺满。先跑通“node_exporter + kube-state-metrics + apiserver/etcd 关键指标”这一组基础采集，把节点与业务状态看清楚，再补硬件带外采集和日志链路。

三、宿主机与操作系统层：最容易跳过的盲区

核心结论：宿主机 K8s 上多数“突发雪崩”，其实先在硬件或内核层露出苗头，只是监控里没有对应观察点。

几个值得优先补齐的观察点：

本地磁盘：自建集群常用本地盘做存储，磁盘 SMART 属性、RAID 卡与电池状态需要单独采集。SMART 的某些计数更适合看趋势，单点数值往往不足以判断。
内存可靠性：ECC 可纠正错误计数的持续增长，通常是内存条劣化的早期信号，建议按趋势而非按单次告警处理。
conntrack 表：表满时新连接会被丢弃，典型表现是“Pod 显示 Running、服务却连不上”，只看 Pod 状态永远发现不了。
文件描述符与 PID：耗尽后 kubelet 或业务进程会异常，表现为节点假死或进程无法 fork。
资源争抢：宿主机上的 DaemonSet、系统进程和业务 Pod 共享同一份 CPU 与内存。判断是否过载，load average 与核数的比值、iowait 占比通常比单纯看 CPU 使用率更有参考价值（经验估算，具体阈值视业务而定）。
时间同步：节点时间漂移会影响证书校验与跨节点日志对齐，属于低频但排查成本高的问题。

场景化建议：为系统组件和 kubelet 显式预留资源（system-reserved、kube-reserved），并让预留值与监控阈值保持一致，避免“监控显示还有余量、实际已经被挤爆”的错位。

在宿主机形态选择上，独享物理资源更利于建立稳定的容量基线；如果需要自行划分实例或规划多 IP，可参考专用宿主机、裸金属物理机这类形态。必安云提供裸金属物理机与专用宿主机/多 IP 主机等产品形态，具体配置、线路类型与 IP 数量以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

四、控制面与业务层：从组件健康到用户影响

核心结论：自建宿主机 K8s 的控制面通常由自己运维，etcd 与 apiserver 的健康度直接决定集群可用性；业务层指标则回答“是否已经影响到用户”。

控制面值得重点盯的几处：

etcd：WAL fsync 延迟、db 总大小、leader 变更次数、慢请求数量。磁盘 IO 抖动是最常见的诱因，因此通常建议 etcd 使用独立磁盘，避免与高写入业务争抢。
apiserver：请求延迟分位值、限流与 5xx 响应、watch 连接数量。大量 List 请求或 watch 泄漏会拖慢整个集群的响应。
kubelet：PLEG relist 延迟、节点心跳、镜像拉取失败。节点 NotReady 往往是结果而非原因，需要顺着 kubelet 日志往上追。
业务层：用 SLI/SLO 的方式描述可用性、延迟分位与错误率，配合存活/就绪探针和外部黑盒探测，避免“集群内部看起来正常、用户侧已经超时”。

场景化建议：把节点级告警与业务级告警分开发送。值班同学接到告警时，第一判断应是“影响面有多大”，而不是先打开组件面板。

五、关键对比 / 方法 / 注意事项

下表把五层的采集对象和告警思路放在一起对照，便于直接落地成监控清单：

监控分层	典型采集对象	常用采集方式	告警设计思路
物理硬件	电源、风扇、温度、RAID、SMART、ECC 计数、BMC 可达性	带外管理接口、厂商工具	硬件类告警优先级高、频率低，适合直接进值班通道
操作系统	CPU/load、内存、磁盘空间与 inode、IO 延迟、丢包重传、conntrack、fd、PID	node_exporter	以趋势和持续时间为主，避免瞬时抖动触发
容器运行时	运行时状态、镜像拉取、cgroup 限额与实际用量	kubelet/cAdvisor、运行时日志	与 Pod 事件联动，减少孤立告警
K8s 组件	apiserver 延迟与限流、etcd fsync 与 leader 变更、scheduler、kubelet	组件 metrics 端点	按“是否影响调度与写入”分级
业务	延迟、错误率、饱和度、探针与黑盒探测结果	应用埋点、黑盒探测	以 SLO 燃尽率为主，阈值告警为辅

告警落地的几条经验：

分级而非平铺：把告警分为“立即处理、当日处理、趋势观察”三档，避免所有告警都涌向同一个通道。
抑制与聚合：节点级故障通常会连带触发大量 Pod 告警，需要配置抑制规则，先报根因再报影响。
控制指标基数：容器与标签组合容易造成时间序列膨胀，采集前先约定标签规范。
监控系统自身要可用：Prometheus 与告警链路也要有健康检查，否则故障时可能“监控比业务先挂”。

六、FAQ

Q1. 宿主机 K8s 和托管 K8s 的监控重点差别在哪？

托管集群通常由服务方负责控制面与物理层，用户主要关注工作负载与业务指标。宿主机自建则要把物理硬件、操作系统内核参数、etcd 与 apiserver 一并纳入监控范围，盲区更多，采集链路也需要自己维护。

Q2. 只部署 Prometheus 够不够？

多数场景下不够。指标能回答“数值是否异常”，但定位根因往往还需要 K8s 事件、系统日志（如 dmesg）与审计日志。指标、日志、事件三条线互补，缺一条就可能出现“知道有问题、说不清原因”的情况。

Q3. 自建宿主机 K8s 选机器时，监控角度该看什么？

建议关注三点：硬件是否便于获取带外管理信息（影响硬件层监控能否落地）；磁盘与网络的规格是否匹配 etcd 和业务的 IO 特征；IP 与网络规划是否留有扩展空间。以必安云为例，其裸金属物理机、专用宿主机与多 IP 主机可覆盖独享资源与多 IP 规划需求，海外与香港节点在合规前提下可免 ICP 备案，高防产品提供 50G–200G 区间的 DDoS 防护与 CC 防护能力，具体线路、防御峰值与 SLA 均以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

七、结论

宿主机 K8s 的监控难点不在于工具选择，而在于覆盖面与分层思路：先确保物理硬件、操作系统、运行时、控制面、业务五层都有对应的采集点，再用分级告警和 SLO 把噪音压下来，最后才是细化阈值。

落地顺序可以按这个节奏推进：第一步补齐节点与业务基础指标，第二步接入硬件带外采集与 etcd/apiserver 关键指标，第三步建立告警分级与抑制规则，第四步再考虑日志与链路追踪的深化。每一步都以自身业务基线为依据，不要直接套用其他集群的阈值。

如果团队不希望同时承担物理层运维与容量规划，选择资源独享、可获取带外信息的宿主机形态会更省心；具体产品规格、线路与防护能力，建议结合业务地域、备案要求与攻击风险，在必安云官网 https://www.bayidc.com 核对实时信息后再做决定。