Iris 应用在 Kubernetes 中稳定运行的关键是适配云原生契约：需实现 readiness/liveness 探针、监听 SIGTERM 优雅关闭、配置通过环境变量或 ConfigMap 注入、采用多阶段构建精简镜像，并在 Deployment 中设置资源限制与探针参数。
Iris 是 Go 语言的高性能 Web 框架，本身不依赖 Kubernetes，但要让它在 K8s 中稳定运行，关键不是“怎么上”，而是怎么适配云原生运行时契约。直接把本地跑通的 Iris 二进制扔进 Pod 很可能失败——不是框架问题，是缺失容器化、声明式、可观测性等基础契约。
确保 Iris 应用满足 K8s 最小生命周期契约
K8s 不关心你用什么框架，只认 readiness/liveness 探针、信号处理、无状态设计。常见错误：应用启动后立刻响应 HTTP，但数据库连接未就绪，Probe 就把 Pod 干掉了。
必须做这几件事：
-
Iris启动时禁用默认 panic recovery（或重写），避免掩盖初始化失败 - 暴露
/healthz和/readyz端点，前者检查进程存活，后者检查 DB/Redis 等依赖连通性 - 监听
SIGTERM，收到后停止接受新请求、等待正在处理的请求完成（用iris.Shutdown()或手动控制http.Server.Shutdown()） - 所有配置通过环境变量或
ConfigMap注入，不要硬编码端口、DB 地址
Dockerfile 要精简且明确暴露端口
很多 Iris 示例用 FROM golang:alpine 编译再运行，这会把整个 Go 工具链打进镜像，体积大、有安全风险。
推荐多阶段构建：
FROM golang:1.23-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o iris-app . <p>FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /app/iris-app . EXPOSE 8080 CMD ["./iris-app"]
注意：EXPOSE 只是文档作用，真正生效的是 Service 定义；但漏掉它会导致 IDE 或 linter 报 warning，且容易忽略端口一致性。
K8s Deployment 必须设置资源限制和探针
Iris 启动快、内存占用低，但没限制就等于没保护。OOMKilled 是最常被忽视的 Pod 非正常退出原因。
Deployment 片段示例（关键字段不能少）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: iris-api
spec:
replicas: 2
template:
spec:
containers:
- name: app
image: your-registry/iris-api:v1.2
ports:
- containerPort: 8080
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 30
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3特别注意：initialDelaySeconds 要大于应用冷启动时间；failureThreshold 设为 3 是为了防偶发网络抖动误杀。
Service + Ingress 配置别绕开 K8s 网络模型
有人图省事，在Iris 里直接调用 net.Listen 绑定 0.0.0.0:80，再用 HostNetwork 模式部署——这等于放弃 K8s 的 Service 发现、负载均衡、NetworkPolicy 等全部能力。
正确做法：
- 应用只监听
localhost:8080（或:8080，K8s 默认绑定到所有接口） - 用 ClusterIP Service 暴露内部流量
- 对外暴露走 Ingress（如 Nginx Ingress Controller），不要用 NodePort 除非调试需要
- 如果需要 TLS 终止，用
Ingress的tls字段或cert-manager自动签发，别在Iris里硬编码证书路径
Ingress 示例中，host 和 path 必须与 Iris 路由前缀对齐，否则 404 不是框架问题，是路由错配。
真正卡住人的地方，往往不是 Iris 怎么写路由，而是它在 K8s 里“不知道自己该听谁的”——比如 ConfigMap 更新了，应用没 reload；或者日志全打 stdout 却没接 sidecar 收集；又或者用了本地缓存，跨 Pod 不一致。这些不是框架缺陷，是没对齐云原生的基本假设。
