直接回滚可行但需前置配置：必须启用--record记录版本且设置revisionhistorylimit（默认10，建议5–15），否则历史replicaset被gc清理后无法回滚；回滚本质是触发新一轮滚动更新，非倒带。
直接回滚是可行的，但必须在部署前就启用版本历史记录，否则kubectl rollout undo会失败或回滚到错误状态。
Deployment 必须配置 revisionHistoryLimit
默认情况下，Kubernetes 只保留最近 10 次 Deployment 的历史版本（即 ReplicaSet），但如果你没显式设置，某些集群或旧版 kubectl 可能只存 2–5 个。一旦旧 ReplicaSet 被 GC 清理，就无法回滚。
- 在
Deployment的spec中添加：revisionHistoryLimit: 10（建议设为 5–15，视发布频率而定） - 该字段控制保留多少个旧 ReplicaSet 对象，每个对应一次镜像变更
- 不设置或设为 0 会导致
kubectl rollout history deployment/<name></name>显示空或仅当前版本 - 修改后需用
kubectl apply更新 Deployment，不会触发滚动更新
回滚前先确认可用版本列表
执行 kubectl rollout history deployment/go-app，输出类似：
REVISION CHANGE-CAUSE 1 kubectl set image deployment/go-app go-app=your-registry/go-app:v1.0 --record=true 2 kubectl set image deployment/go-app go-app=your-registry/go-app:v1.1 --record=true 3 kubectl apply --filename=deploy.yaml --record=true
注意：CHANGE-CAUSE 列为空时，说明没加 --record=true，此时只能靠 REVISION 编号和创建时间判断版本，容易误操作。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 务必在每次
kubectl set image或kubectl apply时加上--record=true - 如果漏了，可手动 patch 注解：
kubectl annotate deployment/go-app kubernetes.io/change-cause="v1.0.2 fix panic" --overwrite - 用
kubectl rollout history deployment/go-app --revision=2查看某次的具体镜像与参数
执行回滚并验证 Pod 状态
回滚本质是让 Deployment 控制器把 spec.template.spec.containers[].image 改回旧值，并触发新一轮滚动更新 —— 不是“倒带”，而是另一次正向发布。
- 回滚到上一版本：
kubectl rollout undo deployment/go-app - 回滚到指定 revision：
kubectl rollout undo deployment/go-app --to-revision=1 - 执行后立即检查：
kubectl get replicaset -l app=go-app，应看到新旧 ReplicaSet 副本数动态变化 - 等
kubectl rollout status deployment/go-app返回 success 后，再验证 Pod 的镜像：kubectl get pod -l app=go-app -o jsonpath='{.items[*].spec.containers[*].image}'
容易被忽略的终止信号处理问题
回滚过程会删除旧 Pod，Kubernetes 发送 SIGTERM，但 Go 应用若没捕获，可能正在处理请求时被强制 kill，造成连接中断或数据不一致。
- 必须在 Go 主程序中监听
syscall.SIGTERM和syscall.SIGINT - 收到信号后，调用
http.Server.Shutdown()并等待活跃连接关闭（建议设30scontext timeout） - 避免在
main()结尾直接os.Exit(0)，这会跳过 cleanup - 配合 readinessProbe 设置
initialDelaySeconds和periodSeconds，确保新 Pod 真正 ready 后才切走流量
回滚不是“一键还原”，它依赖 Deployment 的历史快照、镜像仓库中对应 tag 的长期可用性，以及应用自身的优雅终止能力。三者缺一不可。
