代码写好了，怎么稳稳上生产？Docker、K8s、CI/CD 部署全流程：多环境 + 发布策略一篇讲透-公司新闻-南京汉荣信息科技有限公司-国家信创产品省政府协议供货商、人工智能、交通、物联网、分布式存储、备份、云计算、轨道交通（行车调度、occ辅助决策、乘务派班、实训仿真、运营安全大数据分析、施工调令管理等系统）与智能交通（交通枢纽综合管控平台、智能交通信号控制系统、有轨电车信号优先系统、 TOCC综合管控平台）13912903125

传递精彩
聚焦企业，聚焦行业，聚焦客户

免费体验

当前位置：首页>新闻动态>公司新闻

代码写好了，怎么稳稳上生产？Docker、K8s、CI/CD 部署全流程：多环境 + 发布策略一篇讲透

2026-10-28　

15次浏览

容器化与镜像构建

Dockerfile

复制# Stage 1: 依赖安装FROMpython:3.12-slimASbuilderWORKDIR/appCOPYrequirements.txt. # 使用 --no-cache-dir 减少镜像体积RUNpipinstall--no-cache-dir-rrequirements.txt  # Stage 2: 运行镜像FROMpython:3.12-slim# 非 root 用户运行（安全基线）RUNadduser--system--group--no-create-homeagent WORKDIR/app# 只复制 site-packages，不复制 pip 缓存COPY--from=builder/usr/local/lib/python3.12/site-packages/usr/local/lib/python3.12/site-packages COPY--chown=agent:agent.. USERagentEXPOSE8000HEALTHCHECK--interval=30s--timeout=3s--retries=3CMDpython-c"import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]1.

多阶段构建的核心价值：最终镜像只包含运行时需要的文件，不包含构建工具、pip 缓存、源代码中的测试文件。生产镜像越小越好——越小意味着启动快、安全漏洞少、传输快。

Docker Compose（本地开发）

复制services:agent-engine:build: ./agent-engineports: ["8000:8000"]env_file: .env.devvolumes:      - ./agent-engine:/app# 热重载depends_on:redis: { condition: service_healthy }postgres: { condition: service_healthy }deploy:resources:limits: { cpus: "1.0", memory: "2G" }worker:build: ./agent-enginecommand: python -m workerenv_file: .env.devdepends_on:redis: { condition: service_healthy }redis:image: redis:7-alpinehealthcheck:test: ["CMD", "redis-cli", "ping"]interval: 5spostgres:image: postgres:16-alpineenvironment:POSTGRES_DB: agentPOSTGRES_PASSWORD: dev_passwordvolumes:      - pgdata:/var/lib/postgresql/datahealthcheck:test: ["CMD", "pg_isready"]interval: 5s1.

开发环境的 volumes 映射让代码改动即时生效，不需要重新构建镜像——但生产环境绝不用 volumes 挂载代码。开发和生产的环境差异通过 env_file 注入。

Kubernetes 部署

核心 Manifest

复制# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: agent-enginenamespace: prodspec:replicas: 3strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 0# 更新期间保持全部可用selector:matchLabels:app: agent-enginetemplate:metadata:labels:app: agent-enginespec:containers:      - name: agent-engineimage: registry.example.com/agent-engine:1.2.0ports:        - containerPort: 8000protocol: TCPenvFrom:        - configMapRef:name: agent-config        - secretRef:name: agent-secretsresources:requests:cpu: "1"memory: "2Gi"limits:cpu: "2"memory: "4Gi"livenessProbe:httpGet:path: /healthport: 8000initialDelaySeconds: 10periodSeconds: 15readinessProbe:httpGet:path: /healthport: 8000initialDelaySeconds: 5periodSeconds: 101.

水平自动扩缩 (HPA)

复制# hpa.yamlapiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata:name: agent-engine-hpanamespace: prodspec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: agent-engineminReplicas: 3maxReplicas: 20metrics:  - type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 70  - type: Resourceresource:name: memorytarget:type: UtilizationaverageUtilization: 801.

HPA 基于 CPU/内存使用率自动扩缩。Agent 引擎是 CPU 密集型（LLM 调用是 IO 密集型，但 prompt 处理和响应解析是 CPU 密集型），CPU 用 70% 作为扩缩阈值是合理的起点。

关键依赖的部署策略

组件	部署方式	高可用策略
Agent 引擎	Deployment + HPA	多副本
Redis	StatefulSet + 哨兵	主从 + 哨兵切换
PostgreSQL	StatefulSet + WAL	PITR 恢复
消息队列	StatefulSet	集群 + 镜像队列

