IT策士 10余年一线大厂经验专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章助你少走弯路。在第 6 篇中我们学会了用docker stats实时查看容器的 CPU 和内存使用。在 Docker Compose 的单机环境下这基本够用——毕竟所有容器都挤在一台宿主机上出问题了你也可以快速定位。但在 Kubernetes 集群中一切都变了。Pod 可能在节点间漂移Deployment 可能会静默地增加副本一个微小的内存泄漏可能在几个小时后压垮整个节点。没有一套好的监控体系你就像在黑夜里飞行——看不到速度、高度也看不到前方是否有山峰。这一篇我们就来点亮这盏探照灯从Metrics Server到Prometheus系统性地构建起对集群和应用的“上帝视角”。一、为什么需要专业的监控Kubernetes 本身并不会自动告诉你 Pod 是否健康、资源是否充足——它只负责调度。要了解集群的“身体状况”你需要两样东西资源指标CPU、内存、磁盘等供 Scheduler 和 HPA 使用。应用指标请求速率、错误率、延迟等供开发者和运维人员分析。Docker Compose 时代我们只能通过docker stats或ctop获取非常有限的实时数据没有历史趋势也没有告警能力。而 Kubernetes 生态提供了一条完整的监控链Metrics Server→ 聚合资源指标点亮kubectl top驱动 HPA。Prometheus Grafana→ 采集、存储、可视化任何自定义指标并触发告警。二、部署 Metrics Server让kubectl top工作2.1 Metrics Server 的作用Metrics Server 是 Kubernetes 官方维护的轻量级资源指标聚合器。它从每个节点的 kubelet 收集 CPU 和内存数据并通过 Metrics API 暴露出来。没有它kubectl top命令会报错。HPA水平自动伸缩无法根据 CPU/内存使用率自动调整副本数。2.2 在 Minikube 中启用Minikube 通常默认不启用 Metrics Server我们需要手动开启minikube addonsenablemetrics-server输出 Themetrics-serveraddon is enabled验证安装kubectl get pods-nkube-system-lk8s-appmetrics-server# NAME READY STATUS RESTARTS AGE# metrics-server-xxxxxxxxxx-xxxxx 1/1 Running 0 60s2.3 体验kubectl top# 查看节点资源使用情况kubectltopnodes输出NAME CPU(cores)CPU% MEMORY(bytes)MEMORY% minikube 150m7% 1200Mi31%# 查看 Pod 资源使用情况kubectltoppods-ndefault输出NAME CPU(cores)MEMORY(bytes)flask-deployment-xxxxxxxxx-xxxxx 25m 95Mi redis-xxxxxxxxxx-xxxxx 10m 15Mi现在kubectl top成为了你的第一个集群级监控工具。但要记住它只反映当前时刻的快照没有历史数据也没有应用层面的指标。三、部署 Prometheus Grafana 监控栈对于生产级监控Prometheus是事实上的标准。它是 CNCF云原生计算基金会继 Kubernetes 之后第二个毕业的项目。它基于“拉取”模式工作Prometheus 服务器定期从目标如 Pod、Service的 HTTP 端点抓取指标数据存储在内部时序数据库中。我们将使用kube-prometheus-stack这个 Helm Chart 来一次性部署 Prometheus、Grafana 和 Alertmanager。3.1 使用 Helm 部署# 添加 Prometheus Community 仓库helm repoaddprometheus-community https://prometheus-community.github.io/helm-charts helm repo update# 安装 kube-prometheus-stackhelm upgrade--installmonitoring prometheus-community/kube-prometheus-stack\--namespacemonitoring --create-namespace\--setgrafana.adminPasswordadmin123输出Releasemonitoringdoes not exist. Installing it now. NAME: monitoring LAST DEPLOYED: Mon May2710:00:002025NAMESPACE: monitoring STATUS: deployed REVISION:1NOTES:...这条命令部署了以下组件3.2 访问 GrafanaGrafana 默认通过 ClusterIP 暴露我们用kubectl port-forward来访问kubectl port-forward-nmonitoring svc/monitoring-grafana3000:80然后在浏览器中打开http://localhost:3000使用用户名admin和你设置的密码登录。登录后点击左侧 “Dashboards”你会发现很多预置的仪表板例如Kubernetes / Compute Resources / PodPod 的 CPU、内存、网络 IO 仪表板。Kubernetes / Compute Resources / Cluster集群整体资源概览。四、监控贯穿案例Flask 计数器应用现在我们要把贯穿始终的Flask Redis 计数器应用接入 Prometheus 监控。4.1 为 Flask 应用添加指标端点为了让 Prometheus 能抓取数据我们的 Flask 应用需要暴露一个/metrics端点。我们使用prometheus_flask_exporter库。修改app.pyfrom prometheus_flask_exporterimportPrometheusMetrics... appFlask(__name__)metricsPrometheusMetrics(app)# 自动为每个请求生成计数器/延迟直方图# 添加一个自定义业务指标当前访问总数infometrics.info(app_info,Application info,version3.0)...同时更新requirements.txt添加依赖prometheus_flask_exporter0.23.1构建新镜像flask-redis-counter:3.0-monitoring推送到 Minikube 环境并更新 Deployment。4.2 创建 ServiceMonitor 让 Prometheus 发现目标Prometheus Operator 使用ServiceMonitor来自动发现需要抓取的目标。我们只需创建一个 ServiceMonitor 指向我们的 Flask Service。apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: flask-app-monitor namespace: monitoring spec: selector: matchLabels: app: flask-counter# 匹配 Flask Service 的标签endpoints: - port: http path: /metrics interval: 15s假设你的 Flask Service 有标签app: flask-counter且端口名称为http或指定端口号。kubectl apply-fservicemonitor.yaml稍等片刻Prometheus 就会自动发现并开始抓取 Flask 应用的指标。4.3 在 Grafana 中查看应用指标回到 Grafana我们导入一个简单的 Flask 仪表板或者直接在新仪表板中创建面板点击 “” → “Import”输入仪表板 ID如11572是一个通用的 Flask 仪表板Prometheus 数据源选择Prometheus。加载后你会看到请求速率Request Rate随着curl或浏览器访问曲线上下波动。错误率Error Rate如果触发了 500 错误这里的线条会飙升。请求延迟Request DurationP50、P95、P99 延迟分布。应用自定义指标比如我们定义的访问总次数计数器flask_http_request_total。模拟高负载使用wrk或ab对http://Ingress-IP/counter发起持续并发请求。你会看到 Grafana 中的 CPU 和请求速率指标迅速攀升。当 CPU 使用率超过我们设定的 HPA 阈值例如 50%HPA 会自动增加 Pod 副本数这在第 36 篇资源管理中提到的 ResourceQuota 和后续的弹性伸缩中将发挥关键作用。此时文字描述一下仪表板上的变化趋势因为无法截图Grafana 仪表板上flask_http_request_total计数器持续线性增长rate(flask_http_request_total[5m])显示当前 QPS 稳定在 120 左右。node_cpu_seconds_total面板显示集群节点 CPU 使用率从 15% 上升到 65%。*container_memory_usage_bytes面板显示 Flask Pod 内存使用稳定在 100MiB~128MiB 之间符合我们设置的 Requests/Limits。*五、告警让监控主动说话监控的目的是在问题发生时及时通知我们而不是等用户投诉后才去查看仪表板。Prometheus 通过Alertmanager实现这一功能。5.1 创建一个告警规则我们定义一个规则如果某个 Pod 在最近 5 分钟内频繁重启超过 2 次就触发告警。apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: pod-restart-alert namespace: monitoring spec: groups: - name: pod-restart rules: - alert: PodFrequentlyRestarting expr: rate(kube_pod_container_status_restarts_total{namespacedefault}[5m])2for: 1m labels: severity: warning annotations: summary:Pod {{$labels.pod }} is restarting frequentlydescription:Pod {{$labels.pod }} in namespace {{$labels.namespace }} has restarted {{$value}} times in the last 5 minutes.应用此规则后如果某个 Pod比如配置错误导致 CrashLoopBackOff频繁重启Prometheus 会将告警发送给 Alertmanager。5.2 配置 Alertmanager 通知在kube-prometheus-stack的values.yaml中可以配置 Alertmanager 的通知方式如 Email、Slack、Webhook。这里我们模拟一个 Slack 通知alertmanager: config: receivers: - name:slackslack_configs: - api_url:https://hooks.slack.com/services/...channel:#k8s-alertsroute: receiver:slackgroup_by:[alertname]group_wait: 10s group_interval: 10s repeat_interval: 1h告警效果描述当你故意将 Flask Deployment 的镜像改为一个不存在的版本触发 ImagePullBackOffAlertmanager 会在 1 分钟内检测到 Pod 频繁重启并发送如下告警到 Slack*“Alert: PodFrequentlyRestarting, Severity: warning, Pod flask-deployment-xxxxxxxx-xxxxx has restarted 3 times in the last 5 minutes.”*六、技术演进路线图从 Docker 到 K8s 的监控能力演进单机容器化Dockerdocker stats、ctop提供即时快照无历史无告警。单机编排Compose同上依赖宿主机工具。集群编排K8s 核心对象Metrics Server 提供基础资源指标支持kubectl top和 HPA。生产级运维监控、日志等Prometheus Grafana Alertmanager 构建起完整的监控、可视化与告警闭环。至此你的集群不再是一个“黑盒”。你可以回答下面这些关键问题集群还有多少资源可用为什么这个 Deployment 的响应变慢了如何提前收到磁盘即将耗尽的通知七、本篇总结Metrics Server是 K8s 资源监控的基石为kubectl top和 HPA 提供数据。Prometheus Stack提供了从指标采集、存储、可视化Grafana到告警Alertmanager的一站式方案。监控实战我们将 Flask 应用接入 Prometheus查看了请求速率、错误率等指标并创建了 Pod 重启告警规则。通过这篇你初步构建了 K8s 的“神经系统”。但监控只解决了“发现问题”日志则用于“定位原因”。下一篇——第 42 篇日志管理使用 EFK 或 Loki 采集日志我们将深入日志聚合的世界用 Loki 优雅地管理所有容器日志。想了解更多还可以去各个平台搜索「IT策士」一起升级 IT 思维