kubectl logs 是什么
kubectl logs 读取容器标准输出与标准错误的日志。数据来自 kubelet 在节点上落盘的容器运行时日志文件，命令通过 API Server 把请求转发到对应节点的 kubelet，因此不用登录节点，也不要求容器内装有任何排查工具。启动参数写错、依赖连不上、代码抛异常，这些线索都会先出现在这里。
能看与不能看
它只能看到容器主进程写到标准输出与标准错误的内容。应用把日志写进容器内的文件、或者直接写进数据库与远端日志服务时，kubectl logs 会是空的。这种情况下要么进容器读文件，要么依赖集中式日志采集。日志文件本身也会被 kubelet 轮转，超过保留上限的历史内容会消失。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，需要 pods 与 pods/log 权限 |
|---|---|
| 语法 | kubectl logs <pod> [-c 容器] [选项] |
| 数据来源 | kubelet 落盘的容器运行时日志文件 |
| 前提条件 | Pod 已调度到节点，且目标容器至少启动过一次 |
| 输出内容 | 容器主进程的标准输出与标准错误，不含文件日志 |
| 保留策略 | 由 kubelet 控制轮转，超出上限的旧日志会被删除 |
典型使用场景
- 应用起不来：看进程第一屏输出，定位配置缺失、端口占用或依赖不可达
- 接口报错排查：用 -f 跟随实时输出，一边复现请求一边看异常堆栈
- 发布后验证：确认新版本启动日志里没有连接池、数据库迁移或探针相关报错
- 多容器 Pod：用 -c 只看业务容器，避开代理类边车容器刷屏
- 按标签聚合：一次抓一组 Pod 的日志，区分是普遍故障还是单个实例异常
- 重启后取证：加 --previous 读上一个已终止实例的日志，崩溃现场往往在这里
- 限流排查：配合 --since 与 --timestamps 对齐监控告警时间点，看当时发生了什么
常用示例
常用示例
kubectl logs web-7d9c8b6f5c-abcde # 单容器 Pod 直接读日志
kubectl logs web-7d9c8b6f5c-abcde -c istio-proxy # 指定容器，避开边车噪声
kubectl logs -f --tail=100 web-7d9c8b6f5c-abcde # 先给最后 100 行，再持续跟踪
kubectl logs --since=30m --timestamps web-x # 只看半小时内并带时间戳
kubectl logs web-x --previous --tail=200 # 读上一个已终止实例的日志
kubectl logs -l app=web --all-containers=true --max-log-requests=10 # 按标签聚合
kubectl logs deploy/web --tail=50 # 直接按负载名取，自动挑一个 Pod常用选项对照
| 选项 | 作用 | 典型用途 |
|---|---|---|
| --tail=N | 只输出末尾 N 行 | 日志量大的容器先看最近内容 |
| -f | 持续跟踪新增输出 | 边复现问题边观察 |
| --since=30m | 只看某个时间点之后的日志 | 和故障发生时间对齐 |
| --timestamps | 每行前置时间戳 | 给日志排序、与监控时间线对照 |
| --previous | 读上一个终止实例的日志 | 崩溃重启后取现场 |
| -l | 按标签选择多个 Pod | 判断故障范围是个例还是普遍 |
排查配合动作
- 先用 get 确认重启次数，再决定读当前实例还是上一个实例
- 日志里的报错时间和 describe 的事件时间对齐，能快速锁定是启动期还是运行期
- 多副本都报同样的错，优先怀疑配置与依赖；只有一个副本报错，优先怀疑节点与该实例
Pod 只有一个容器时 -c 可省略；多容器而不指定会直接报错，并在提示里列出可选容器名。
容器日志由 kubelet 轮转（默认单文件约 10Mi、保留数份），超过上限的旧日志会被删除，长期留存必须依赖日志采集系统。
应用若在日志里输出多行堆栈，按行读取会显得散乱，可在输出里搜索关键字，或配合 --tail 只看关键片段。