在 Kubernetes 中优雅地管理 ConfigMap 热更新
最近在生产环境中遇到一个问题:修改 ConfigMap 后,Pod 内的应用并不会自动感知到变化。虽然 Kubernetes 会在一定时间后更新挂载的文件,但应用本身需要有 reload 机制才行。
常见的做法有几种:使用 inotify 监听文件变化、利用 Reloader 控制器自动触发滚动更新、或者在应用内部实现配置轮询。本文对比了这三种方案的优劣,并给出了我们最终采用的方案。
最近在生产环境中遇到一个问题:修改 ConfigMap 后,Pod 内的应用并不会自动感知到变化。虽然 Kubernetes 会在一定时间后更新挂载的文件,但应用本身需要有 reload 机制才行。
常见的做法有几种:使用 inotify 监听文件变化、利用 Reloader 控制器自动触发滚动更新、或者在应用内部实现配置轮询。本文对比了这三种方案的优劣,并给出了我们最终采用的方案。
在 Go 项目中,context.Context 几乎无处不在,但很多人并没有正确地使用它。最常见的错误是在 struct 中存储 context,这违反了官方的设计建议。
另一个经典陷阱是 goroutine 泄漏:当你启动一个 goroutine 处理请求,但忘记传入可取消的 context,即使客户端已经断开连接,后端仍然在执行不必要的计算。
func handleRequest(ctx context.Context) {
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
result, err := slowQuery(ctx)
// ...
}
阅读全文 →
自从 Redis 修改了开源协议,我们团队一直在评估替代方案。DragonflyDB 兼容 Redis 协议,但在多线程架构上做了很大改进,实际压测中在高并发场景下吞吐量提升了约 3 倍。
迁移过程中遇到了一些兼容性问题,主要集中在 Lua 脚本和某些冷门命令上。本文记录了整个迁移过程、踩过的坑,以及最终的性能对比数据。
阅读全文 →传统的服务网格方案(如 Istio)通过 sidecar 代理实现流量观测,但这带来了不可忽视的性能开销和运维复杂度。借助 eBPF,我们可以在内核层直接捕获网络流量元数据,无需修改任何应用代码。
本文介绍了如何使用 Cilium 的 Hubble 组件搭建一套轻量级的服务间调用拓扑观测系统,实测资源开销仅为 Istio 方案的 1/5。
阅读全文 →每次换电脑或者新同事入职,配开发环境都是一场噩梦。Docker 解决了运行时的问题,但开发时的工具链(编译器版本、linter 配置、系统依赖)仍然很难统一。
Nix Flakes 提供了一种声明式的方式来定义开发环境。一个 flake.nix 文件就能确保所有人用的工具版本完全一致,而且不会污染系统全局环境。