kubectl get events --sort-by='.lastTimestamp' 把最新的集群事件放在最后，而不是按 API 返回的随意顺序输出。事件是排查问题时第一个该看的东西，比日志更靠前——日志说的是应用做了什么，事件说的是集群对它做了什么。真正值得关心的一半故障(磁盘空间不够、镜像拉不下来、资源不足、卷没挂载上)在日志里根本看不到。
1. 怎么按时间排序 kubectl 事件？
$ clai 显示集群事件，最新的在最下面→ kubectl get events --sort-by='.lastTimestamp'不排序的话，事件按 API 恰好存储的顺序返回，根本没法看。排序键以点开头，因为它是事件对象内部的一个 JSONPath 路径。
2. 怎么只看某个命名空间里的警告？
$ clai 显示 production 命名空间里最近的警告→ kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'事件分两种类型，Normal 和 Warning。排查故障时 Normal 只会添乱。--field-selector 在服务端过滤，所以就算集群很大也不会慢。
3. 怎么看某一个 Pod 的事件？
$ clai 显示这个 pod 发生了什么→ kubectl describe pod my-app-7d9f8 -n productiondescribe 会把事件打印在输出的最后，已经关联到具体对象——通常比过滤整个事件列表更快。FailedScheduling、ImagePullBackOff、OOMKilled 这类原因就是在这里看到的。
4. 怎么看崩溃容器的日志？
$ clai 显示这个容器上一次运行的日志→ kubectl logs my-app-7d9f8 -n production --previous容器重启后，日志会被新实例的日志替换掉。--previous 取出的是上一个实例的日志——也就是真正记录了崩溃原因的那份。不加这个参数，你看到的只是刚启动、还没什么可说的进程。
5. 怎么实时观察事件？
$ clai 实时跟踪这个命名空间里的事件→ kubectl get events -n production --watch在发布时很有用：可以实时看到调度器安置 Pod、镜像拉取、就绪检查通过的全过程。Ctrl+C 停止。
6. 为什么 Pod 起不来？
$ clai 显示不是 Running 状态的 pod，以及它们的事件→ kubectl get pods -n production --field-selector status.phase!=Running先缩小范围找到有问题的 Pod，再逐个 describe。Pending 状态几乎总意味着调度器找不到地方安置这个 Pod——资源不够、放置约束不匹配，或者卷没找到。
常见陷阱
- 事件大约只保留一小时。
--event-ttl默认是 1 小时，之后事件就消失了。昨天的事故已经没法靠事件复盘——需要外部采集器。 --sort-by需要以点开头的 JSONPath。 是--sort-by='.lastTimestamp'，不是lastTimestamp。少了这个点，命令会悄悄返回一个未排序的列表。- 事件是按命名空间隔离的。 不加
-n看到的是默认命名空间，production 里的什么都看不到。想看全貌用--all-namespaces。
相关问题
日志还是事件，先看哪个？ 先看事件。它能说明应用有没有真正启动起来。日志只有在容器真正运行起来之后才有意义。
为什么 kubectl logs 是空的？ 要么容器根本没启动，要么没往 stdout 写东西，要么已经重启过了。前两种情况事件能回答，第三种靠 --previous 参数。
kubectl events 和 kubectl get events 有什么区别？ 独立的 kubectl events 命令出现得更晚，默认就按时间排序。get events 到处都能用，包括老版本集群。
相关阅读
CliAI 把一句关于 Pod 的大白话问题变成正确的 kubectl 命令，不用你记住字段选择器和 JSONPath 语法。一行命令安装。