企业 Kubernetes 平台交付与故障验收项目
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
本文缩写（英文全称与中文含义）
| 缩写 | 英文全称／名称 | 中文含义 |
|---|---|---|
| ACK | Acknowledgement | 消息或数据接收确认 |
| API | Application Programming Interface | 应用程序编程接口 |
| CD | Continuous Delivery / Continuous Deployment | 持续交付／持续部署；是否自动上线取决于流程 |
| CI | Continuous Integration | 持续集成 |
| CLI | Command-Line Interface | 命令行接口 |
| CNI | Container Network Interface | 容器网络接口 |
| CRD | Custom Resource Definition | Kubernetes 自定义资源定义 |
| CSI | Container Storage Interface | 容器存储接口 |
| DLQ | Dead-Letter Queue | 死信队列 |
| DNS | Domain Name System | 域名系统 |
| EKS | Elastic Kubernetes Service | AWS 托管 Kubernetes 服务 |
| ESO | External Secrets Operator | 将外部秘密系统中的值同步到 Kubernetes 的控制器 |
| GitOps | GitOps | 以 Git 保存期望状态、由自动化持续协调实际状态的运维方式 |
| GKE | Google Kubernetes Engine | Google 托管 Kubernetes 服务 |
| HPA | Horizontal Pod Autoscaler | Pod 水平自动扩缩容器 |
| HTTP | Hypertext Transfer Protocol | 超文本传输协议 |
| ID | Identifier | 标识符 |
| IP | Internet Protocol | 网际协议；IP 地址是网络寻址标识 |
| LB | Load Balancer | 负载均衡器 |
| PDB | Pod Disruption Budget | Pod 中断预算，约束自愿驱逐 |
| RBAC | Role-Based Access Control | 基于角色的访问控制 |
| RPO | Recovery Point Objective | 恢复点目标，可接受的数据丢失时间范围 |
| RPS | Requests Per Second | 每秒请求数 |
| RTO | Recovery Time Objective | 恢复时间目标，可接受的恢复耗时 |
| SA | Service Account | 服务账号，供程序或工作负载使用的身份 |
| SIGTERM | Termination Signal | 请求进程正常终止的信号 |
| SLO | Service Level Objective | 服务等级目标 |
| SQS | Simple Queue Service | AWS 消息队列服务 |
| TLS | Transport Layer Security | 传输层安全协议 |
交付目标：把真实订单 API/worker 部署到可重建、可审计、可恢复的平台，并证明发布/节点故障不会造成业务数据错误。使用已有真实业务镜像；本文提供平台整合与业务验收脚本，不把 Hello World 当企业项目。预算至少包括两个隔离集群或按需恢复集群、数据库/队列、LB、日志和备份存储。
1. 固定项目输入与仓库#
完成 实践约定与 业务基线。指定平台、业务、数据库、安全各一名负责人；固定 Git commit、镜像 digest、组件兼容矩阵、SLO/RPO/RTO与停止线。
platform-delivery/
infrastructure/ # 集群、网络、云角色；独立 state/部署流程
platform/ # CRD、插件、namespace、RBAC、策略、Secret 引用
applications/orders/ # API、worker、Service、HPA/PDB、监控
overlays/staging/ # 集群专属地址/身份，不含 Secret 值
overlays/recovery/ # 隔离依赖与临时域名
tests/ # 业务 API/幂等/对账
evidence/CHANGE_ID/ # 脱敏验收、版本和恢复水位Worker 必须实现暂停拉取、在途任务完成/续租和失败重投；Kubernetes 的退出等待不会自动替业务完成这些协议。
基础设施与 Kubernetes provider 分层，避免 Terraform 循环依赖。应用只引用平台输出，不能让建集群反过来依赖集群内业务资源。
2. 建集群与平台底座#
逐步执行以下独立文章，每项验收完成再下一项：
| 顺序 | 执行文档 | 本阶段交付 |
|---|---|---|
| 1 | kubeadm / EKS / GKE 三选一 | 私网 API、至少三业务节点、可重建基础设施 |
| 2 | 权限、安全 | 人员短期身份、业务 SA、拒绝测试和审计 |
| 3 | 网络、CSI | 跨节点访问、隔离策略、存储与 IP 容量 |
| 4 | ESO、证书、Gateway | 私有依赖凭据、TLS 业务入口 |
| 5 | 监控、日志、追踪 | 按请求 ID 定位业务链路、告警与值班入口 |
| 6 | Argo CD 或 Flux | 受限 GitOps、固定 revision、回退路径 |
按平台选择托管能力；不在 GKE 强装另一套 CNI，也不同时让 Argo/Flux 管理相同对象。需要自管消息服务时使用 RabbitMQ，已有 SQS/Pub/Sub 则复用业务架构。
3. 部署真实 API 与 worker#
按 Kustomize渲染实际 orders 清单；worker 需要专用 SA、专属 Secret、真实 ACK/重试/DLQ、SIGTERM 处理及队列监控。API 用 HTTP 探针，worker 使用业务提供的健康接口/命令，不能复制 API 探针制造重启循环。
下载 worker 清单，加入应用 Kustomization 的 resources，替换镜像 digest。它要求镜像提供 /app/worker 和 /app/healthcheck startup|ready|live（成功返回 0）；orders-worker-runtime 由 ESO 创建。live 只判断进程/事件循环，不因队列短暂故障失败。worker 必须自己暂停拉取消息，readiness=false 不会自动停止消费。 云队列访问给该 SA 单独配置联合身份。
kubectl kustomize overlays/staging > staging-rendered.yaml
kubectl --context="$LAB_CONTEXT" apply --dry-run=server -f staging-rendered.yaml
kubectl --context="$LAB_CONTEXT" diff -f staging-rendered.yaml
# 经 GitOps 同步；首次独立实验可 apply，之后只保留一个管理者。
kubectl --context="$LAB_CONTEXT" -n orders rollout status deployment/orders-api --timeout=10m
kubectl --context="$LAB_CONTEXT" -n orders rollout status deployment/orders-worker --timeout=10m
kubectl --context="$LAB_CONTEXT" -n orders get pods,svc,pdb,hpa,pvc确认实际域名/TLS→Gateway→API→数据库→队列→worker→结果链路。入口权限、SA 权限和网络策略做正反向验证后，才跑写入压测。
4. 执行业务门禁#
下载 k6 脚本和 请求样例 到 tests。契约：POST /orders 接受 Idempotency-Key，返回字符串 id；GET /orders/:id 返回相同 id。按真实 API 修改契约/状态码/请求体，使用合成账户与库存、隔离支付端点。这不是供生产任意接口直接运行的脚本。
通过企业密钥系统把短期业务 token 写到本机 0600 文件；不放 CLI 参数或 Git。启动 k6：
export BASE_URL='https://orders.staging.example.com'
export RUN_ID="$CHANGE_ID-$(date -u +%Y%m%dT%H%M%SZ)"
export TOKEN_FILE='/secure/orders-test-token'
export PAYLOAD_FILE="$PWD/tests/payload.example.json"
export RATE=5
export DURATION=2m
k6 run --summary-export "$EVIDENCE/k6-summary.json" tests/orders.k6.jsRATE 是每秒业务迭代数，每轮包含创建、幂等重放、查询三个 HTTP 请求，不是总 RPS。先低流量验证，再按真实容量逐步增加；示例 p95<300ms/错误率<0.1% 是需团队确认的门槛。checks 配了 threshold，失败会使退出码非零；仅输出 check 不会自动阻断 CI。
本脚本只验证 API 正确性/幂等，不证明 worker 最终完成。再按 client_reference 的 RUN_ID 前缀对账：唯一订单数、确认消息数、成功处理数、DLQ、业务金额/库存差异。待异步窗口结束仍未完成视为失败；保存脱敏统计，不输出 token/客户数据。
5. 变更与故障矩阵#
持续运行上述流量，每次只注入一个故障，恢复稳定再下一项：
| 场景 | 操作入口 | 必须通过 |
|---|---|---|
| 非法身份/未签镜像 | 权限、供应链 | 拒绝新访问/部署，旧业务保持正常 |
| 发布错误版本 | 蓝绿 | preview 门禁失败不晋级，旧 active 正常 |
| 单节点维护 | 调度 | PDB/容量有效，业务满足 SLO |
| 镜像/调度故障 | 排障 | 告警触发、证据能定位、恢复无数据错误 |
| 密钥轮换 | ESO | 新凭据生效，旧凭据按窗口撤销 |
| 数据恢复/集群故障 | Velero、多集群 | 隔离恢复、数据对账、RPO/RTO达标 |
| 平台升级 | 自建 / EKS / GKE | API/插件/数据兼容，逐阶段有停止点 |
插件健康和业务健康分别记录；故障后 Running 并不意味着积压/对账已恢复。
6. 交付与清理#
验收记录至少包含：环境/版本/commit/digest、负载与样本量、错误率/p95/p99、权限拒绝证据、告警时间、恢复步骤、数据水位、实际 RPO/RTO、剩余风险与负责人。未执行的格子写“未验证”，不得写通过。
清理按 RUN_ID 用业务批准的清理/冲正流程处理测试数据，保持审计与会计一致；脚本不自动 DELETE 订单。回收临时恢复环境前保留外部备份、镜像、日志，检查孤立 LB、卷、DNS 与云费用。交付结果是可重放的 Git 仓库和证据，不是一次 kubectl 成功截图。
参考：k6 门槛与退出码。
可直接运行的配套工程#
可直接使用 企业订单参考工程 提供的 API/worker、完整 Helm/Kustomize 与并发幂等验收。该实现使用数据库事务队列；外部 broker 演练仍按相应文档选择适配。