EthanWalkerTech

K8s 发布失败后,大家第一眼先看哪?

  •  
  •   EthanWalkerTech · 1 day ago · 2318 views
    最近在看 K8s 的发布链路,发现一个挺现实的问题:发布失败以后,每个人下手的位置不太一样。

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

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

    大家平时遇到这种发布失败,一般第一步看哪里?
    有固定顺序吗,还是看报错现象临时判断?
    22 replies    2026-06-26 14:25:02 +08:00
    owt5008137
        1
    owt5008137  
       1 day ago via Android
    打开 AI ,帮我诊断。。。(🐶
    cheng6563
        2
    cheng6563  
       1 day ago
    k8s 发布不就是跑命令吗,所以 claude code 一把嗦。
    pollux
        3
    pollux  
       1 day ago
    不是先看日志吗?
    beyondstars
        4
    beyondstars  
       1 day ago
    kubernetes 资源是互相联系的,从顶层看起,比如 deployment >> replicaset >> pod >> container ,既要看 kubernetes 事件,也要看日志。

    不要无脑给 ai 所有权限让 ai 全权控制你的 k8s 集群,出了问题你没法甩锅给 ai 。可以把你认为可疑的但又不理解的信息丢给 ai 。
    Mystery0
        5
    Mystery0  
       1 day ago via Android
    不是应该看报错信息吗
    momocraft
        6
    momocraft  
       1 day ago
    想想怎么让自己不用想
    hackroad
        7
    hackroad  
       1 day ago
    每个动作不应该埋点日志?失败了通知对应的动作?
    seers
        8
    seers  
       1 day ago
    当然是从最底下开始一层层往上了,从现象倒推是最快的
    weiwenhao
        9
    weiwenhao  
       1 day ago   ❤️ 1
    原则上是先看失败日志,一般都是让 cladue 直接操作 kubectl 帮我分析,cladue 都会让我审批我看命令是查询相关的就直接通过。
    winson030
        10
    winson030  
       1 day ago
    一般出事都会告警,先看告警日志吧。
    alexluo1
        11
    alexluo1  
       1 day ago   ❤️ 1
    看甲方群
    limusi
        12
    limusi  
       1 day ago
    claude code + kubectl 90%的情况 1 分钟内能解
    cctv6
        13
    cctv6  
       23h 28m ago via Android
    kubectl get/describe pod/deploy
    Frankcox
        14
    Frankcox  
       22h 23m ago
    这个要看 devops ,cicd 做的水平
    如果就扔给我一句:“应用发布失败了”
    那我首先要看 deployment, pod 的状态,看是集群问题还是应用问题。
    locoz
        15
    locoz  
       21h 25m ago via Android
    当然是不看啊,这点破事还得需要让我来看的话,那说明 AI 出问题了。正常来说应该是 AI 自己处理完,真碰到什么有风险的操作要决策了才来找我,没风险单纯碰到点小问题都该自己解决。
    ExplodingDragon
        16
    ExplodingDragon  
       14h 34m ago   ❤️ 1
    先看看 deploy 或者 sts 版本有没有滚完,哪里出错,先保证业务稳定性,剩下的 ci/cd 问题可以慢慢修
    5261
        17
    5261  
       14h 17m ago
    我还停留在 docker compose 水平阶段
    noahjsn
        18
    noahjsn  
       12h 52m ago
    kubectl logs <pod_name>
    EthanWalkerTech
        19
    EthanWalkerTech  
    OP
       11h 58m ago
    @ExplodingDragon 这个思路挺实用的。

    一般怎么看 rollout 卡在哪一步?先看 Deployment / StatefulSet ,还是直接看 Pod 和 Events ?
    EthanWalkerTech
        20
    EthanWalkerTech  
    OP
       11h 50m ago
    @weiwenhao 你这个是 claude 先判断要查什么,然后你再确认命令吗?

    平时只读 kubectl 命令你会直接放行? get pods 、describe pod 、logs 、get events 这类?
    weiwenhao
        21
    weiwenhao  
       11h 26m ago   ❤️ 1
    @EthanWalkerTech 是的,比如我收到了告警,然后我把告警信息给到 cladue ,比如下面这个是昨天的


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

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

    '''


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

    其实我 apply 命令也是让 cladue 写 yaml, 然后我过一遍,然后让 cladue 进行 apply 。
    EthanWalkerTech
        22
    EthanWalkerTech  
    OP
       8h 52m ago
    @weiwenhao 放行的时候一般只关注命令是不是查询,还是会看下 namespace 资源类型这些是否越界?
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   2622 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 56ms · UTC 15:17 · PVG 23:17 · LAX 08:17 · JFK 11:17
    ♥ Do have faith in what you're doing.