监控概览（Metrics / Prometheus）

集群跑起来后，你一定想知道：现在 CPU 用了多少？哪个节点快撑爆了？某个 Pod 内存飙到多少？这就是监控要回答的问题。

63-1 指标从哪来

Kubernetes 里，指标由运行在节点上的组件实时采集。最核心的两个采集点是：

• cAdvisor：集成在 kubelet 里，负责收集每个容器的 CPU、内存、文件系统使用情况。
• 节点级 exporter：比如 node exporter，收集节点本身的磁盘、网络、负载等指标。

这些原始数据需要一个”汇总层”暴露给 Kubernetes API。这个汇总层就是 Metrics Server。

63-2 Metrics Server 与 kubectl top

Metrics Server 通常以 Deployment 跑在集群里。装好之后，你就能用 kubectl top 看实时用量：

# 查看节点的 CPU 和内存使用
kubectl top nodes

# 查看 Pod 的资源使用
kubectl top pods

这条命令看着简单，背后是 kubectl 去问 metrics.k8s.io API，API 再去读各节点 kubelet 汇总的指标。如果 kubectl top 报错说找不到资源，多半是 Metrics Server 没装。

63-3 指标的类型

Kubernetes 社区把指标分成几类，理解它们有助于选对工具：

• 资源指标（Resource Metrics）：CPU、内存这类，由 Metrics Server 提供，供 HPA 和 top 用。
• 自定义指标（Custom Metrics）：比如每秒请求数、消息队列长度，由 Prometheus 等适配器提供，让 HPA 能按业务指标扩缩。
• 外部指标（External Metrics）：来自集群外的数据，比如云负载均衡的连接数。

资源指标解决”够不够用”，自定义指标解决”忙不忙”。两者结合，扩缩容才更贴合真实业务。

63-4 Prometheus 的角色

Metrics Server 只管资源指标，且数据不持久化（只留最近一小段）。如果你要长期存储、画图表、设告警、按业务指标扩缩，就需要 Prometheus。

Prometheus 是一套开源的监控系统，它主动”抓取（scrape）“各组件的指标端点，存进自己的时序数据库，再配合 Grafana 画图、Alertmanager 发告警。

在 Kubernetes 里，Prometheus 通常这样工作：

• 用 ServiceMonitor 或 PodMonitor 声明要抓哪些目标。
• 通过 prometheus-adapter 把 Prometheus 里的指标转成 Kubernetes 的自定义指标 API，供 HPA 消费。
• 用 Grafana 展示节点、Pod、容器的各类图表。

63-5 监控管道整体看

把上面串起来，典型的监控管道是：

1. cAdvisor / exporter 在节点和容器上产生原始指标。
2. Metrics Server 汇总资源指标，供 kubectl top 和 HPA 用。
3. Prometheus 抓取更丰富的指标，长期存储并告警。
4. Grafana 把 Prometheus 的数据可视化。

对初学者，先把第 1、2 步跑通——装好 Metrics Server，能 kubectl top、HPA 能工作，就已经覆盖了大多数日常场景。Prometheus 那套等需要长期监控和告警时再上。

63-6 实践建议

• 新集群先装 Metrics Server，这是地基。
• kubectl top 要常看，它是发现资源瓶颈最快的入口。
• 告警要早于事故：等节点 OOM 了才看监控就晚了，用 Prometheus + Alertmanager 提前设阈值。
• 边缘或资源受限场景，Prometheus 抓取间隔别太密（30–60 秒），避免压垮网络。

一句话：监控不是装个工具就完事，而是建立”看不见集群状态就不踏实”的习惯。先用 Metrics Server 把眼睛睁开来，再逐步补上 Prometheus 的全身透视。