企业自建容器云的选型材料，翻开来大多在比同一批东西：控制台好不好用、有没有 CI/CD 流水线、应用商店里有多少个 Helm Chart、支不支持服务网格。

这些能力当然有价值，但它们都在 Kubernetes 之上。而 K8s 本身是标准的——各家发行版在核心调度能力上的差异，远小于选型表给人的印象。

真正决定两年后运维成本的，是 Kubernetes 之下 的四个问题：

• 容器节点从哪来？谁负责扩容？

• 应用要持久卷，存储从哪儿给？

• 容器里的服务要访问虚拟机上的数据库，网络怎么通？

• 出了故障，运维要开几个控制台才能定位？

这四个问题的答案，取决于容器平台和企业现有虚拟化资源池之间是什么关系。

一、“融合”是所有人都在说的话，但融合有深浅

几乎每家厂商的容器云方案都会提到与虚拟化底座的关系，但表述的落点各不相同：

这五种表述落在完全不同的层次上。“共用资源”、“共享存储与网络”、“扩展授权模块”、“跨基础设施纳管”——单看每一句都合理，放在一起才看得出它们承诺的不是同一件事。

但融合是分层次的，每深一层，就少一类运维负担：

选型时值得做的一件事，是把候选方案的宣传语按这五层对号入座——“共用资源”通常指 L1 到 L2，“深度集成”要问清楚是否包含 L3 和 L4。

二、五条路径的基本形态

独立自建路径和其余四条的分野最明显：Rancher Prime 提供的是跨基础设施的 K8s 管理能力，它不假设底下跑的是什么，也因此不负责底下的事。SUSE 官方对其定位的表述是解决跨任意基础设施管理多个 Kubernetes 集群的运维与安全挑战——管理集群，不管理集群之下的资源供给。

这不是缺点，是产品边界。选择这条路径意味着企业自己承担 L1 到 L4 的全部工作。

本节结论：已有成熟的基础设施团队、且需要同时纳管多云与边缘集群的企业，独立自建路径的灵活度更高。 基础设施团队规模有限、希望容器资源供给自动化的企业，应优先看依托现有虚拟化底座的路径。

三、维度一：容器节点从哪来

新华三那一行有一条容易漏算的：如果容器集群跑在裸金属上，除容器服务授权外还需要配置裸金属资源授权。这在做成本测算时要单独列出来。

本维度结论：开发团队频繁申请测试集群、集群生命周期短的场景，节点能否由平台自动供给决定了基础设施团队的日常负担。 需要确认三件事：创建一个新集群需要多久、加节点是否需要人工介入、以及集群销毁后资源是否自动回收。

四、维度二：持久化存储由谁提供

有状态应用是容器云落地的分水岭。无状态服务怎么部署都行，一旦要跑数据库、消息队列、对象存储，持久卷的供给方式就决定了架构。

独立自建路径在这一维度的实际工作量最容易被低估：要么额外部署一套分布式存储并自行承担其运维，要么对接现有存储阵列的 CSI 驱动并自行验证兼容性与性能。这部分工作不出现在任何一份 K8s 选型表里，但它会实实在在占用团队时间。

本维度结论：计划在容器上跑有状态应用的企业，应把持久卷供给方式列为一级维度。 询价时要问清：持久卷是否由平台存储直接提供、是否需要额外采购存储授权、以及快照与备份能力是否覆盖容器卷。

五、维度三：容器网络与虚拟机网络是否同平面

这是融合深度里差距最大、也最少被问到的一项。

现实中的应用架构极少是纯容器的。典型形态是：新开发的微服务跑在容器里，而它依赖的数据库、中间件、老系统仍然跑在虚拟机上。这条调用链每天要走无数次。

如果容器网络和虚拟机网络不在同一个平面内，打通的方式通常是 NodePort、Ingress 或额外的网关设备——链路多一跳，安全策略要在两套系统里各配一遍，排障时要跨两个网络视图看。

本维度结论：应用架构中存在容器服务调用虚拟机上数据库或中间件的场景时，网络是否同平面直接决定了链路复杂度与安全策略的维护成本。 这一项无法从宣传页判断，建议在 POC 中直接验证：起一个容器 Pod，直接 ping 同环境下虚拟机的内网 IP，看是否需要额外配置。

