健康检查接口不能直接调用 Kubernetes API，因 /healthz 是内部端点且默认不暴露，频繁直连会触发限流；应封装带缓存的轻量接口，用 time.AfterFunc 和 sync.RWMutex 实现低开销、线程安全的 10–30 秒缓存。
健康检查接口为什么不能直接调用 Kubernetes API
因为 kube-apiserver 的 /healthz 是集群内部端点，且默认不暴露给外部；更关键的是，频繁直连会触发限流（429 Too Many Requests），尤其在高频率探针场景下。所以得自己封装一层带缓存的轻量接口，避免每次请求都穿透到 API Server。
用 time.AfterFunc + 全局变量实现低开销缓存
不需要引入 Redis 或内存库——Kubernetes 健康检查本质是“最终一致”型需求，缓存 10–30 秒完全可接受。重点是避免 goroutine 泄漏和并发写冲突。
- 用
sync.RWMutex保护缓存值读写，读多写少场景下比sync.Mutex更高效 - 缓存更新用
time.AfterFunc而非time.Ticker：避免 ticker 持有引用导致 GC 不回收，也防止重启后多个 ticker 累积 - 首次请求触发预热（lazy init），避免服务刚启动时所有探针同时打到 API Server
示例片段：
var (
mu sync.RWMutex
cacheData struct {
Status string `json:"status"`
At time.Time `json:"at"`
}
)
func refreshCache() {
// 实际调用 clientset.CoreV1().Nodes().List(...)
// 省略 error 处理，失败时保留旧值
mu.Lock()
cacheData = struct{ Status string; At time.Time }{
Status: "ok",
At: time.Now(),
}
mu.Unlock()
}
// 启动时立即刷新一次，再设 15s 后刷新
refreshCache()
time.AfterFunc(15*time.Second, refreshCache)
http.HandlerFunc 中如何安全读取缓存并响应
HTTP handler 必须无阻塞、低延迟（Kubernetes 默认超时是 1 秒）。不能在 handler 里做任何网络调用或加写锁。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只用
mu.RLock()读取，立刻释放 - 响应状态码必须严格匹配 Kubernetes 探针要求：成功返回
200，失败返回非2xx（如503），否则 kubelet 会误判为就绪 - 别加额外 header（如
X-Cache-Age），某些旧版 kubelet 会因未知 header 拒绝解析响应
handler 示例：
func healthzHandler(w http.ResponseWriter, r *http.Request) {
mu.RLock()
data := cacheData
mu.RUnlock()
w.Header().Set("Content-Type", "application/json")
if time.Since(data.At) > 30*time.Second {
w.WriteHeader(http.StatusServiceUnavailable)
json.NewEncoder(w).Encode(map[string]string{"error": "stale cache"})
return
}
w.WriteHeader(http.StatusOK)
json.NewEncoder(w).Encode(map[string]interface{}{
"status": data.Status,
"cached_at": data.At.UTC().Format(time.RFC3339),
})
}
部署时要注意的 Pod 配置细节
即使代码逻辑正确，Kubernetes 层配置错误也会让缓存失效或引发误杀。
-
livenessProbe和readinessProbe的periodSeconds必须大于缓存刷新周期（比如缓存 15s 刷新，probe 至少设为 20s），否则 probe 总是拿到过期数据 - 禁用
initialDelaySeconds以外的所有重试（即不设failureThreshold> 1），因为缓存冷启动期间可能短暂不可用，重试会放大抖动 - 如果容器启用了
securityContext.readOnlyRootFilesystem: true，确保没写临时文件——本方案不依赖磁盘，这点刚好兼容
典型 probe 片段：
readinessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 20
timeoutSeconds: 2
failureThreshold: 1
缓存机制真正起效的前提，是你清楚知道「健康」对你的服务意味着什么——是节点 Ready？是某个关键 Deployment 有足够副本？还是 etcd 连通性？这些语义必须由你定义，缓存只是把判断结果稳住几秒而已。别让它掩盖了真实问题。
