应使用--audit-webhook-config-file实现go程序实时处理，因--audit-log-path仅写文件无法实时消费；需配置审计策略、webhook服务及正确解析v1.event结构。
怎么拿到K8s audit log流？用kube-apiserver的--audit-log-path还是--audit-webhook-config-file？
K8s audit log默认不输出到stdout，必须显式配置。直接写文件（--audit-log-path=/var/log/kube-apiserver-audit.log）最简单，但无法实时消费；想用Go程序实时处理，得走Webhook——否则你的http.Server收不到任何东西。
- 文件模式适合离线分析，但Go程序要轮询+tail，容易丢事件、重复读、权限受限
- Webhook模式要求你先写好接收端（HTTP handler），再通过
--audit-webhook-config-file指向它，且kube-apiserver必须能网络连通该服务 - Webhook配置里
batchMaxSize和throttleQPS直接影响日志延迟：设太大，单次POST体积膨胀；设太小，QPS压不上去，日志堆积在apiserver内存队列里
apiVersion: v1
kind: Config
clusters:
- cluster:
server: http://your-go-service:8080/audit
name: audit-webhook
contexts:
- context:
cluster: audit-webhook
name: default-context
current-context: default-context
Go里怎么解析audit log的JSON结构？别直接json.Unmarshal进map[string]interface{}
K8s audit log是严格schema的，但字段多、嵌套深、部分字段可选（比如requestObject只在create/update时存在）。用泛型map解码，后面取user.username或objectRef.namespace时全是类型断言+panic风险。
- 官方提供了Go struct定义：
k8s.io/apiserver/pkg/apis/audit/v1里的Event，必须用它——不是第三方包，是k8s.io/apiserver源码里的 - 要注意版本对齐：
v1对应K8s 1.16+，老集群用v1beta1，混用会导致Unknown field错误 -
requestObject和responseObject是runtime.RawExtension，不能直接当map用；需二次解码，比如判断objectRef.resource == "pods"后再json.Unmarshal进v1.Pod
示例关键段：
var event auditv1.Event
if err := json.Unmarshal(rawBody, &event); err != nil {
// 处理解码失败，不是所有字段都必填，但顶层结构必须对
}
if event.RequestObject != nil {
var pod corev1.Pod
if err := event.RequestObject.Unmarshal(&pod); err == nil {
// 确实是个Pod请求
}
}
为什么你的Go服务收不到audit event？检查这三处硬性限制
Webhook不是“发了就完”，K8s apiserver有强校验逻辑，挂掉一个环节整个链路静默：
立即学习“go语言免费学习笔记（深入）”；
-
kube-apiserver启动参数必须含--audit-policy-file，且策略文件里至少有一条level: Metadata或更高——空策略或全None等于没开审计 - Webhook服务返回非2xx状态码（比如503），apiserver会退避重试，但默认只试2次，之后丢弃；看
kube-apiserver日志里有没有Failed to process event: failed to send audit event to webhook - Go服务监听地址必须是HTTP（非HTTPS），除非你在webhook config里配了
insecureSkipTLSVerify: true；但生产环境别跳过证书校验，否则apiserver拒绝连接
快速验证是否通路：
curl -X POST http://your-go-service:8080/audit \
-H "Content-Type: application/json" \
-d '{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata"}'
如果这个能收到，说明服务层OK；如果收不到，问题在K8s配置侧。
高并发下audit log处理卡住？别在handler里做耗时操作
Audit log量级直接受集群规模和操作频率影响：一个中等集群每秒可能产生几十条event，AdmissionReview类操作还会触发多次audit。Go handler里如果同步调ES、写磁盘、加锁查DB，立刻成为瓶颈。
- HTTP handler函数必须轻量：只做解析 + 提取关键字段（如
user.username、verb、objectRef） + 发送到channel或消息队列 - 别用
log.Printf打全量event，JSON序列化本身就有开销；调试时用fmt.Sprintf("%s %s %s", e.User.Username, e.Verb, e.ObjectRef.Resource)就够了 - 如果用channel传递，记得buffer size匹配预期吞吐，比如
make(chan *auditv1.Event, 1000)；无缓冲channel在峰值时直接阻塞handler
真正耗时的分析（比如规则匹配、聚合统计）应该放在后台goroutine里做，和HTTP接收解耦。
K8s audit event的stage字段（RequestReceived/ResponseComplete）常被忽略，但它决定了你看到的是请求前快照还是响应后结果——删资源时，ResponseComplete阶段才能看到responseObject里的finalizers是否已清空。 
