把交易型应用从 AWS 迁到 OCI：设计隔离的 VCN（CIDR、NSG 与圣保罗的坑）

阶段 0：网络先于负载

在交易型应用的 AWS→OCI 迁移中，诱惑是先从集群开始。错了：VCN（虚拟云网络）才是地基。CIDR、子网或 NSG 的错误只在应用运行后才浮现——那时修复代价很高。我们先把整张网格设计好，隔离的，从一开始就用 OKE/ARM。

决策一：不能重叠的 CIDR

我们为 VCN 选了 10.1.0.0/20——刻意避开 10.0.0.0/16。如果将来与另一个网络对等（共存期间的 AWS，或未来的 VCN），重叠的 CIDR 会让对等变得不可能。带着未来去选范围，现在免费，以后极贵。

CIDR 是单向决策：以后更改意味着重建子网并重新编址一切。在敲下第一个 /20 之前，先想好未来的对等。

决策二：圣保罗只有一个可用域

OCI 的 SA-SAOPAULO-1 区域只有 1 个 AD。与拥有 3 个 AD 的区域不同，你不是在多个 AD 之间分散韧性——而是在单个 AD 内的 Fault Domain 之间分散。任何按多 AD 设计的人都会受挫；这里的高可用模式是面向 fault domain 的，而非面向 AD 的。

决策三：Service Gateway 在一个意外的前缀上响应

为了让内部流量在不出公网的情况下到达 OCI 服务（对象存储等），使用 Service Gateway。坑在于：在圣保罗，service CIDR 标签是 all-gru-services-in-oracle-services-network——而非 SA-SAOPAULO。把路由规则指向错误的标签会让流量干脆不路由，且没有明显报错。

# 列出该区域可用的 service CIDR 标签（找到 'gru'）
oci network service list --query "data[].{name:name,cidr:\"cidr-block\"}" --output table

# Service Gateway 的路由规则用 'all-gru-services...' 标签，而非 'SA-SAOPAULO'
oci network route-table update --rt-id ocid1.routetable.oc1..aaaaEXAMPLE \
  --route-rules '[{"destination":"all-gru-services-in-oracle-services-network",
                   "destinationType":"SERVICE_CIDR_BLOCK",
                   "networkEntityId":"ocid1.servicegateway.oc1..aaaaEXAMPLE"}]'

4 个 NSG 的矩阵

我们没有用宽泛的 Security List，而是按层使用 Network Security Group，遵循最小权限——数据库只接受来自应用 NSG 的连接：

nsg-lb    : ingress 80,443  来自 0.0.0.0/0             (公网负载均衡器)
nsg-app   : ingress 3000, 30000-32767 (NodePort),      来自 nsg-lb
            10250 (kubelet)            来自 VCN 内部
nsg-wp    : ingress 2028 (自定义 SSH), 9100 (Prometheus) 来自运维 IP
nsg-db    : ingress 3306              仅来自 nsg-app/nsg-wp   (无 0.0.0.0/0)

NSG 引用 NSG（源 = 另一个 NSG，而非 CIDR）正是让网格抗变更的原因：扩展应用无需为新范围重新打开数据库。

额外：在 ARM 节点上跑不起来的 amd64 镜像

OKE 集群是 ARM（Ampere）。原本在 ECS 上运行的镜像是仅 amd64 的（task definition 里 runtimePlatform 为空）。在 ARM 节点上，Pod 以 exec format error 进入 CrashLoopBackOff。修复是做多架构重建——从 x86 迁到 Ampere 时反复出现的话题：

docker buildx build --platform linux/arm64 -t registry.example.com/myapp/app:arm64 --push .

经验教训

1. 在任何负载之前设计 VCN。CIDR、子网和 NSG 是地基；应用上线后再改代价高昂。

2. 带着未来对等去选 CIDR。避免与 10.0.0.0/16 重叠；今天选范围之外的 /20，明天保住对等。

3. 圣保罗 = 1 个 AD，靠 Fault Domain 提供韧性。别按多 AD 设计；在 fault domain 之间分散。

4. Service Gateway 用 'all-gru-services' 标签。指向 SA-SAOPAULO 会让流量悄无声息地无法路由。

结论

从容器开始的云迁移，是从屋顶开始。正确的网络——不重叠的 CIDR、按 fault domain 的韧性、指向正确标签的 Service Gateway、以及 4 个最小权限的 NSG——正是让迁移的其余部分变得可预测，而非一连串区域性惊吓。