从一次 K8s Controller OOM 聊起:彻底搞懂 Go GMP 调度模型
不讲干巴巴的八股文。从一个真实的 Kubernetes controller 内存暴涨 + 延迟飙高的线上事故出发,用 pprof 数据倒推 GMP 调度模型的每个概念,让你理解为什么要学这些东西。
不讲干巴巴的八股文。从一个真实的 Kubernetes controller 内存暴涨 + 延迟飙高的线上事故出发,用 pprof 数据倒推 GMP 调度模型的每个概念,让你理解为什么要学这些东西。
生产环境的 K8s controller 突然 fatal error: concurrent map read and map write 崩溃退出,不是 panic,recover 也救不了。从这个事故出发,搞清楚 map 的并发问题、遍历随机性、delete 不缩容等实战中真正会踩的坑。
一个 K8s admission webhook 在高峰期频繁超时,但单个请求处理逻辑明明很快。问题出在 channel 的使用方式上。从这个事故出发,拆解 channel 的底层结构、发送接收流程、select 实现,以及那些年我们踩过的 channel 坑。
一个 K8s admission webhook 上线后内存持续增长,pprof 显示大量 timer 泄漏。根因是 context.WithTimeout 的 cancel 函数没有被调用。从这个事故出发,拆解 context 的树状传播机制、四种派生函数、最佳实践与常见陷阱。
一个 K8s operator 在高负载下频繁 fatal crash:concurrent map read and map write。问题不在逻辑,在于共享状态的保护方式。从这个事故出发,拆解 Mutex 的正常/饥饿模式、RWMutex 的读写协调、WaitGroup 的计数器陷阱、Once 的 double-checking,以及 sync.Map 的双 map 架构。