六、维度四：控制台与告警的数量

多套系统各自为政，是私有云运维里最消耗人力的一类问题：故障发生时要在虚拟化控制台、K8s Dashboard、存储管理界面、监控系统之间来回切换才能定位根因；合规审计时要分别导出日志再人工关联。

这里要区分两种“统一”：统一纳管多个 K8s 集群，和统一纳管虚拟机与容器。前者解决的是集群多的问题，后者解决的是技术栈多的问题。企业的实际痛点往往是后者——运维团队要同时看虚拟机和容器，而不是要看几十个 K8s 集群。

本维度结论：基础设施团队人数少于 5 人的企业，控制台数量是一个真实的成本变量。 选型时要问清：虚拟机与容器是否在同一界面、告警是否进同一个中心、RBAC 与审计日志是否统一。

七、维度五：授权计量方式

延续基础设施采购的通用问题——容器平台的授权怎么算，直接影响扩容成本。

按宿主机或节点计量的方案，扩容成本随节点数线性增长；作为平台内置模块提供的，则要确认容器能力是否随平台授权一并覆盖，还是需要单独采购。这两种结构在三节点起步时差异不大，在几十节点规模上差距会明显放大。

本维度结论：测算容器平台成本时，要把三年后的目标节点数代入计算，而不是只算首期。 同时要确认：容器平台授权与虚拟化平台授权是否独立计算、开发测试集群是否占用正式授权额度。

八、维度六：信创架构支持

信创场景下容器平台有一个特殊问题：镜像的架构。 x86 环境下现成可用的容器镜像，在 ARM 或其他国产架构上需要对应架构的版本。这不是平台能力问题，是生态问题，但它会实实在在影响项目周期。选型时应要求供应商说明其应用市场中的镜像对国产架构的覆盖情况。

本维度结论：信创环境下的容器云选型，平台支持国产架构只是及格线，要额外确认应用镜像的架构覆盖与构建流程。

九、维度七：Kubernetes 之上的能力

这一节放在最后，是因为它是各家差距最小的一块。

这张表放在这里，是为了说明一件事：在 Kubernetes 之上，各家的能力清单高度趋同，且这些能力大多可以后补。 今天没有服务网格，明年可以加；流水线不好用，可以换一套外部工具。

本维度结论：这一层的能力差异不应主导选型决策，但有两项值得单独确认——镜像仓库是否支持离线环境同步，以及应用市场的镜像是否覆盖目标 CPU 架构。 这两项在信创和涉密环境下会直接影响项目周期。

十、四类企业的选型结论

十一、容器云的八项询价核对

第 3 条建议坚持要求实测。容器与虚拟机网络互通这件事，各家的文档表述差异很大，而一次 Pod 到虚拟机 IP 的 ping 测试，能在五分钟内得到确定答案。

十二、选型之前值得想清楚的事

容器云这个品类，选型材料的重心长期偏在 Kubernetes 之上的能力——流水线、应用商店、微服务治理。这些能力的差异是真实的，但它们大多可以后补：今天没有服务网格，明年可以加；今天流水线简陋，可以换一套。

而 Kubernetes 之下的选择很难后补。节点怎么来、存储怎么给、网络怎么通，这三件事一旦定下来，改动意味着重建集群、迁移数据、重新设计网络策略。

所以选型顺序值得倒过来：先把第十一节里的第 1 到第 4 条问清楚，再去比控制台好不好看。

那八个问题建议原样发给每一家候选供应商，其中第 3 条和第 4 条尽量在 POC 环境里实测，而不是看文档。

资料来源

• ZStack：ZStack ZCF 官方产品文档与产品规格说明

• 深信服：深信服官网云原生平台产品页、超融合承载容器云方案页、超融合业务承载页

• 新华三：H3C 官网 CloudOS 7.0 云操作系统 License 支持情况说明

• 华为：以华为官方产品文档为准，本次评测未获取到完整的公开容器服务技术文档

• SUSE Rancher Prime：SUSE 官方文档站 Rancher Manager 产品说明、SUSE 官网云原生解决方案页

以上均查证于 2026 年 8 月。各厂商产品能力与授权政策随版本迭代变化，最终以各厂商当前官方文档与实际 POC 结果为准。