Kubernetes中Ingress流量平滑滚动升级依赖Ingress Controller自动响应Endpoint变更，通过readinessProbe、terminationGracePeriodSeconds等配置保障连接不中断、健康检查持续通过。
在 Kubernetes 中，Nginx 平滑重载本身不是目标，真正需要的是 Ingress 流量的平滑滚动升级——即后端服务版本切换时，用户无感知、连接不中断、健康检查持续通过。这背后依赖的不是手动 reload nginx.conf，而是 Kubernetes 原生的声明式控制与 Ingress Controller 的动态适配能力。
核心原理：Ingress Controller 自动响应 Endpoint 变更
Ingress 资源只是路由声明，真正转发流量的是 Ingress Controller（如 ingress-nginx）。它通过监听 Service 关联的 EndpointSlice（或旧版 Endpoints）变化，自动更新内部 upstream 配置，并热重载 Nginx worker 进程，整个过程无需人工干预或触发 nginx -s reload。
- Deployment 滚动更新新 Pod 时，Kubernetes 自动将就绪（通过 readinessProbe）的新 Pod IP 加入对应 Service 的 EndpointSlice
- ingress-nginx 控制器监听到 EndpointSlice 更新事件后，立即生成新配置并平滑切换 upstream（复用 keepalive 连接，不中断长连接）
- 旧 Pod 被优雅终止（preStop hook + terminationGracePeriodSeconds），已建立连接可继续处理完请求
确保平滑的关键配置项
仅靠默认设置可能不够稳定，需显式优化以下参数：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- readinessProbe：必须配置，且 failureThreshold 和 periodSeconds 合理（例如探针间隔 5s，连续 2 次失败才摘流），避免新 Pod 尚未就绪就被加入流量
- terminationGracePeriodSeconds：设为 30–60 秒，给应用足够时间处理完存量请求再退出
-
滚动策略（rollingUpdate）：控制并发更新节奏，例如：
maxSurge: 1（最多多起 1 个新 Pod）
maxUnavailable: 0（保证始终有足额副本在线） -
ingress-nginx annotation（可选增强）：
nginx.ingress.kubernetes.io/affinity: "none"（禁用 session 亲和，避免新旧版本混用导致状态错乱）
nginx.ingress.kubernetes.io/proxy-next-upstream-tries: "3"（提升临时失败容忍度）
验证是否真正平滑的方法
不能只看 Pod 状态，要从流量层确认：
- 用
curl -v http://your-domain/healthz持续请求，观察 HTTP 状态码是否始终为 200，无 connection refused 或 timeout - 在客户端侧发起长连接（如 WebSocket 或 HTTP/2 流），升级过程中保持连接活跃不中断
- 查看 ingress-nginx Pod 日志，搜索
"upstream changed"或"reloading configuration"，确认重载日志存在但无 ERROR 级别报错 - 监控指标：对比升级前后 5xx 错误率、P99 延迟、active connections 曲线，应无明显毛刺
蓝绿或金丝雀场景下的补充说明
若需更精细控制（如 5% 流量切新版本），不应修改 Ingress 对象本身，而应：
- 用 独立 Service + 权重注解（如
nginx.ingress.kubernetes.io/canary: "true"配合 header/cookie 规则） - 或借助 Service Mesh（如 Istio） 实现基于 Header、权重、延迟的细粒度路由
- 此时 Ingress Controller 仍只做静态规则加载，动态分流由 sidecar 完成，进一步解耦
