零停机发布需部署策略、基础设施与应用可观测性协同配合；python应用须显式设计健康检查端点（如/healthz）、分层构建docker镜像、合理配置kubernetes滚动更新参数（如maxunavailable: 0），并在ci/cd中验证真实流量路径下的服务就绪状态。
零停机发布不是靠单个脚本或命令实现的，而是依赖部署策略、基础设施配合与应用自身可观察性共同作用的结果。Python Web应用本身不自带“零停机”能力，必须在CI/CD流程中显式设计支撑机制。
健康检查端点必须暴露且可靠
Kubernetes 或负载均衡器依赖/healthz（或类似路径）判断实例是否就绪。如果应用没提供，或者返回逻辑有误（比如数据库连接失败时仍返回 200），滚动更新会跳过等待直接杀掉旧 Pod，造成请求中断。
-
readiness probe应只检查本地服务状态（如 HTTP 可达、事件循环活跃），不要包含下游依赖（DB、Redis） -
liveness probe可检查更深层状态，但失败后会重启容器，需避免误判 - 示例 Flask 健康端点应这样写：
from flask import Flask app = Flask(__name__)
@app.route('/healthz') def health(): return {'status': 'ok'}, 200
- 不要返回
500或超时 —— 这会让 Kubernetes 认为实例不可用，触发不必要的驱逐
Docker 镜像构建必须分层且最小化
CI 流程中构建镜像若每次都重装全部依赖，会导致镜像体积膨胀、推送耗时、拉取慢，间接拉长滚动更新窗口，增加并发旧/新实例的时间差。-
COPY requirements.txt .必须放在COPY . .之前，利用 Docker 缓存加速 - 使用
--no-cache-dir和--user安装依赖（避免 root 权限和缓存污染） - 生产镜像建议用
python:3.10-slim而非python:3.10，减少攻击面和体积 - 不要在
Dockerfile中RUN pip install -r requirements.txt后再COPY app.py—— 这样每次代码变更都会重做 pip 安装
Kubernetes 部署配置要启用滚动更新并设合理参数
单纯用kubectl apply 默认是滚动更新，但默认参数（如 maxSurge=25%, maxUnavailable=25%）在小规模 Deployment（比如只有 2 个副本）下极易导致瞬间不可用。
- 显式设置
strategy.rollingUpdate.maxSurge和maxUnavailable，例如：strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0
-
maxUnavailable: 0确保旧 Pod 不销毁，直到新 Pod 通过readinessProbe - 同时设置足够长的
readinessProbe.initialDelaySeconds（比如 10–15 秒），给 Python 应用（尤其带 ORM 初始化的）留出启动时间 - 如果用
gunicorn，注意--preload会影响 readiness 检查时机 —— 预加载可能让进程提前就绪，但实际 worker 还没 ready
CI/CD 流水线里不能跳过验证环节
很多团队在 GitHub Actions 或 GitLab CI 中只跑单元测试就推镜像上线，这是高危操作。零停机的前提是新版本能真正接管流量，而不仅是“能启动”。- 流水线必须包含：构建镜像 → 推送 registry → 在测试环境部署 → 发起真实 HTTP 请求验证
/healthz和关键业务接口（如/api/v1/status） - 验证失败应中断流水线，而不是静默忽略
- 不要用
curl -f @#@#@#@#@#@#@#@#@#@0 || exit 1这类本地检查 —— 它绕过了 Service、Ingress、Probe 等真实路径，毫无意义 - 推荐做法：部署到 staging namespace 后，用
kubectl wait --for=condition=available等待 Deployment 就绪，再发 curl 到 ClusterIP Service
真正的难点不在写几行 Python 或 YAML，而在于把应用启动行为、探针语义、K8s 调度节奏、CI 验证深度这四者对齐。任何一个环节松动，zero-downtime 就只剩字面意思。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
