kubectl logs 是干什么的
kubectl logs 查看 Pod 内容器的标准输出日志，是排查容器问题最直接的入口：多容器 Pod 要指定容器名，容器重启过就要读上一个实例的日志才能拿到崩溃现场，多副本还能按标签一次聚合输出。掌握这几个参数，大部分日志类问题都能在一条命令内看清。
基本信息
| 基本用法 | kubectl logs Pod 名 -n 命名空间 |
|---|---|
| 多容器 | -c 指定容器名，不指定且存在多个容器时会提示选择 |
| 上一实例 | --previous 读取已终止的那次运行的日志 |
| 范围控制 | -f 实时跟随，--tail 限制行数，--since 限制时间窗 |
| 多副本聚合 | -l 按标签选择，配合前缀参数区分输出归属 |
| 时间戳 | --timestamps 每行带时间，便于与事件时间线对齐 |
典型使用场景
- 看启动失败原因：配置错误、依赖不可达、端口占用都会在日志里出现
- 崩溃复盘：容器反复重启时读上一实例日志，拿崩溃瞬间的输出
- 跨副本对比：聚合多个副本的日志，找出行为不一致的那一个
- 与事件对照：日志加时间戳后和集群事件按时间排列，还原故障过程
- 发布验证：跟随日志观察请求处理是否正常，确认没有异常堆栈
- 剔除噪音：用行数与时间窗参数快速缩小到出问题的那几分钟
参数速查
| 参数 | 作用 | 使用注意 |
|---|---|---|
| -c 容器名 | 指定容器 | 多容器 Pod 必填 |
| --previous | 读上一实例日志 | 崩溃排查的关键参数 |
| --tail=200 | 只看最后若干行 | 不加时可能刷出巨量历史日志 |
| --since=1h | 限定时间窗 | 定位某段故障时最有效 |
| --timestamps | 每行加时间戳 | 用于与事件、监控对齐 |
| -l app=web | 按标签选多副本 | 输出会混在一起，需要前缀区分 |
| --prefix=true | 给每行加来源前缀 | 多副本聚合时必开 |
使用示例
使用示例
kubectl logs web-1 -n dev --tail=200 # 看尾部日志
kubectl logs web-1 -c istio-proxy # 指定容器
kubectl logs web-1 --previous # 看崩溃的那一次
kubectl logs -l app=web --prefix=true --tail=50 # 多副本聚合，带来源前缀
kubectl logs web-1 --timestamps --since=30m # 带时间戳看最近半小时日志带时间戳后再与集群事件对照，崩溃时间线会非常清楚：先看事件给出时间点，再用时间窗精确取日志，比从头部翻起高效得多。
重启过的容器要看上一实例日志：当前实例往往刚启动，输出里没有崩溃信息，只看当前日志很容易得出『没有报错』的错误结论。
多容器 Pod 不指定容器会直接报错，这不是功能坏了，而是需要明确读哪一个容器的输出。
日志实现与集群日志系统有关：接入集中采集后，命令行能查到的范围可能受保留策略限制，长周期回溯要去日志平台。
日志排查的习惯
- 先按时间窗取一次日志，再从结果里定位崩溃的起点
- 打开时间戳后与事件时间对齐，结论比只看内容可靠得多
- 聚合多副本时必须开来源前缀，分不清来源会得出错误结论
- 日志为空时先确认应用是否把输出写进了容器内文件
- 重要故障先保存日志文件，实例重建后现场就随之消失
- 把常用参数组合写进手册，减少临场漏参数的情况
把日志约定写进开发规范：统一走标准输出、统一时间戳格式、统一关键字段，排障时能省下大量对齐与猜测的时间。