client-go 可实时拉取 pod 日志，需调用 /api/v1/namespaces/{ns}/pods/{name}/log 流式接口，关键配置 follow=true、taillines=0，并用 bufio.scanner 按行读取；多 pod 场景需并发控制、加 context 超时、统一日志前缀及正确关闭流。
Go 程序调用 client-go 实时拉取 Pod 日志
直接用 client-go 调 Kubernetes API 获取日志，本质是复现 kubectl logs -f 的行为——它底层走的是 /api/v1/namespaces/{ns}/pods/{name}/log 这个 streaming endpoint。关键不是“能不能”，而是“怎么避免卡住或丢日志”。
必须显式设置 Follow=true 和 TailLines=0（否则默认只返回最后 10 行），并用 bufio.Scanner 按行读取流，不能用 io.ReadAll 一次性吞：
req := clientset.CoreV1().Pods("default").GetLogs("my-pod", &corev1.PodLogOptions{
Container: "app",
Follow: true,
TailLines: 0,
})
readCloser, err := req.Stream(context.TODO())
if err != nil {
panic(err)
}
scanner := bufio.NewScanner(readCloser)
for scanner.Scan() {
fmt.Println(scanner.Text()) // 实时输出
}
- 不设
Follow=true就不是实时，只是快照 -
TailLines=0才能从头开始流；设成正数会跳过前面内容 - 务必用
scanner.Scan()，否则流可能被缓冲阻塞，甚至连接超时断开 - 如果 Pod 有多个容器，
Container字段必须指定，否则报container not specified
多 Pod 日志聚合场景下该怎么做
想同时看一个 Deployment 下所有 Pod 的日志？client-go 不支持原生批量拉取，得自己轮询 + 并发控制。别直接起 goroutine 死循环拉，容易打爆 API Server。
推荐做法：先用 List() 拿到当前匹配的 Pod 列表，再对每个 Pod 启一个带 context timeout 的日志流 goroutine，并统一用 sync.WaitGroup 管理生命周期：
- 每次
List()后重新比对 Pod 名称，避免重复启动已终止的流 - 给每个流加
context.WithTimeout(ctx, 30*time.Second)，防止某个 Pod 崩溃后流卡死 - 日志行前缀加上
[pod-name/container]，否则根本分不清哪行是谁打的 - 不要用
fmt.Printf直接输出——并发写 stdout 可能乱序，至少用log.Printf或加锁
为什么不用 kubectl logs --since=1m | grep error 这种方式
因为你在 Go 里没法可靠地 exec.Command("kubectl", "logs", ...) 并实时消费 stdout：子进程退出时机不可控、信号传递复杂、权限依赖宿主机环境、且 --since 在旧版 kubectl 中不支持流式模式。
真正需要程序内集成时，唯一健壮路径就是走 client-go 的 streaming 接口。其他方式全是临时 workaround：
-
exec.Command在容器内跑会失败——没装 kubectl，也没 kubeconfig 权限 - 用
os/exec管道解析日志，遇到换行符在中间截断（比如 Java stack trace）就彻底错位 - 本地开发调试可以接受 shell 方式，但上线服务必须用 client-go
容易被忽略的上下文与清理问题
最常漏掉的是流关闭和 context 取消。没关 readCloser 会导致连接泄漏；没 cancel context 会让 goroutine 永远挂起，哪怕 Pod 已删。
正确姿势是把日志流封装成结构体，实现 Close() 方法：
type LogStream struct {
reader io.ReadCloser
cancel context.CancelFunc
}
func (l *LogStream) Close() {
l.reader.Close()
l.cancel()
}
实际使用时，defer stream.Close() 是底线。Kubernetes 日志流没有心跳保活，长时间空闲会被 apiserver 断连——你得监听 scanner.Err() 并做重连判断，而不是假设一次 Stream() 能撑一整天。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
