2. Oracle Cloud基础设施与容器服务概览
在把应用搬上 Oracle Cloud 之前，需要先弄清楚它提供的基础设施“地基”是什么，以及容器服务在这块地基上处于什么位置。OCI（Oracle Cloud Infrastructure）的核心可以概括为三块：计算、网络、存储。容器并不是凭空运行的，它最终要落在计算实例或托管节点上，通过网络对外暴露，通过存储持久化数据。理解这三者的关系，才能理解 OKE（Oracle Container Engine for Kubernetes）和 OCIR（Oracle Cloud Infrastructure Registry）为什么这样设计、又该如何配合使用。
计算：容器最终落脚的地方
OCI 的计算服务以“实例（Instance）”为基本单位，实例由形状（Shape）决定 CPU、内存和网络能力。常见形状包括通用型（如 VM.Standard.E4/E5，基于 AMD/Intel）、弹性型（如 VM.Standard3.Flex，可自定义 OCPU 与内存比例）以及面向高性能计算的 GPU 形状。对容器场景而言，真正重要的不是单台实例多强，而是“节点池”这个概念：OKE 会把一组配置相同的实例组织成节点池，Pod 调度到这些节点上运行。
这里有一个容易混淆的点：容器里的 CPU 请求（request）和限制（limit）与节点实例的 OCPU 是两层资源。例如一个节点池使用 2 个 VM.Standard.E4.Flex 实例、每个 4 OCPU，那么该节点池总容量约 8 OCPU；若每个 Pod 请求 0.5 OCPU，理论上可容纳约 16 个 Pod（实际还要扣除系统组件占用）。规划节点池时，先算总容量，再留出系统预留，是避免“Pod 一直 Pending”的关键。
网络：决定容器能否被访问
OCI 网络的核心是 VCN（Virtual Cloud Network），它像一块可自定义的私有网络，内部再划分为若干子网（Subnet）。子网分两种：公共子网可挂公网 IP，私有子网只能通过 NAT 网关或堡垒机访问。OKE 的典型部署是：节点放在私有子网，负载均衡器放在公共子网，外部流量经负载均衡器进入集群。
安全控制由安全列表（Security List）和网络安全组（NSG）承担。NSG 更细粒度，可以按“角色”绑定到具体资源上，例如给节点 NSG 放行来自负载均衡器 NSG 的流量，而不是简单按网段开放。这种“引用另一个 NSG 作为源”的写法，比写死 IP 段更安全，也更适合节点扩缩容后 IP 变化的场景。
存储：容器数据的持久化
容器本身是无状态的，但数据库、日志、上传文件需要持久化。OCI 提供块存储（Block Volume）、文件存储（File Storage）和对象存储（Object Storage）。在 OKE 中，块存储通过 CSI 驱动以 PVC（PersistentVolumeClaim）方式挂载给 Pod，适合单节点读写的数据库类负载；文件存储支持多节点同时读写，适合共享配置或共享文件场景；对象存储则常用于镜像、备份和静态资源。
需要特别注意的是块存储的访问模式：默认 ReadWriteOnce 意味着同一时刻只能挂载到一个节点。如果多个 Pod 分散在不同节点却都想写同一块盘，就会挂载失败。这类问题在排障时经常出现，规划阶段就要按访问模式选存储类型。
容器化在云上的价值
把应用容器化后放到 OCI 上，收益主要体现在三方面。第一是一致性：镜像把运行环境固化下来，开发机、测试环境、生产环境跑的是同一个镜像，消除了“在我机器上是好的”这类问题。第二是弹性：容器启动快，配合节点池自动扩缩容，可以在流量高峰快速增加副本。第三是资源利用率：多个容器共享同一节点内核，比每个应用一台虚拟机更省资源。
但容器化不是免费的午餐。它要求团队接受镜像构建、版本管理、健康检查、日志采集等一整套工程实践。如果只是把虚拟机里的启动脚本原样塞进容器，收益会非常有限。
OKE 与 OCIR 的定位与集成
OKE 是 OCI 上的托管 Kubernetes 服务。它托管的是控制平面（API Server、etcd、调度器），用户只需为工作节点付费，控制平面由 Oracle 负责可用性和升级。OCIR 则是 OCI 上的容器镜像仓库，用来存放构建好的镜像，支持公共和私有仓库，并与 OCI 的 IAM 权限体系打通。
两者的集成方式很直接：在 OKE 集群中创建 Pod 时，镜像地址写成 OCIR 的仓库路径，例如 <region>.ocir.io/<namespace>/<repo>:<tag>。如果仓库是私有的，需要创建一个 docker-registry 类型的 Secret，内容为 OCIR 的用户名和认证令牌，然后在 Pod 的 imagePullSecrets 中引用。这样节点拉取镜像时就会带上凭证。
下面这张图把本节的关键对象和它们之间的关系梳理出来：左侧是 OCI 基础设施三要素，中间是 OKE 集群内部结构，右侧是 OCIR 与镜像拉取路径。
从图中可以看到一条清晰的链路：镜像先推送到 OCIR，OKE 节点在创建 Pod 时从 OCIR 拉取镜像，Pod 运行在节点池的实例上，网络通过 VCN 和负载均衡器对外暴露，数据通过 CSI 驱动落到块存储或文件存储。这条链路中的任何一环配置不当，都会导致部署失败或运行异常。
最后需要强调，OKE 托管的是控制平面，不是工作节点。节点的操作系统补丁、容器运行时版本、节点池的扩缩容策略，仍然需要用户自己管理。理解这一点，才能正确评估 OKE 带来的运维负担与便利之间的平衡。