滚动更新卡在“Waiting for rollout to finish”是因为Kubernetes需等待所有新Pod就绪且旧Pod完全终止，而Golang服务若未正确实现readinessProbe、未优雅处理SIGTERM或terminationGracePeriodSeconds过短，就会阻塞进度。
滚动更新为什么卡在 Waiting for rollout to finish
因为 Kubernetes 默认等待所有新 Pod 进入 Ready 状态，并且旧 Pod 完全终止后才认为 rollout 成功。如果 Golang 服务没正确响应就绪探针（livenessProbe 或 readinessProbe），或者没处理 SIGTERM 信号导致优雅退出超时，就会卡住。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保 Golang HTTP 服务暴露
/healthz或类似端点，并在readinessProbe中配置httpGet调用它；不要只依赖端口连通性（tcpSocket） - 在 main 函数中监听
os.Signal，收到syscall.SIGTERM后关闭 HTTP server 并等待活跃请求完成（例如用srv.Shutdown(ctx)） - 设置合理的
terminationGracePeriodSeconds（默认 30s），若业务清理耗时长，需显式调大，否则 Pod 可能被强制 kill，触发重试或连接中断 -
readinessProbe的initialDelaySeconds应大于服务启动耗时，避免新 Pod 被过早加入 Service 导致 5xx
rollingUpdate 策略里 maxSurge 和 maxUnavailable 怎么设才不丢请求
这两个参数控制更新节奏：前者决定最多额外创建几个 Pod，后者决定最多允许几个 Pod 不可用。设错会导致流量抖动甚至 503。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对有状态或强一致性要求的服务，优先设
maxUnavailable: 0，靠maxSurge: 1实现“先扩后缩”，确保任何时候至少有一个旧 Pod 在服务中 - 若集群资源紧张，可设
maxSurge: 25%+maxUnavailable: 25%，但必须配合足够快的就绪探针（periodSeconds: 2）和短超时（timeoutSeconds: 1） - 绝对不要设
maxUnavailable: 100%（即滚动更新退化为重建），除非你确认服务完全无流量或已切走 - Golang 服务启动慢（比如加载配置、初始化 DB 连接池）时，
maxSurge不宜过大，否则大量 Pod 同时启动可能打爆下游依赖（如数据库连接数）
更新时出现 CrashLoopBackOff 却看不到日志？
Kubernetes 会快速重启失败 Pod，导致 kubectl logs 拿不到崩溃前的日志。Golang 二进制若 panic 未捕获、或 init 阶段出错，容器就直接退出。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 加一层 shell wrapper 启动命令，比如
sh -c 'exec /app/server >& /dev/stdout'，避免 stdout/stderr 被重定向丢失 - 在 Golang 主函数开头加
log.SetOutput(os.Stdout)，禁用默认文件输出；panic 前用log.Fatal显式输出错误 - 用
kubectl describe pod <name>查Events区域，重点关注FailedMount、ErrImagePull、OOMKilled等非应用层错误 - 临时调试时，把镜像 CMD 改成
sleep infinity，再kubectl exec进去手动运行二进制，复现并捕获 panic stack
如何验证滚动更新真正零中断？
光看 kubectl rollout status 成功不够——它只确认 Pod 状态，不验证流量是否连续。真实场景下，DNS 缓存、kube-proxy 规则刷新延迟、客户端连接复用都可能导致短暂断连。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 更新前起一个持续 curl 的 watch 脚本：
while true; do curl -s -f http://svc/healthz || echo "$(date) FAIL"; sleep 0.1; done - 观察 Service 的 endpoints 是否平滑过渡：
kubectl get endpoints <svc-name> -w，应看到旧 IP 逐渐减少、新 IP 逐渐增加，中间无空窗 - Golang 服务里记录每个请求的
Pod UID和时间戳，结合 Prometheus 抓取http_requests_total{pod=~"old|new"}，确认新旧版本请求数无断崖 - 特别注意客户端是否启用了 HTTP keep-alive；旧连接可能复用到已终止的 Pod，表现为偶发 timeout，而非 5xx
最常被忽略的是 Golang HTTP Server 的 IdleTimeout 和 ReadTimeout 设置——它们会影响连接复用行为，在滚动更新窗口内若不匹配 kube-proxy 刷新周期（默认 1–2s），就会放大中断感知。
