4、关键指标采集：Node Exporter部署与配置，cAdvisor指标与kube-state-metrics指标的区别
在Kubernetes容量规划中，指标数据的准确性与覆盖范围直接决定规划质量。本章聚焦三类核心采集组件：Node Exporter（节点资源）、cAdvisor（容器资源）与kube-state-metrics（集群状态），厘清各自的部署方式、指标特征与适用场景。
4.1 Node Exporter：节点级资源指标的采集基石
Node Exporter是Prometheus生态中用于采集宿主机操作系统级指标的标准组件，覆盖CPU、内存、磁盘、网络、文件系统等维度。在K8s环境中，通常以DaemonSet方式部署，确保每个节点运行一个实例。
4.1.1 部署配置要点
- DaemonSet模式：保证节点扩缩时自动覆盖，无需手动管理。
- hostNetwork: true：直接使用宿主机网络，避免端口映射损耗。
- hostPID: true：采集宿主机进程级指标（如CPU、内存使用率）。
- 资源限制：建议设置requests 100m CPU / 100Mi内存，limits 200m CPU / 256Mi内存。
- 端口：默认9100，通过Prometheus serviceMonitor或annotations自动发现。
关键采集指标清单（容量规划常用）
| 指标名称 | 含义 | 容量规划用途 |
|---|---|---|
| node_cpu_seconds_total | CPU累计使用时间（按mode分） | 计算CPU利用率、核时消耗 |
| node_memory_MemTotal_bytes | 节点总内存 | 内存总量基线 |
| node_memory_MemAvailable_bytes | 节点可用内存 | 内存余量评估 |
| node_filesystem_size_bytes | 文件系统总大小 | 磁盘容量规划 |
| node_filesystem_avail_bytes | 文件系统可用空间 | 磁盘水位预警 |
| node_network_receive_bytes_total | 网络接收字节累计 | 网络带宽利用率 |
| node_load1 / node_load5 / node_load15 | 系统平均负载 | CPU饱和度辅助判断 |
4.1.2 部署示例（DaemonSet关键片段）
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-exporter
namespace: monitoring
spec:
selector:
matchLabels:
app: node-exporter
template:
metadata:
labels:
app: node-exporter
spec:
hostNetwork: true
hostPID: true
containers:
- name: node-exporter
image: prom/node-exporter:v1.7.0
args:
- --path.procfs=/host/proc
- --path.sysfs=/host/sys
- --collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$/)
ports:
- containerPort: 9100
resources:
requests:
cpu: 100m
memory: 100Mi
limits:
cpu: 200m
memory: 256Mi
volumeMounts:
- name: proc
mountPath: /host/proc
readOnly: true
- name: sys
mountPath: /host/sys
readOnly: true
volumes:
- name: proc
hostPath:
path: /proc
- name: sys
hostPath:
path: /sys4.2 cAdvisor与kube-state-metrics：容器级与集群状态级指标
cAdvisor内嵌于kubelet中，提供容器运行时资源使用指标；kube-state-metrics则从Kubernetes API Server获取集群对象状态。两者在容量规划中扮演不同角色，常被混淆。
4.2.1 核心区别对比
| 对比维度 | cAdvisor | kube-state-metrics |
|---|---|---|
| 数据来源 | cgroup文件系统 + kubelet | Kubernetes API Server（list/watch） |
| 指标类型 | 资源使用量（CPU、内存、网络、磁盘IO） | 对象状态（Pod、Node、Deployment、HPA等） |
| 典型指标 | container_cpu_usage_seconds_total container_memory_working_set_bytes | kube_pod_status_phase kube_node_status_capacity_cpu_cores |
| 采集粒度 | 容器级别（container_id） | 集群对象级别（namespace/name） |
| 容量规划用途 | 实际资源消耗、利用率、饱和度 | 资源总量、分配量、副本数、配额 |
| 部署方式 | 内嵌于kubelet，无需额外部署 | 独立Deployment，需配置RBAC |
| 数据延迟 | 实时（秒级） | 依赖API Server缓存（秒级至分钟级） |
容量规划黄金组合：cAdvisor提供“实际用了多少”，kube-state-metrics提供“能分配多少”和“期望状态”。两者结合才能计算资源利用率、超分比、碎片率等核心规划指标。
4.2.2 kube-state-metrics部署要点
- 独立Deployment：建议2副本，避免单点故障。
- RBAC权限：需要get/list/watch pods、nodes、deployments、horizontalpodautoscalers等资源。
- 端口：默认8080（metrics）和8081（telemetry）。
- 资源限制：根据集群规模调整，1000节点集群建议requests 200m CPU / 512Mi内存。
- 指标过滤：通过--metric-limit-allowlist控制采集范围，减少Prometheus存储压力。
4.3 三类指标在容量规划中的协同关系
下图展示了Node Exporter、cAdvisor、kube-state-metrics在K8s集群中的采集路径与数据流向，以及它们在容量规划中的互补定位。
4.4 指标采集避坑指南
常见误区与优化建议：
- 不要用cAdvisor的container_memory_usage_bytes做容量规划：该指标包含缓存和可回收内存，应使用
container_memory_working_set_bytes反映真实占用。 - Node Exporter的node_memory_MemFree_bytes不可靠：Linux内存管理会占用空闲内存做缓存，应使用
node_memory_MemAvailable_bytes。 - kube-state-metrics的kube_node_status_capacity与kube_node_status_allocatable区别：capacity是节点硬件总量，allocatable是扣除系统预留后可分配给Pod的量，规划时以allocatable为准。
- 避免重复采集：如果已通过kubelet的/metrics/cadvisor端点采集容器指标，无需再单独部署cAdvisor容器。
- 注意指标基数爆炸：kube-state-metrics的Pod指标会随Pod数量线性增长，建议通过relabel_config过滤不需要的namespace。