Kubernetes 可观测性体系：从 metrics-server 到完整监控栈

This article is extracted from the chat log with AI. Please identify it with caution.

说明：本文由 Codex 根据作者提供的主题、素材与公开资料辅助生成，属于 AI 生成/整理内容，非作者原创。请读者自行甄别并交叉验证。

总览#

Kubernetes 的可观测性不是一个单独组件，而是一组分层能力。

最容易接触到的是：

kubectl top node
kubectl top pod

它背后通常是 metrics-server。但 metrics-server 只是 Kubernetes 资源指标链路里很小的一块，它主要服务 kubectl top、HPA 和 VPA，不等于完整监控系统。

一个更完整的 Kubernetes 可观测性体系通常包括：

层次	常见组件	解决的问题
资源指标	metrics-server	CPU、Memory 当前使用量
系统和应用指标	Prometheus	历史趋势、查询、告警规则
Kubernetes 对象状态	kube-state-metrics	Pod、Deployment、PVC、Node 等对象状态
告警	Alertmanager	告警分组、路由、静默、通知
展示	Grafana	Dashboard 和多数据源查询
日志	Fluent Bit、Loki、ELK	应用日志、容器日志、系统日志
Trace	OpenTelemetry、Jaeger、Tempo	跨服务调用链
审计	API Server Audit Logs	谁在什么时候操作了集群

所以可以先记住一句话：

metrics-server 是 Kubernetes 资源指标入口，不是完整可观测性平台。

metrics-server 的位置#

Kubernetes 官方文档把 metrics-server 所在链路称为 Resource Metrics Pipeline。

这条链路大致是：

container runtime / cAdvisor
        ↓
kubelet resource metrics
        ↓
metrics-server
        ↓
metrics.k8s.io API
        ↓
kubectl top / HPA / VPA

metrics-server 会从各节点 kubelet 获取 Pod 和 Node 的资源指标，然后通过 Kubernetes API Aggregation 暴露 metrics.k8s.io API。

可以直接查看：

kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
kubectl get --raw /apis/metrics.k8s.io/v1beta1/pods

常用命令：

kubectl top node
kubectl top pod
kubectl top pod -A
kubectl top pod -n default --containers

如果没有安装 metrics-server，通常会看到类似错误：

Metrics API not available

或者：

error: Metrics API not available

metrics-server 能做什么#

metrics-server 适合做三类事情。

第一，查看当前资源使用：

kubectl top node
kubectl top pod

第二，支撑 HPA：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

第三，支撑 VPA 等资源建议类能力。

metrics-server 不能做什么#

metrics-server 的定位很克制。它不是 Prometheus，也不是日志系统。

它不适合：

长期保存历史指标。
做复杂 PromQL 查询。
做告警规则。
展示 Dashboard。
收集业务指标。
分析日志。
做链路追踪。
做安全审计。

它更像一个“资源温度计”：

当前 CPU / Memory 大概多少？
HPA 是否有基本资源指标可用？

如果你需要回答更复杂的问题，就要引入完整观测栈。

Prometheus：指标系统核心#

Prometheus 是 Kubernetes 里最常见的指标系统。

它通常会 scrape 这些目标：

kube-apiserver
kube-scheduler
kube-controller-manager
kubelet
kube-proxy
node-exporter
应用自己的 /metrics

Prometheus 适合回答：

API Server 请求延迟是否升高？
Node CPU 是否长期过高？
某个 Deployment 的 Pod 重启次数是否异常？
应用接口 QPS 和错误率是多少？
过去 7 天内内存使用趋势如何？

和 metrics-server 相比：

对比	metrics-server	Prometheus
主要用途	HPA、VPA、kubectl top	监控、查询、告警
指标类型	CPU、Memory 资源指标	系统、应用、业务指标
历史存储	不适合作历史存储	支持时序存储
查询能力	Kubernetes Metrics API	PromQL
告警	不负责	配合 Alertmanager

kube-state-metrics：对象状态#

Kubernetes 有很多信息不是 CPU / Memory，而是“对象状态”：

Deployment 期望副本数和可用副本数
Pod phase
Pod restart count
DaemonSet 是否在所有节点就绪
PVC 是否 Bound
Job 是否失败
Node 是否 Ready

这些状态来自 Kubernetes API。kube-state-metrics 的作用是把这些 API 对象状态转换成 Prometheus 指标。

例如：

kube_deployment_status_replicas_available
kube_pod_container_status_restarts_total
kube_persistentvolumeclaim_status_phase
kube_node_status_condition

这类指标适合做告警：

Deployment 可用副本数不足
Pod 长时间 Pending
PVC 长时间未绑定
Node NotReady
Job 执行失败

Alertmanager：告警路由#

Prometheus 负责计算告警规则，Alertmanager 负责处理告警通知。

典型链路：

Prometheus rule
        ↓
Alertmanager
        ↓
