K8s 发布失败后，大家第一眼先看哪？

[EthanWalkerTech]

最近在看 K8s 的发布链路，发现一个挺现实的问题：发布失败以后，每个人下手的位置不太一样。

有人先翻 CI ，看是不是镜像没打出来；有人先看 Helm / Argo CD ，确认资源有没有真正下到集群；也有人直接 kubectl describe pod ，先扫 Events 、Pod 状态、Deployment ；还有人第一反应是去看业务日志。

我有点纠结的是：第一步到底该先确认发布动作有没有真正执行成功，还是直接进集群看 Pod 为什么没起来。

大家平时遇到这种发布失败，一般第一步看哪里？
有固定顺序吗，还是看报错现象临时判断？

[owt5008137]

打开 AI ，帮我诊断。。。（🐶

[cheng6563]

k8s 发布不就是跑命令吗，所以 claude code 一把嗦。

[pollux]

不是先看日志吗？

[beyondstars]

kubernetes 资源是互相联系的，从顶层看起，比如 deployment >> replicaset >> pod >> container ，既要看 kubernetes 事件，也要看日志。

不要无脑给 ai 所有权限让 ai 全权控制你的 k8s 集群，出了问题你没法甩锅给 ai 。可以把你认为可疑的但又不理解的信息丢给 ai 。

[Mystery0]

不是应该看报错信息吗

[momocraft]

想想怎么让自己不用想

[hackroad]

每个动作不应该埋点日志？失败了通知对应的动作？

[seers]

当然是从最底下开始一层层往上了，从现象倒推是最快的

[weiwenhao]

原则上是先看失败日志，一般都是让 cladue 直接操作 kubectl 帮我分析，cladue 都会让我审批我看命令是查询相关的就直接通过。

[winson030]

一般出事都会告警，先看告警日志吧。

[alexluo1]

看甲方群

[limusi]

claude code + kubectl 90%的情况 1 分钟内能解

[cctv6]

kubectl get/describe pod/deploy

[Frankcox]

这个要看 devops ，cicd 做的水平
如果就扔给我一句：“应用发布失败了”
那我首先要看 deployment, pod 的状态，看是集群问题还是应用问题。

[locoz]

当然是不看啊，这点破事还得需要让我来看的话，那说明 AI 出问题了。正常来说应该是 AI 自己处理完，真碰到什么有风险的操作要决策了才来找我，没风险单纯碰到点小问题都该自己解决。

[ExplodingDragon]

先看看 deploy 或者 sts 版本有没有滚完，哪里出错，先保证业务稳定性，剩下的 ci/cd 问题可以慢慢修

[5261]

我还停留在 docker compose 水平阶段

[noahjsn]

kubectl logs <pod_name>

[EthanWalkerTech]

@ExplodingDragon 这个思路挺实用的。

一般怎么看 rollout 卡在哪一步？先看 Deployment / StatefulSet ，还是直接看 Pod 和 Events ？

[EthanWalkerTech]

@weiwenhao 你这个是 claude 先判断要查什么，然后你再确认命令吗？

平时只读 kubectl 命令你会直接放行？ get pods 、describe pod 、logs 、get events 这类？