Deployment滚动更新由spec.template变更自动触发：控制器比对期望与实际状态，一旦Pod模板（如镜像、环境变量）变化，即创建新ReplicaSet并按maxSurge/maxUnavailable策略逐步替换旧Pod，全程需正确配置readinessProbe以确保流量平滑切换。
滚动部署在 Kubernetes 中不是“手动执行”的操作，而是 Deployment 控制器根据 Pod 模板变更自动触发的协调过程；只要你改了 spec.template（比如镜像、环境变量、启动参数），Kubernetes 就会按策略逐步替换旧 Pod —— 但前提是配置得当，否则可能卡住、中断流量或扩缩失控。
Deployment 的滚动更新是如何被触发的
Deployment 本身不轮询或监听变化，它依赖控制器循环比对当前状态与期望状态。只要 spec.template 字段发生任何结构性变更（哪怕只是加了一个空格或改了注释），就会生成一个新的 ReplicaSet，并开始滚动过程。
-
kubectl set image deployment/my-app container-name=new-image:v1.2是最常用触发方式，它本质是 patch 更新spec.template.spec.containers[*].image - 直接
kubectl apply -f deploy.yaml也能触发，但必须确保 YAML 文件中spec.template确实有变更；GitOps 工具如 Argo CD 也是靠检测 Git 中该字段差异来驱动 - 注意：
metadata.annotations或spec.replicas变更不会触发滚动更新，只会扩缩或打标，这点常被误认为“更新没生效”
为什么新 Pod 启动了却收不到流量？
根本原因通常是缺失或配置错误的 readinessProbe。Service 的 endpoints 列表由 EndpointSlice 控制器维护，它只把通过 readiness 探针的 Pod 加入列表 —— 即使 Pod 状态是 Running，若探针未就绪，就不会被路由流量。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- HTTP 探针示例：
readinessProbe.httpGet.path必须返回 HTTP 200，且路径要真实存在（比如/healthz而非/） -
initialDelaySeconds要大于应用实际冷启动耗时，否则探针过早失败会导致 Pod 反复重启 - 避免用
exec探针调外部命令（如curl），它依赖容器内工具链，增加不可控性 - 没配探针时，Pod 一进入
Running状态就被加入 endpoints，极易导致 5xx 请求 —— 这是生产环境最常见“零停机”失效原因
maxSurge 和 maxUnavailable 怎么设才不翻车
这两个参数控制滚动节奏，直接影响可用性与资源开销。默认值 maxSurge=25%、maxUnavailable=25% 对多数场景偏保守，但盲目调高可能引发雪崩。
- 若应用内存敏感（如 Java 应用），
maxSurge设太高会导致节点资源瞬时超卖，触发 OOMKilled；建议先压测单 Pod 资源占用，再反推安全并发数 - 对于强一致性服务（如订单写入），
maxUnavailable=0可保副本不减，但要求至少有 1 个额外 Pod 容量（即maxSurge > 0），否则滚动会卡住 - 设
maxSurge=0意味着“先删后建”，等效于 Recreate 策略，完全失去滚动意义；除非你明确接受短暂中断 - 线上建议用整数而非百分比（如
maxSurge: 1），避免副本数少时计算结果为 0（例如 replicas=2 时 25% = 0.5 → 向下取整为 0）
滚动中怎么确认是否真正完成
别只看 kubectl get deploy 显示 AVAILABLE，那只是副本数达标；真正要验证的是：所有新 Pod 就绪、旧 ReplicaSet 已缩容为 0、且 Service 流量已全部切走。
- 检查新 RS：运行
kubectl get rs -l app=my-app，确认只有一个 RS 的DESIRED等于副本数，其余 RS 的CURRENT为 0 - 确认旧 Pod 彻底消失：
kubectl get pods -l app=my-app --show-labels | grep -v new-pod-hash，应无输出 - 观察 endpoint：运行
kubectl get endpoints my-app -o wide，IP 列应全是新 Pod 的 IP，且数量匹配 - 关键陷阱：
kubectl rollout status默认只等 Pod Ready，不校验 probe 成功率或业务指标；高风险发布建议配合curl -f http://service/health做 post-rollout 验证
滚动部署真正的复杂点不在“怎么起新 Pod”，而在于如何让新旧 Pod 在生命周期交叠期互不干扰 —— 探针配置、连接优雅关闭、下游重试机制、以及监控能否及时捕获 5xx 上升趋势，这些才是决定一次发布成败的关键。Kubernetes 只提供机制，不保证语义正确性。