Agent 引擎本身无状态，用 Deployment + HPA 即可。有状态组件（Redis、PostgreSQL）用 StatefulSet。

部署拓扑图

图：负载均衡→多实例→基础设施→外部API 完整拓扑

CI/CD 流水线

GitHub Actions 示例

复制name: Agent CI/CDon:push:branches: [main, develop]pull_request:branches: [main]jobs:# Stage 1: 代码质量lint-and-test:runs-on: ubuntu-lateststeps:      - uses: actions/checkout@v4      - run: make lint# ruff / mypy      - run: make test# pytest      - run: make security-scan# trivy / bandit# Stage 2: 评测evaluation:needs: lint-and-testruns-on: ubuntu-lateststeps:      - uses: actions/checkout@v4      - run: make eval-smoke# 空跑评测（10 分钟）      - run: make eval-component# 组件评测（30 分钟）env:LLM_API_KEY: ${{ secrets.LLM_API_KEY }}      - name: Check resultsrun: |if [ $(cat eval-report.json | jq '.tsr_delta > 0.02') = "true" ]; thenecho "TSR 下降超过 2%，阻断合并"exit 1fi# Stage 3: 构建镜像build:needs: evaluationruns-on: ubuntu-lateststeps:      - uses: actions/checkout@v4      - run: |docker build -t registry.example.com/agent-engine:${{ github.sha }} .docker push registry.example.com/agent-engine:${{ github.sha }}# Stage 4: 部署 stagingdeploy-staging:needs: buildruns-on: ubuntu-latestenvironment: stagingsteps:      - run: kubectl set image deployment/agent-engine gent-engine=registry.example.com/agent-engine:${{ github.sha }} --namespace staging      - run: make eval-e2e-staging# 端到端评测# Stage 5: 部署生产（仅 main 分支）deploy-production:needs: deploy-stagingif: github.ref == 'refs/heads/main'runs-on: ubuntu-latestenvironment: productionsteps:      - run: kubectl set image deployment/agent-engine gent-engine=registry.example.com/agent-engine:${{ github.sha }} --namespace prod      - run: kubectl rollout status deployment/agent-engine --namespace prod --timeout=5m1.

这个流水线的设计核心是门禁逐步收紧。代码检查是最浅的门禁（几分钟），评测级是最重要的门禁（阻断 TSR 下降），staging 部署后的端到端评测是最终门禁。任何一道门禁不过，代码都不会进生产。

评测阻断的精度问题

Agent 评测有随机性——同样的代码跑两次可能 TSR 差 1%。直接把"TSR 下降"作为阻断条件会导致大量的误阻断。

实践中用 3 次运行取中位数的方法：

复制defshould_block(new_tsr:float,baseline_tsr:float,threshold:float=0.02)->bool:"""连续 3 次评测中有 2 次低于基线 - 阈值时阻断"""# baseline_tsr 是过去 7 次 main 分支评测的中位数passes=sum(1forrinnew_tsrifr>=baseline_tsr-threshold)returnpasses<21.

这样单次评测的波动不会误阻断，但持续下降肯定被抓住。

图：从代码提交到流量切换——九阶段 + 三道门禁 + 回滚路径

多环境管理

环境清单

复制开发环境 (dev):   用途: 本地开发、自测   基础设施: Docker Compose   LLM: gpt-4o-mini（降级模型省成本）   外部 API: Mock  测试环境 (staging):   用途: 集成测试、产品验收   基础设施: 轻量 K8s 集群（1-2 节点）   LLM: 生产相同模型   外部 API: 测试账号  预发布 (pre-prod):   用途: 发布前最终验证   基础设施: 与生产一致（小规格）   LLM: 生产相同模型   外部 API: 正式账号（有限额度）  生产 (prod):   用途: 用户使用   基础设施: 生产 K8s 集群   LLM: 生产模型   外部 API: 正式账号1.

四种环境，越多越安全，但维护成本也越高。小团队可以只保留 dev + staging + prod。staging 的环境配置必须和生产保持一致——配置不一致的 staging 没有任何验证价值。

Git 分支与环境映射

复制main 分支 → 生产环境 (自动部署) develop 分支 → staging 环境 (自动部署) feature 分支 → 开发环境 (手动部署) hotfix 分支 → 从 main 切出 → 修复后直接合入 main1.

每个环境对应一个 Kubernetes Namespace，配置从不同的 ConfigMap 和 Secret 注入。

部署策略

滚动更新（默认）

最常用的策略，逐步替换 Pod：

