Iris框架本身不提供内置Kubernetes健康探针，需自行暴露HTTP端点供K8s通过httpGet调用；因其是轻量级框架，健康检查属部署层职责，非框架内置功能。
直接说结论：Iris 框架本身不提供内置的 Kubernetes 健康探针（liveness/readiness probes），你必须自己暴露 HTTP 端点，再由 K8s 通过 httpGet 调用该端点完成探测。
为什么 Iris 没有现成的 /health 接口？
Iris 是轻量级 Web 框架，不捆绑运维语义；健康检查属于部署层契约，不是框架职责。Kubernetes 的探针只认标准 HTTP 状态码（如 200 表示就绪），它不管你是 Iris、Echo 还是 Gin——只要返回 200 + 可控响应体即可。
常见错误现象：CrashLoopBackOff 持续出现，但日志里服务明明在跑；或 readiness probe failed 导致流量进不来，实际接口完全可用——本质是没配对探针路径或逻辑太重（比如检查了未就绪的 Redis 连接）。
- 不要在
/health里做数据库连接池初始化、加载大模型权重等耗时操作 - 不要复用业务路由的中间件（如 JWT 鉴权），探针请求应绕过所有认证和日志记录
- 推荐用独立路由组，例如
app.Get("/health", healthHandler)，避免和主逻辑耦合
怎么写一个靠谱的 readiness probe handler？
readiness 探针要反映“是否能接收流量”，核心是检查依赖服务是否已就绪，而非是否存活。例如：Redis 已连上且能 SET/GET，数据库连接池非空，本地缓存已预热。
示例 handler（Go）：
func healthHandler(ctx iris.Context) {
// 快速返回，不阻塞
ctx.StatusCode(iris.StatusOK)
ctx.JSON(map[string]string{"status": "ok", "time": time.Now().UTC().Format(time.RFC3339)})
}
<p>func readinessHandler(ctx iris.Context) {
// 检查 Redis（假设已注入 client）
if err := redisClient.Ping(ctx).Err(); err != nil {
ctx.StatusCode(iris.StatusServiceUnavailable)
ctx.JSON(map[string]string{"status": "unready", "reason": "redis unreachable"})
return
}
ctx.StatusCode(iris.StatusOK)
ctx.JSON(map[string]string{"status": "ready"})
}- 务必设置超时（如
ctx.SetMaxRequestBodySize(1024)），防止探针被恶意大 Body 卡住 - 不要用
log.Print打印探针日志——高频调用会刷爆日志，改用结构化 debug 日志并限频 - 如果依赖多个后端，建议只检查最关键的 1–2 个（如 Redis + DB），避免单点故障放大
Kubernetes YAML 中怎么配 liveness 和 readiness？
关键不是路径，而是参数组合。Iris 启动后监听 :8080，但探针默认走容器网络，所以 port 必须填容器内端口（不是 NodePort 或 Service port）。
典型配置片段：
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 2-
initialDelaySeconds要大于 Iris 应用冷启动时间（尤其是加载配置、连接 DB 的耗时） -
timeoutSeconds必须小于periodSeconds，否则探针会堆积；Iris 默认无全局超时，需在 handler 内控制执行时间 - 别把
liveness和readiness路径设成同一个——liveness 应极简（只返回 200），readiness 才做依赖检查
容易被忽略的细节：优雅终止与探针协同
当 K8s 发出 SIGTERM 终止 Pod 时，Iris 默认不会等待正在处理的请求结束，可能导致探针返回 200 但后续请求 502。必须显式注册 shutdown hook，并在探针中感知“正在关闭”状态。
做法：app.RegisterDependency(iris.WithShutdownTimeout(30 * time.Second)) + 在 /health 中检查全局 shutdown flag；同时在 Deployment 中设置 terminationGracePeriodSeconds: 45，确保比 shutdown timeout 长。
最常漏掉的是：没关掉探针的自动重试行为——如果 readiness 失败 2 次就摘流量，但应用其实只慢了 1 秒，这种抖动会引发雪崩。调整 failureThreshold 和 periodSeconds 要结合真实 P95 响应时间来定，不能拍脑袋。