Email / Slack / PagerDuty / Webhook

Alertmanager 主要负责：

告警去重。
告警分组。
告警静默。
告警抑制。
按 label 路由到不同团队。

比如：

severity=critical -> 电话告警
team=platform -> 平台组频道
namespace=payments -> 支付组频道

Grafana：展示入口#

Grafana 通常不负责采集数据，它负责展示和查询。

常见数据源：

Prometheus
Loki
Elasticsearch / OpenSearch
Tempo
Jaeger
Cloud Monitoring

常见 Dashboard：

集群总览。
Node 资源使用。
Pod / Namespace 资源使用。
API Server 健康度。
Deployment 状态。
应用 RED 指标。
日志查询。
Trace 跳转。

Grafana 的价值不只是“图好看”，而是把多个信号串起来：

指标发现问题 -> 日志定位错误 -> Trace 找到慢调用

日志：kubectl logs 只是入口#

Kubernetes 默认能让你看容器 stdout / stderr：

kubectl logs <pod-name>
kubectl logs <pod-name> -c <container-name>
kubectl logs deployment/web
kubectl logs -f <pod-name>

但这只是单 Pod 视角。生产环境通常需要集群级日志系统：

container stdout/stderr
        ↓
node log files
        ↓
Fluent Bit / Fluentd / Vector
        ↓
Loki / Elasticsearch / OpenSearch / Cloud Logging
        ↓
Grafana / Kibana

日志适合回答：

某个请求为什么失败？
某个 Pod 崩溃前打印了什么？
某个时间段有哪些错误堆栈？
某个用户操作触发了什么异常？

指标告诉你“哪里异常”，日志帮你看“具体发生了什么”。

Trace：跨服务调用链#

Trace 解决的是跨服务调用链问题。

比如一次请求经过：

gateway -> user-service -> order-service -> payment-service -> database

指标能告诉你延迟升高，日志能告诉你某个服务报错，但 Trace 能告诉你：

慢在哪个服务？
哪个下游调用超时？
哪个数据库查询耗时最长？
一次请求完整路径是什么？

典型链路：

Application SDK / OpenTelemetry
        ↓
OpenTelemetry Collector
        ↓
Jaeger / Tempo / Zipkin
        ↓
Grafana / Jaeger UI

OpenTelemetry 更像统一采集和标准，Jaeger / Tempo 更像 Trace 后端和查询系统。

Audit Logs：控制面审计#

Audit logs 是 Kubernetes API Server 的审计日志。

它记录的是：

谁在什么时候对集群做了什么？

常见问题：

谁删除了 Deployment？
谁修改了 Secret？
谁 exec 进了 Pod？
哪个 ServiceAccount 调用了敏感 API？
谁改了 RBAC？

Audit logs 和应用日志不是一回事。应用日志关注业务运行，Audit logs 关注 Kubernetes API 操作。

它适合：

安全审计。
权限排查。
事故复盘。
合规记录。

一个常见生产组合#

一个比较典型的 Kubernetes 可观测性组合是：

metrics-server
  -> kubectl top / HPA / VPA

Prometheus
  -> 系统、节点、应用指标

kube-state-metrics
  -> Kubernetes 对象状态

node-exporter
  -> 节点操作系统指标

Alertmanager
  -> 告警通知

Grafana
  -> Dashboard 和查询入口

Fluent Bit + Loki
  -> 容器日志

OpenTelemetry Collector + Tempo / Jaeger
  -> 分布式链路追踪

API Server Audit Log
  -> 控制面审计

如果只是学习或本地集群，metrics-server 足够让你跑 kubectl top 和 HPA；如果是生产环境，就应该把指标、日志、事件、Trace、审计分层补齐。

排查命令#

查看 Metrics API 是否可用：

kubectl api-resources | grep metrics
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes

查看 metrics-server：

kubectl get deploy -A | grep metrics-server
kubectl get pod -A | grep metrics-server
kubectl logs -n kube-system deploy/metrics-server

查看资源指标：

kubectl top node
kubectl top pod -A

查看对象状态：

kubectl get pod -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl describe pod <pod-name>

查看应用日志：

kubectl logs <pod-name>
kubectl logs <pod-name> -c <container-name>
kubectl logs deployment/<deployment-name>

小结#

Kubernetes 原生提供了很多观测入口，但不内置完整监控平台。

可以这样记：

metrics-server：当前 CPU / Memory 资源指标，服务 HPA 和 kubectl top。
Prometheus：系统和应用指标的采集、存储、查询。
kube-state-metrics：Kubernetes API 对象状态。
Alertmanager：告警分发。
Grafana：展示和查询入口。
Loki / ELK：日志系统。
OpenTelemetry / Jaeger / Tempo：链路追踪。
Audit logs：API Server 安全审计。

所以 metrics-server 是起点，不是终点。真正的生产可观测性，需要把指标、日志、Trace、事件和审计组合起来看。