平台架构先定什么

一句话总结

设计不是选择工具，而是决定允许哪些失败、保证什么。尤其要先于部署工具审查地址空间、数据所有权和故障时必须保留的容量。

为什么需要它

设想升级订单服务时，一个 Pod 一直 Pending。有人要增加节点，另一个人要把金丝雀改成蓝绿，但尚无人查看 Pod 事件和卷位置。若根因是卷的节点约束，增加 CPU 无效；若新旧版本不能同时写同一数据，仅改变流量切换方式也无效。

先写明前提：数据能否重建？新旧版本能否同时写？失去一个节点后是否仍须服务？没有答案，架构图中再多方框也产生不了恢复步骤。

工作原理

地址空间与候选节点

例如把 Pod 的 /16 按每节点 /24 分配，算术上有 256 个块。实际节点上限仍取决于 CNI、预留和集群设置，不能直接写成可运营节点数。还应检查 Service、Pod、公司网络与 VPN 地址是否重叠。CIDR 或 CNI 变更依实现可能需要迁移或重建，值得尽早调查。

Pod Pending 时，应先看调度器允许的候选节点和事件，而不是总 CPU。nodeSelector、affinity、taint/toleration、卷 topology、requests 会共同缩小候选范围。标签匹配不等于一定可调度。

kubectl get nodes --show-labels
kubectl -n team-a describe pod orders-canary
kubectl -n team-a get events --sort-by=.metadata.creationTimestamp
kubectl -n team-a get pvc

这里的 team-a 和 orders-canary 是示例名称。实际练习要替换为目标名称，并区分错误来自 scheduler，还是卷连接、挂载过程。

RWO 的 Once 并非一个 Pod

ReadWriteOnce(RWO)表示可在一个节点上读写，**同一节点的多个 Pod 可以使用同一卷。**只允许一个 Pod 的 ReadWriteOncePod(RWOP)是另一种模式，还要确认 CSI 等支持条件。即使支持 RWX，也不代表应用并发写安全。请阅读官方 PV 文档的访问模式，分别标明节点数、Pod 数和数据一致性。

观察情况	先检查	尚不能断定
两个 Pod 引用 RWO PVC	两个 Pod 所在节点与驱动限制	第二个 Pod 必然失败
在另一节点连接失败	事件、现有连接、topology	增加节点 CPU 即可解决
同一节点上两者均 Ready	应用锁、单 writer、模式兼容性	并发写也安全
改成蓝绿	预览版本写入、后台任务	只切流量即可保证单 writer

蓝绿发布不是数据访问控制。即使 Service 不发送流量，新版本的批处理也可能写入。必须设计应用单 writer、向新卷复制并验证、模式兼容性，必要时明确停机。选择取决于 RPO、RTO 和数据模型。

现场表现

订单团队需要回答两个不同问题。“新 Pod 能否启动？”由调度与卷事件回答；“新 Pod 是否应该启动？”由并发写契约与兼容性测试回答。不能通过第一个问题就跳过第二个。

设计备忘录应保留决定、前提、确认命令、失败替代方案四栏。例如在“共享 RWO”旁写明“可调度到同一节点”的前提，并另列“writer 只有一个”。这会把考试术语转化为运营判断。

下一步学习

接下来学习给租户的配额与真实容量预留有何不同。最后的测验会判断同一 RWO 在不同条件下为何结论不同。仅凭这里的阅读示例，不能声称已验证 CSI 多节点故障或数据恢复。