复制初始: V1 × 5 Step 1: 启动 V2 × 1（maxSurge: 1） Step 2: V2 健康 → 停止 V1 × 1（maxUnavailable: 0） Step 3: 重复直到全部替换为 V2 × 51.

maxUnavailable: 0 确保更新期间所有请求都能被处理。代价是需要额外的资源运行新旧版本并存。

蓝绿部署（高风险变更）

复制蓝色: V1（当前生产） 绿色: V2（新版本）  切换: 负载均衡器流量从蓝切到绿 观察: 10-30 分钟，确认无异常 回滚: 切回蓝色1.

蓝绿部署适合 Agent 系统的 prompt 变更——prompt 改坏了可能导致任务完成率暴跌，蓝绿让你能快速切回。代价是需要双倍资源。

金丝雀发布（大版本更新）

复制V1: 95% 流量 V2: 5% 流量（观察 10 分钟）→ 25%（观察 30 分钟）→ 100%1.

金丝雀最适合验证"新版本是否稳定"。对于 Agent 系统，金丝雀还可以比较新旧版本的 TSR：

复制# 金丝雀发布期间自动比较defcompare_canary():v1_tsr=get_tsr("versinotallow=v1",duration="10m")v2_tsr=get_tsr("versinotallow=v2",duration="10m")delta=v2_tsr-v1_tsrifdelta<-0.02:# V2 TSR 比 V1 低 2%rollback()elifdelta>0.02:# V2 更好，继续放量increase_canary()else:# 无显著差异，继续观察wait()1.

自动回滚条件

复制# 自动回滚触发器autoRollback:errorRate: { threshold: 0.05, window: 5m }    # 错误率 > 5%p95Latency: { threshold: 10s, window: 5m }     # P95 延迟 > 10staskSuccessRate: { threshold: 0.05, window: 5m } # TSR 下降 > 5%healthCheck: { consecutive: 3 }                # 健康检查连续 3 次失败1.

任何一个条件触发，自动回滚到上一个版本。

配置与密钥管理

环境变量分层

复制classConfig:def__init__(self):# 1. 默认值（最低优先级）self.llm_model="gpt-4o-mini"self.max_steps=10# 2. 环境变量覆盖self.llm_model=os.getenv("LLM_MODEL",self.llm_model)self.max_steps=int(os.getenv("MAX_STEPS",self.max_steps))# 3. 配置文件覆盖（可选）config_file=os.getenv("CONFIG_FILE")ifconfig_fileandos.path.exists(config_file):withopen(config_file)asf:file_config=yaml.safe_load(f)self.__dict__.update(file_config)# 4. 密钥管理服务覆盖（最高优先级）secret=os.getenv("SECRET_STORE")ifsecret=="vault":vault_config=self._load_from_vault()self.__dict__.update(vault_config)1.

密钥管理

类别	示例	存储方式
LLM API Key	OpenAI / Anthropic / Claude Key	密钥管理服务 (Vault / AWS Secrets Manager)
数据库密码	PostgreSQL 密码	密钥管理服务
JWT Secret	Token 签名密钥	密钥管理服务
非敏感配置	模型名、日志级别、超时时间	ConfigMap / 环境变量

密钥管理的基本原则：

不提交到 Git。.env 文件在 .gitignore 中，密钥管理服务的访问凭证通过环境变量注入。

不同环境不同密钥。开发环境的 API Key 和生产环境的 API Key 不同。开发用测试额度，生产用正式额度。

轮换自动化。密钥定期轮换（建议 90 天），轮换过程不能影响服务。用双 Buffer 模式：

复制classKeyManager:def__init__(self):self.current_key=self._load_key("current")self.next_key=self._load_key("next")# 预加载下一个 keydefget_key(self)->str:returnself.current_keydefrotate(self):"""切换到预加载的下一个 key"""self.current_key=self.next_keyself.next_key=self._load_key("new")1.

总结

部署方案决定了 Agent 系统的稳定性和发布效率：

汉荣云原生统一管理平台：容器化（多阶段构建 + 非 root + HEALTHCHECK）→ K8s 部署（Deployment + HPA + ConfigMap/Secret）→ CI/CD（代码检查 → 评测门禁 → 构建 → staging → 生产）→ 多环境（dev/staging/pre-prod/prod 配置一致）→ 部署策略（滚动/蓝绿/金丝雀）+ 自动回滚条件 → 密钥管理（不分环境 + 不提交 Git + 自动化轮换）。

上一篇：“AI 时代你还在用 Java 的 LangGraph4J 不切到 Python 吗？”我笑了：“Codex+Claude Code 啥语言不行？Agent根本不在乎。”

下一篇：没有了！