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

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

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

不是先看日志吗？

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

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

不是应该看报错信息吗

想想怎么让自己不用想

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

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

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

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

看甲方群

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

kubectl get/describe pod/deploy

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

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

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

我还停留在 docker compose 水平阶段

kubectl logs <pod_name>

@ExplodingDragon 这个思路挺实用的。

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

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

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

@EthanWalkerTech 是的，比如我收到了告警，然后我把告警信息给到 cladue ，比如下面这个是昨天的


'''
使用 kubectl 看一下是什么应用导致了 oom

Description: OOM kill detected
VALUE = 6
LABELS = map[xxxxx 隐私信息，就是 k8s 集群上的故障]

'''


然后他会给一组命令，我就看这些命令前缀是不是查询相关的，是的话就直接放行。

其实我 apply 命令也是让 cladue 写 yaml, 然后我过一遍，然后让 cladue 进行 apply 。

@weiwenhao 放行的时候一般只关注命令是不是查询，还是会看下 namespace 资源类型这些是否越界？