iris框架无内置kubernetes探针支持，需手动实现：livenessprobe用轻量路由返回200，readinessprobe用带超时依赖检查的/readyz并失败时返回503，startupprobe应单独设无外部依赖的/startupz。
直接给结论： Iris 框架本身不内置 Kubernetes 探针语义，但你可以用普通路由 + 简单 HTTP 处理器模拟 livenessProbe 和 readinessProbe 行为；关键不是“Iris 怎么支持探针”，而是“如何让 Iris 路由返回符合 Kubernetes 期望的 HTTP 状态码和响应时机”。
怎么写一个符合 Kubernetes livenessProbe 要求的路由
Kubernetes 默认把 HTTP 状态码 2xx 或 3xx 视为成功，4xx/5xx 视为失败。所以你不需要额外封装，只要确保路由逻辑快、无副作用、不依赖外部服务（如 DB 连接）即可。
-
livenessProbe应该只检查进程是否存活：比如返回200 OK，不查数据库、不调远程服务 - 推荐用
ctx.StatusCode(200)显式设状态码，避免框架默认行为干扰 - 不要在 handler 里加
time.Sleep或阻塞 IO，否则会触发failureThreshold导致误重启 - 示例：
app.Get("/healthz", func(ctx iris.Context) {
ctx.StatusCode(200)
ctx.WriteString("ok")
})
怎么写 readinessProbe 对应的路由（带依赖检查）
readinessProbe 的核心是“能否收流量”，意味着它要验证应用是否真正就绪——比如 DB 是否连通、缓存是否可用、配置是否加载完成。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 别把所有依赖都塞进一个
/readyz，按实际瓶颈拆：DB 连接单独 check，Redis 单独 check，避免单点失败拖垮整个就绪判断 - 每个依赖检查必须设超时（如
context.WithTimeout），否则 Pod 可能卡在Running但长期不 Ready - HTTP 状态码建议：全部通过返回
200，任一失败返回503 Service Unavailable（Kubernetes 会自动从 Service Endpoints 移除该 Pod） - 示例（伪代码）：
app.Get("/readyz", func(ctx iris.Context) {
dbOK := checkDBConnection(ctx)
redisOK := checkRedisConnection(ctx)
if !dbOK || !redisOK {
ctx.StatusCode(503)
ctx.JSON(map[string]bool{"db": dbOK, "redis": redisOK})
return
}
ctx.StatusCode(200)
ctx.WriteString("ready")
})
为什么 startupProbe 不能简单复用 /healthz 或 /readyz
Kubernetes 的 startupProbe 是为了容忍慢启动应用（比如 JVM 初始化、大模型加载），它会在容器启动后先跑 startup 检查，等成功后才启用 liveness/readiness。如果你直接复用已有路由，可能造成两个问题：
- startupProbe 配置了
failureThreshold: 30，但你的/readyz依赖 DB，而 DB 启动慢于 Pod —— 此时 startupProbe 会反复失败直到阈值触达，Pod 直接被 kill - startupProbe 成功后，livenessProbe 立刻开始执行，但此时你的业务逻辑可能还没完全初始化（比如某些全局 sync.Once 未跑完）
- 正确做法：单独开一个轻量路由，比如
/startupz，只检查进程内标志位或文件是否存在（如os.Stat("/tmp/app-initialized")），不碰任何外部依赖
容易被忽略的细节：响应头和路径前缀
Kubernetes 探针对响应体内容不敏感，但对响应头和路径很敏感：
- 别在健康检查路由里加
ctx.Header("Content-Type", "...")，除非你明确需要；多数情况下空 Content-Type 也没问题 - 如果用了
iris.WrapRouter或反向代理（如 Nginx），确保路径没被重写 —— 比如 Kubernetes 配置的是path: /healthz，但 Nginx 把它转成了/api/v1/healthz，那探针永远 404 - 路径必须完全匹配：Kubernetes 不会自动补尾部斜杠，
path: /healthz和app.Get("/healthz/", ...)是两个不同路由 - 测试时用
curl -v http://localhost:8080/healthz直接验证，别只信浏览器访问结果（浏览器可能缓存或自动跳转）
