Kubernetes部署监控：别等Pod崩了才想起看日志

公司新上线的微服务系统跑在ref="/tag/2020/" style="color:#E3A3CF;font-weight:bold;">Kubernetes上，早上刚开完晨会，运维同事就收到告警：订单服务CPU飙升到98%，紧接着用户投诉下单失败。翻了半天Prometheus图表，又切到Kibana查日志，最后发现是某个ConfigMap没更新，导致Java应用疯狂重试连接数据库——而这个配置变更，其实在部署流水线里就该被拦截。

监控不是加个Grafana就完事

很多团队把“上了Prometheus+Alertmanager”当成K8s监控闭环，结果真出问题时，告警邮件堆成山，却分不清是节点OOM、Etcd响应延迟，还是应用本身逻辑卡死。真正的部署监控，得从镜像推送到Pod就绪全程盯紧：镜像签名是否合法？Deployment滚动更新时有没有副本数归零？Readiness Probe连续失败几次后该不该自动回滚？

三步揪出部署过程中的异常苗头

第一，用kubectl get events -n your-namespace实时扫集群事件流。别小看这行命令，它能立刻暴露Secret挂载失败、ImagePullBackOff、NodeNotReady等部署初期的典型故障。比如某次CI/CD脚本漏写了--dry-run=client参数，直接apply了一个语法错误的YAML，event里立马出现“invalid resource name”提示。

第二，在CI阶段嵌入健康检查。部署前先curl一下服务探针端点：

curl -f http://localhost:8080/actuator/health || exit 1

再配合Helm test或Kustomize的kapp deploy --diff标志，提前发现资源配置冲突。

第三，给关键资源打上可追溯标签。在Deployment YAML里加上：

metadata:
  labels:
    deployer: "jenkins-prod-234"
    commit-sha: "a1b2c3d"
    env: "prod"

这样当某Pod异常时，一眼就能定位到是哪个构建版本、谁触发的部署、走的哪条流水线。

别让安全漏洞藏在监控盲区

某次安全扫描发现，集群里有5个Pod运行着带CVE-2023-24329漏洞的Nginx镜像，但这些Pod全被标记为“已就绪”。原来团队只监控Pod状态（Running/Ready），却没校验容器镜像的CVE状态和签名有效性。后来在Argo CD同步钩子里加了一行：

cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity-regexp ".*github.*" nginx:1.21.6

签名失效或镜像被篡改时，同步直接中断，比事后补救强十倍。

监控的本质不是记录数据，而是让每一次部署都经得起回溯和质问。你敢不敢在发布页面上，把当前Pod的镜像哈希、启动时间、最近三次健康检查响应码，全打在右上角小字里？