Panda Research Reports/2026/
IaaS 领域扩展与产品路线图
Home

IaaS 领域扩展与产品路线图

陈兴源@panda，2026-03
基于开源生态的小微企业 IaaS 及超融合架构（HCI）产品线扩展战略调研与演进路线图1. IaaS 领域核心技术栈与基础概念深度解析1.1. 计算虚拟化：从底层硬件抽象到虚拟机管理1.2. 容器化与云原生计算：轻量级的隔离与安全防护1.3. 网络虚拟化（SDN）：解耦控制平面与数据平面1.4. 存储虚拟化：分布式文件系统与对象存储的融合1.5. IaaS 业界标准与互操作性：打破数据孤岛与供应商锁定1.6. IaaS 各种技术总结2. 业界主流 IaaS 与 HCI 软件生态及产品竞争力分析2.1. 传统企业级霸主与国产化替代的时代机遇2.2. 复杂而庞大的全栈云平台：OpenStack2.3. 简单易用的混合架构集群平台：Proxmox VE (PVE)2.4. 云原生超融合领域的颠覆性新星：Harvester2.5. 主流 IaaS 平台总结3. 小微存储团队的二次开发可行性评估与战略定位4. 迈向独立交付：分阶段企业级产品线扩展与演进路线图4.1. 阶段一：强化自身存储基座，全面推行插件化生态集成（第 1-12 个月）4.2. 阶段二：试水“存算一体”，向轻量级自主 HCI 进军（第 13-24 个月）4.3. 阶段三：云原生行业专有 HCI 解决方案的独立交付与生态破局（第 25-36 个月）引用文献

基于开源生态的小微企业 IaaS 及超融合架构（HCI）产品线扩展战略调研与演进路线图

云计算与基础设施即服务（IaaS, Infrastructure as a Service）市场正处于从传统虚拟化向云原生架构演进的深刻变革期。随着人工智能工作负载的激增以及企业对敏捷性、弹性扩展要求的提高，全球 IaaS 市场在 2024 年实现了 22.5% 的增长，整体规模达到 1718 亿美元，分布式云和混合云基础设施的需求呈现出前所未有的强劲增长态势 1。对于目前核心规模在 10 人以下、主打基于 CephFS 与 JuiceFS 二次开发的熊猫高性能分布式文件系统软件开发团队而言，其软件产品的市场和营销环境高度依赖与安超云（ArcherOS）等超融合（HCI, Hyper-converged infrastructure）厂商的生态捆绑，虽然在短期内降低了市场拓展的难度并保障了基础现金流，但从长远战略维度审视，缺乏独立的计算与网络编排能力将极大限制企业的市场前景、利润空间与品牌独立性。
本报告旨在为公司决策层提供一份详尽且深入浅出的 IaaS 领域技术生态调研。报告将从底层核心技术栈的原理出发，全面剖析业界主流软件产品的竞争格局，并结合团队现有的分布式存储核心技术壁垒，量身定制一份兼具技术前瞻性与落地可行性的分阶段产品线扩展路线图，助力企业突破单一存储供应商的局限，最终实现使团队具备一体化的基础设施云服务解决方案的独立交付与实施能力。

1. IaaS 领域核心技术栈与基础概念深度解析

为了使公司决策层能够准确评估跨入 IaaS 计算、网络与容器领域的风险与技术门槛，必须首先对这些领域的核心技术栈从专业角度进行深度解析。基础设施即服务（IaaS）的本质是“软件定义数据中心（SDDC, Software-Defined Data Center）”，其核心逻辑是通过纯软件的方式，将原本僵化、物理隔离的计算、存储、网络等硬件资源进行抽象化、池化，并根据上层业务的需求进行自动化的动态调度与分配 3。这种抽象解耦了硬件与软件的强绑定关系，是现代云计算的基石 5。

1.1. 计算虚拟化：从底层硬件抽象到虚拟机管理

计算虚拟化是传统 IaaS 平台最核心的组成部分，其根本目标是在一台裸金属物理服务器（BMS, Bare Metal Server）上并行运行多个相互完全隔离的客户操作系统（VM, Virtual Machine, 即虚拟机）。为了实现这一目标，业界发展出了多种虚拟机监控器（Hypervisor）。Hypervisor 扮演着硬件与虚拟机之间的翻译官与仲裁者角色，主要分为直接运行在裸金属硬件上的第一型（Type-1）和运行在宿主操作系统之上的第二型（Type-2） 6。
在 Linux 生态中占据绝对主导地位的技术栈是 KVM（Kernel-based Virtual Machine）。KVM是一个直接集成在 Linux 内核中的虚拟化模块 6。它的核心作用是利用现代中央处理器（CPU）提供的硬件辅助虚拟化技术（例如 Intel 的 VT-x 或 AMD 的 AMD-V 指令集，ARM64 平台的 ARMv8/v9 Virtualization 指令集），将原本普通的 Linux 内核直接转变为一个高性能的第一型虚拟机监控器 6。如果对非技术背景的人解释，可以将 KVM 理解为一座大楼的“地基与钢筋骨架”，它在最底层负责物理 CPU 和内存资源的硬性切割与隔离，确保一个虚拟机的运行情况（以及崩溃等异常故障）绝不会影响到物理机或其他虚拟机。
与 KVM 并列的其他主流内核级虚拟化技术包括微软的 Hyper-V。Hyper-V 是 Windows 生态下的第一型 Hypervisor，它同样直接控制底层硬件，启用 Hyper-V 后，Windows 宿主机(host)本身也降级为一个特权虚拟机运行 8。而在桌面级或开发测试环境中，广泛使用的是 VirtualBox / VMWare 等软件。VMWare / VirtualBox 等软件属于第二型 Hypervisor，它们依赖自行开发的 vboxdrv 等私有内核模块来获取对物理硬件的访问权限 6。由于它必须经过宿主操作系统的调度，其性能损耗远高于 KVM 或 Hyper-V，因此 vboxdrv 等技术主要用于单机软件产品，绝不会被用于企业级 IaaS 集群的底层构建。
然而，仅仅拥有 KVM 这样的底层引擎是远远不够的。KVM 本身只负责 CPU 和内存的虚拟化，它无法为虚拟机提供完整的硬件运行环境（如虚拟网卡、硬盘控制器、USB 接口及显卡等）。这就需要引入 QEMU（Quick Emulator）。QEMU 是一个强大的硬件模拟器，它在用户空间运行，负责模拟出虚拟机所需的所有外设硬件，并管理虚拟机的运行进程 6。在实际的企业级应用中，QEMU 与 KVM 是深度绑定的（业界常称为 qemu-kvm），由 KVM 负责处理极度消耗性能的 CPU 指令，而由 QEMU 负责繁杂的设备模拟 6。如果将 KVM 比作大楼的地基，QEMU 就是大楼内部的“水电管道和门窗系统”。
由于直接在命令行中操作 QEMU 参数极其复杂且容易出错，开源社区开发了 Libvirt 这一中间层管理工具及应用编程接口（API）和命令行工具 virsh 库。Libvirt 完整地屏蔽了底层 QEMU/KVM 的所有复杂细节，提供了一套标准化的接口，让上层软件可以极其简单地发出创建、启动、实时迁移和销毁虚拟机的指令 6。无论是庞大的 OpenStack，轻量化的分布式虚拟化平台 Proxmox VE，还是单机级别的虚拟机管理器（如 virt-manager, QEMU），其底层绝大多数都是通过调用 Libvirt 来对虚拟机进行生命周期管理的。

1.2. 容器化与云原生计算：轻量级的隔离与安全防护

尽管虚拟机提供了极佳的安全隔离性，但每个虚拟机都需要运行一个数百兆乃至数吉字节的完整操作系统，这带来了巨大的资源消耗和启动延迟。为了解决这一痛点，容器化技术（Containerization technology）应运而生。容器化提供了一种更为轻量级的替代方案，它允许多个应用程序共享同一个宿主机（通常是 Linux）的操作系统内核，但彼此之间在逻辑上看似完全独立 10。容器的本质并非像 KVM 那样的硬件级别虚拟化，而是 Linux 内核提供的几种核心资源管理机制的巧妙组合。
首先是 Namespaces（命名空间）技术，它负责提供“资源可见性隔离”。Linux 内核提供了多种不同类型的 Namespace，包括网络（Network）、进程号（PID）、挂载点（Mount）等资源的 namespace。处于特定 Namespace 中的进程只能看到属于该空间的资源，而对外部世界一无所知 10。以企业办公楼作比喻，Namespace 就像是每一间独立办公室的磨砂玻璃门和实心墙壁，确保里面的员工（进程）看不到、也无法直接干涉其他办公室的工作状态 12。
其次是 Cgroups（控制组）技术，它负责“资源限制与记账”。仅仅有可见性隔离是不够的，还需要防止某个失控的程序耗尽整台服务器的算力。Cgroups 能够精确限制某个进程或进程组能够使用的 CPU 核心数、内存容量以及磁盘 I/O 速度的上限 10。继续上面的比喻，Cgroups 就像是办公楼里为每间办公室独立安装的智能电表和水表，它不仅精确记录资源消耗，还能在某间办公室用电超标时直接切断电源，从而防止个别故障导致整栋大楼瘫痪 13。
为了确保容器环境的绝对安全，防止恶意程序穿透容器的隔离层控制宿主机或其它租户的容器，现代 IaaS 平台还需要依赖 SELinux（Security-Enhanced Linux）或 AppArmor 等强制访问控制（MAC）安全机制。SELinux 为系统中的每一个文件、进程和网络端口都打上了安全标签，并制定了极其严格的访问策略 11。即使某个容器内的进程获得了 root 权限，只要 SELinux 策略不允许，它依然无法读取或修改宿主机上的关键系统文件，这为多租户云计算环境提供了不可或缺的终极安全防线。
基于容器化技术的软件产品和解决方案包括 Docker、Podman、LXC（Linux Containers）等。这些产品的核心技术原理都是相同的，但在控制平面架构设计、管理运维操作方式和用户态特性上存在差异。对比如下：
对比维度
Docker
Podman
LXC (Linux Containers)
核心定位
应用容器（Application Containers）
应用容器（Application Containers）
系统容器（System/OS Containers）
架构设计
客户端-服务器架构，依赖后台守护进程（Daemon）
分支-执行架构，无守护进程（Daemonless）
直接与 Linux 内核交互（Cgroups, Namespaces）
主要应用场景
微服务架构、CI/CD 管道、单一应用打包与分发
替代 Docker，对安全性（无 Root）要求较高的环境、Kubernetes 兼容场景
轻量级虚拟机的替代品，需要运行完整 Linux 环境（如 SSH、Cron 等）的场景
权限与安全性
默认需要 Root 权限运行守护进程（虽然支持 Rootless 模式，但配置较复杂），存在守护进程单点故障和提权风险
默认且原生支持 Rootless（非特权）模式，安全性极高，没有守护进程的提权风险
支持特权和非特权（Unprivileged）容器，安全性通过内核级隔离实现
OCI 兼容性
完全兼容 OCI（Open Container Initiative）标准
完全兼容 OCI，命令行指令与 Docker 高度一致（可直接 alias docker=podman）
不使用 OCI 镜像格式，使用完整的系统镜像（类似于 OS 模板）
编排与生态
拥有 Docker Swarm 集群管理；与 Kubernetes 曾深度集成（现 K8s 已弃用 dockershim，改用 containerd）
原生支持生成和重播 Kubernetes YAML 文件（podman generate kube）；与 systemd 集成极佳
通常结合 LXD（或 Incus）进行集群和存储/网络管理；常用于 Proxmox VE 等虚拟化平台
镜像构建
依赖 Docker CLI 和 Daemon (docker build)
使用轻量级工具 Buildah 进行镜像构建，无需守护进程
通常通过 lxc-create 和分发模板拉取，而非 Dockerfile 式的层级构建
生命周期管理
由 Docker Daemon 统一管理所有容器的生命周期
由启动它的用户进程（或 systemd）管理，容器是子进程
类似于虚拟机的开机/关机，通常由 init 系统（如 systemd）在容器内部接管
网络模式
拥有完整的网络抽象（Bridge, Host, Overlay, Macvlan）
支持 CNI 和 Netavark，网络模式与 Docker 类似
基于桥接（Bridge）、Macvlan 或直接路由，支持分配独立 IP 和复杂网络拓扑
性能与开销
极低（仅应用运行开销），但 Daemon 占用少量内存
极低（仅应用运行开销），无后台进程占用，资源利用率最高
低于传统虚拟机，但略高于 Docker/Podman，因为需要运行系统级服务（如日志、定时任务等）

1.3. 网络虚拟化（SDN）：解耦控制平面与数据平面

在云计算环境中，网络配置的复杂度和变更频率远超传统数据中心。虚拟机或容器的快速创建、迁移和销毁，要求网络资源也必须像计算资源一样能够通过软件接口随时被创建和隔离。软件定义网络（SDN, Software-Defined Networking）的核心理念由此诞生：将网络的“控制平面（决定数据包的路由规则）”与“数据平面（实际搬运和转发数据包的硬件或软件）”彻底分离 5。这种解耦使得管理员可以通过集中式的软件控制器，指挥分布在成百上千台服务器上的虚拟网络设备。
在单台 Linux 服务器内部，虚拟机或容器之间的网络隔离依赖于 Linux Network Namespace 技术。每个容器拥有自己独立的 Network Namespace，其中包含独立的虚拟网卡和路由表。为了让这些孤立的命名空间能够与外界通信，Linux 提供了 veth pair（虚拟以太网对）技术。可以将其想象为一根无形的虚拟网线，一头插在容器内部的虚拟网卡上，另一头插在宿主机上的虚拟交换机上。
在虚拟交换机领域，业界最著名、部署最广泛的开源软件是 OVS（Open vSwitch）。OVS 运行在数据平面，负责在宿主机内部极其高效地根据流表（Flow Table）转发虚拟机之间的数据包 15。然而，当数据中心扩展到数十或数百台物理服务器时，手动或通过简单脚本逐台配置 OVS 的流表将成为一场灾难。为了解决分布式集群的统一网络管理问题，OVN（Open Virtual Network）项目被提出。OVN 是 OVS 的原生控制平面，它提供了一个全局视角的集中式数据库。云平台管理员只需在 OVN 中定义高层次的“逻辑交换机”和“逻辑路由器”，OVN 就会自动将这些逻辑配置翻译为底层每一台 OVS 能够理解的底层流表，并实时分发到所有计算节点上，从而实现全分布式的路由、NAT 和防火墙功能 15。
在跨物理机的网络通信中，VXLAN（Virtual eXtensible LAN）是一种处于统治地位的 Overlay（覆盖网络）网络技术。传统数据中心的二层网络（VLAN, Virtual Local Area Network）最多只能支持 4096 个隔离网段，这对于拥有海量用户的云平台环境而言来说远远不够。VXLAN 巧妙地将二层以太网数据包封装在三层 UDP 数据包中进行传输 19。这意味着，即使两台虚拟机身处不同的物理机房、跨越了无数个复杂的物理路由器，只要它们的宿主机支持 VXLAN 解封装，这两台虚拟机在逻辑上就会认为彼此连接在同一台本地交换机上。这种技术彻底打破了物理网络拓扑对云计算资源池的束缚。
随着 Kubernetes 主导云原生时代，容器网络接口（CNI, Container Network Interface）成为了网络虚拟化的新战场。在这个细分领域，目前主要有两大技术路线。其一是基于传统 BGP 路由协议和 iptables 防火墙规则的 Calico。Calico 历史悠久、极其稳定，兼容几乎所有的操作系统，是目前企业级部署的事实标准 20。其二是基于新兴 的 Linux 内核 eBPF（Extended Berkeley Packet Filter, 扩展的伯克利数据包过滤器）技术的 Cilium。Cilium 将网络控制逻辑直接注入到 Linux 内核的底层，彻底绕过了冗长且低效的 iptables / nftables 规则链，在数据包吞吐量、微服务路由性能以及应用层网络可观测性上具有压倒性的代差优势，代表了 IaaS 网络技术的未来发展方向 20。
网络虚拟化被广泛认为是计算、存储和网络这三者中最复杂、困难的虚拟化类型。计算（服务器）虚拟化已经成熟且相对而言最简单。存储虚拟化有良好的分布式系统理论基础，也有很多成熟的软件产品；虽然在工程实践上仍然具有挑战性，但主要问题在于性能调优和与旧系统的兼容性管理；总体而言，将存储视为一个“池”来管理比管理虚拟化的网络流量要容易得多。而网络虚拟化涉及抽象复杂、有状态且高度相互依赖的物理基础设施，这使得它非常难实现、管理和扩展。
网络虚拟化的复杂性主要体现在：
  • 组件紧密耦合（Tight Coupling of Components）：这与计算虚拟化不同。计算中的虚拟机通常可以独立运行，而虚拟网络则与虚拟交换机和物理网络硬件深度集成。网络任何部分的任何变化，即使是很小的变化，通常都会影响其他部分。
  • 状态复杂性（Stateful Complexity）：网络不仅仅是传输数据包；它们还涉及维护状态（路由表、防火墙规则、VLAN/VXLAN 标签等）。虚拟化这些状态，尤其是在软件定义网络 (SDN) 中，需要管理复杂的网络拓扑。
  • 性能开销（Performance Overheads）：网络功能虚拟化可能会导致严重的性能瓶颈。网络流量对延迟高度敏感，抽象层的开销会降低性能，因此需要精心规划，使用各种技术以保证整个分布式系统的网络性能。
  • 开发和运维技能差距（Operational Skill Gap）：设计、运行和维护虚拟化网络系统需要与传统网络不同的技能，要求开发、运维人员既了解虚拟网络环境，又了解底层物理网络的基础设施和技术栈。对于目前最前沿的基于 Linux eBPF 的虚拟化网络技术，还要求开发人员对 Linux 内核和基于栈的汇编语言等技术栈也非常熟悉。这些都使得整个系统的管理和运维更加困难。

1.4. 存储虚拟化：分布式文件系统与对象存储的融合

熊猫的开发团队目前对存储领域已有深厚的积累，但为了向决策层提供统一的全景视角，必须将其置于 IaaS 全局架构中进行审视。存储虚拟化的终极目标是打破单一物理磁盘的容量和性能界限，将多台服务器的硬盘资源聚合成一个可无限横向扩展的全局统一存储池 24。
在这个领域，Ceph 作为老牌的分布式存储霸主，由于其能够同时提供块存储（RBD）、对象存储（RADOS Gateway）和文件存储（CephFS），长期以来被视为 OpenStack 和各大超融合平台的标准存储底座 25。然而，Ceph 的架构设计决定了其在处理小文件覆盖写（Overwrite）时，由于需要经过复杂的日志和对象切分机制，存在显著的性能衰减；同时，Ceph 集群的日常运维、故障排查与性能调优门槛极高，往往需要专业的存储工程师团队才能驾驭 27。
相比之下，团队正在进行二次开发的 JuiceFS 代表了新一代云原生分布式文件系统的设计哲学。JuiceFS 创造性地实施了“数据”与“元数据”的物理彻底解耦 29。实际的文件数据块被存储在极其廉价且可无限扩展的底层对象存储（如公有云的 S3 或私有云中的 Ceph RADOS）中，而极其敏感、需要高频访问的文件元数据（如目录结构、权限、文件大小）则被集中存储在高性能的内存数据库或分布式事务数据库（如 Redis、TiKV 等）中 28。这种架构极大提升了存储系统的弹性扩展能力和海量小文件处理性能，特别契合当今极其火热的人工智能（AI）大模型训练、自动驾驶数据回放以及三维图形渲染等对 POSIX 协议兼容性要求极高的高阶场景 31。
在现代 IaaS 和云原生容器平台中，存储系统若想被业务无缝使用，必须通过标准化接口接入。容器存储接口（CSI）便是为此而生。CSI 提供了一种插件化的标准架构，使得底层的存储提供商（例如团队研发的二次开发版 JuiceFS）完全不需要修改 Kubernetes 或云平台的核心源代码，只需按照规范编写并部署一组独立的 CSI 驱动程序容器，即可为上层虚拟机或容器实现存储卷（Volume）的动态自动化创建、挂载、容量扩充以及即时快照备份等企业级高级功能 35。掌握 CSI 驱动的开发，是独立存储产品走向通用 IaaS 生态的必经之路。

1.5. IaaS 业界标准与互操作性：打破数据孤岛与供应商锁定

为了确保未来我们自主研发的 IaaS 产品能够与业界其他主流系统（如公共云、传统虚拟化平台或其他私有云）保持高度的互操作性，实现系统间数据的无缝导入、导出与互相交换，必须在架构设计之初就严格遵循业界的事实标准与开放规范。这不仅能降低客户的“供应商锁定（Vendor Lock-in）”顾虑，还能极大提升我们产品的系统生态兼容性。
  • 虚拟机磁盘格式（qcow2 与 RAW）： 在 KVM 和 OpenStack 生态中，qcow2（QEMU Copy-On-Write version 2）是最为通用且功能强大的事实标准磁盘格式。它原生支持精简置备（Thin Provisioning）、内部快照链、后台备份以及数据透明压缩，非常适合高级的云计算管理环境。虽然 raw 这种未经结构化处理的格式能提供略高一筹的物理级磁盘 I/O 性能，但它会占用大量空闲空间且缺乏原生快照等高级管理特性。此外，业界还存在诸如 VMware 的 vmdk 和微软 Hyper-V 的 vhdx 等专有格式。我们未来的 IaaS 平台在底层计算节点应当首选 qcow2 作为默认运行格式，同时在导入导出功能中内置如 qemu-img 这样的转换工具链，以保障跨虚拟化平台的磁盘镜像平滑流转。
  • 虚拟机打包与分发标准（OVF / OVA）： 当需要在不同云平台间迁移，或者向外分发包含多块虚拟磁盘文件及复杂硬件配置拓扑（如 CPU 核心数、内存规格、网卡数量）的完整虚拟机时，OVF（开放虚拟化格式，Open Virtualization Format）及其打包归档的单一文件版本 OVA（Open Virtual Appliance）是业界绝对的通用跨平台标准。全面支持 OVF/OVA 的一键导入与导出，是我们未来的 HCI 产品能够接纳客户从传统的 VMware 或异构私有云环境中无缝“带机迁移”的核心前提。
  • 容器化与云原生镜像标准（OCI）： 随着云原生技术的普及，早期由 Docker 公司定义的私有镜像格式已被 OCI（Open Container Initiative，开放容器倡议）这一广泛的行业规范所取代。OCI 严格定义了容器的“镜像规范（Image Specification，决定了镜像的层级结构和分发格式）”与“运行时规范（Runtime Specification，决定了容器启动时的资源隔离与生命周期）”。这意味着只要遵守 OCI 标准，无论客户使用什么工具链（如 Docker 或 Podman）构建的容器应用，都能在我们的云原生平台上（通过 containerd 或 CRI-O 等标准化运行时环境）无缝稳定地执行。
  • 云原生基础架构插件接口（CSI 与 CNI）： 如前文所述，为了彻底解耦底层基础设施与上层的容器编排系统，Kubernetes 社区主导制定了 CSI（Container Storage Interface，容器存储接口）和 CNI（Container Network Interface，容器网络接口）两大核心标准规范。CSI 标准使得包括我们基于 JuiceFS 深度定制的任何底层分布式存储系统，只需研发符合 RPC 约定的外挂驱动插件，就能即插即用地接入所有标准的 K8s 云平台，无需修改云平台的任何核心代码；同理，CNI 也为引入高级的软件定义网络技术提供了通用的插槽。
  • 云主机自动化初始化规范（Cloud-init）： 在 IaaS 的自动化运维中，当用户从一个通用的基础操作系统模板（如标准版 Ubuntu）启动几十个新的虚拟机实例时，系统需要能够自动为每一个实例注入特定的主机名、网络 IP、硬盘扩容指令以及安全的 SSH 登录密钥。在这个关键环节，cloud-init 是目前横跨 AWS 等公有云以及 OpenStack 等私有云生态共同采用的事实标准定制服务。我们在研发自有的轻量级云管理控制平面时，必须提供与之兼容的元数据（Metadata）下发服务引擎，这是实现虚拟机资源“一键秒级、无人值守”交付的关键基础。

1.6. IaaS 各种技术总结

为了更直观地展示这些复杂技术在 IaaS 架构中的定位，特编制下表以供决策层参考：
IaaS 核心领域
关键底层技术与开源组件
商业隐喻与管理类比
对小微团队的战略意义与研发建议
计算虚拟化
Linux KVM, QEMU, Libvirt
提供物理级别的硬隔离，如同大楼的地基与承重墙。
技术已极其成熟且固化，底层 C 代码无需任何修改，团队只需通过调用高级 API 实现控制即可。
容器化与编排
Namespaces, Cgroups, Kubernetes
轻量级资源分配与全局统筹调度，如同大楼的智能物业管理系统。
Kubernetes 已成为云计算事实上的“操作系统”，一切二次开发与产品架构必须优先考虑以 K8s 为基座。
网络虚拟化
OVS/OVN, VXLAN, Calico, Cilium
打破物理线缆的限制，建立跨主机的无形虚拟通道。
极度复杂。并且且试错成本高，建议直接集成成熟的开源 CNI 插件（如 Cilium），避免自主从零研发底层网络协议栈。
存储虚拟化
CephFS, JuiceFS, CSI 驱动接口
提供分布式、高可用的数据保险箱。
此为团队绝对的核心竞争力所在。 只要开发出完善的 CSI 驱动，就能以存储供应商的身份无缝切入任何 IaaS 与 PaaS 平台。

2. 业界主流 IaaS 与 HCI 软件生态及产品竞争力分析

在确立了清晰的技术理论基础之后，企业在规划产品线扩展时，必须以全局视野审视目前市场上已有的主要玩家及其产品形态。企业级基础设施软件市场的竞争，早已不是单纯的代码性能或单纯功能列表竞争，而是生态丰富度、架构复杂度的平衡以及最终客户运维体验的综合博弈。

2.1. 传统企业级霸主与国产化替代的时代机遇

在相当长的一段历史时期内，VMware 凭借其自研闭源的 ESXi 架构和 vSphere 管理套件，确立了其在企业数据中心不可撼动的行业标准地位。然而，随着 Broadcom 对 VMware 的收购落地，其产品线的大幅精简以及向全订阅制转型导致的授权费用飙升，在全球市场，尤其是对成本与自主可控极度敏感的国内市场，正在掀起一场规模空前的“VMware 替代”浪潮 8。这一宏观市场变化，为走开源路线的 IaaS 平台和国产超融合产品提供了前所未有的市场红利与切入点。
团队目前紧密合作的安超云（ArcherOS），正是抓住了这一时代机遇的典型代表。作为国内优秀的超融合厂商，安超云的核心竞争力在于其打造的“安超云基座”概念。它依托“多芯全栈”的信创适配能力，在南向全面兼容包括飞腾、鲲鹏、海光等在内的六大国产芯片和统信、麒麟等五大国产操作系统；在北向则通过统一的 LCM（生命周期管理）平台，向用户屏蔽了底层复杂的基础架构，提供了一站式的软件定义计算、存储与网络服务 3。安超云的市场成功向我们证明了一个关键的商业逻辑：仅仅拥有零散的开源底层技术（如单机的 KVM 或单独的 Ceph 集群存储产品）是无法直接变现的，必须通过一层优秀的、高度集成的控制平面将它们粘合起来，并打上“安全可靠”、“一键运维”的标签，才能在挑剔的政企市场获得高度认可 3。

2.2. 复杂而庞大的全栈云平台：OpenStack

如果要探讨开源 IaaS，OpenStack 是一座无法绕开的丰碑。它是目前全球部署最广泛的开源云计算基础设施软件，控制着全球数以千万计的计算核心，是许多跨国电信运营商（如各大公有云服务商的底层架构）和超大型金融机构的首选基座 40。与普通软件不同，OpenStack 并非一个单一的执行程序，而是一个由几十个松散耦合的独立子项目共同组成的庞大生态系统，其最初的设计目标就是为了管理由成千上万台物理服务器组成的大型公有云或私有云 8。
为了深入理解其运作机制，我们需要对其核心组件进行拆解：
  • Nova（计算组件）：负责管理虚拟机生命周期的绝对核心。需要注意的是，Nova 自身并不包含任何虚拟化引擎，它是一个纯粹的调度器，通过调用底层的 KVM、VMware 甚至裸金属物理机来完成最终的资源分配 42。
  • Neutron（网络组件）：提供高级的 SDN 网络即服务。它允许云计算租户在 Web 界面上自由绘制复杂的网络拓扑，包括创建隔离的子网、虚拟路由器、负载均衡器等。其底层指令通常被下发给 OVS 或 OVN 来具体执行 42。
  • Cinder（块存储组件）：管理持久化的虚拟硬盘。与 Nova 类似，Cinder 本身绝不直接存储任何用户数据字节，它是一个存储网关。它通过加载各种由第三方存储厂商编写的驱动程序（Driver），与后端的存储系统（如开源的 Ceph，或商业的 NetApp、EMC 存储阵列）进行对接通信 42。
  • Keystone（身份认证）与 Glance（镜像管理）：前者为整个 OpenStack 生态系统提供统一的用户认证、权限目录和 API 令牌分发；后者则作为一个只读的注册表，存储操作系统的安装镜像文件模板，供 Nova 在创建新虚拟机时快速克隆使用 42。
对团队的战略评估：OpenStack 具备无与伦比的强大功能，支持极其复杂的多租户资源强隔离、细粒度的计费接口以及几乎无上限的横向扩展能力 47。然而，这种“大而全”带来了灾难级的架构复杂度。各个独立组件之间需要通过消息队列（如 RabbitMQ）进行海量的异步通信，并依赖复杂的数据库状态同步。对于一个核心成员不足十人的小微软件团队而言，仅仅是搭建、排错并维持一套高可用的 OpenStack 控制平面，就足以耗尽所有的研发精力。因此，本报告强烈建议，不应该将 OpenStack 作为团队自主交付的全栈 IaaS 底层核心架构 8。但是，OpenStack 庞大的存量市场是一块巨大的蛋糕，团队应当投入少量资源，为现有的存储产品开发兼容的 Cinder Driver，以此作为敲门砖，将存储产品作为独立的组件提供、出售给那些已经建立了私有化 OpenStack 平台的客户 50。

2.3. 简单易用的混合架构集群平台：Proxmox VE (PVE)

与 OpenStack 的极度庞大和复杂形成鲜明对比的是，Proxmox VE（简称 PVE）走的是一条“开箱即用”的极简主义路线。PVE 是一款基于 Debian Linux 的开源虚拟化管理平台，它通过精妙的工程设计，将 KVM 虚拟机管理、LXC 容器支持、软件定义存储（深度集成了 Ceph 与 ZFS）以及基础的网桥与 VLAN 网络功能，全部压缩并融合在了一个小小的系统 ISO 安装镜像中 8。
  • 平台特性与核心优势：PVE 提供了一个极其直观且功能全面的基于 Web 的图形化管理界面。最值得称道的是，它原生内置了基于 Corosync 的多节点高可用（HA）集群技术和其独创的基于数据库驱动的集群配置同步文件系统（pmxcfs） 48。这意味着，用户只需几台普通的物理服务器，在不需要部署任何额外且昂贵的独立管理节点数据库的情况下，即可在十分钟内搭建起一个具备虚拟机自动容灾漂移能力的超融合集群 54。对于中小型企业（SMB）、边缘计算节点或缺乏专业运维团队的分支机构场景，PVE 的部署成本和日常运维心智负担极低 8。
  • 对二次开发的严峻挑战与法律风险：PVE 的核心优势在于“简单一体化”，但其管理平面主要是使用 Perl 语言编写的，属于相对传统的单体架构，并未提供现代微服务那种极度灵活的外部扩展机制 8。更关键的是其开源许可协议的风险。PVE 采用了极为严格的 AGPL v3 开源协议 57。AGPL 协议的特殊之处在于它堵住了传统的 SaaS 漏洞：如果任何企业修改了 PVE 的核心源代码，并将其作为在线云服务提供给客户，或者将其打包修改并作为商业闭源的超融合一体机向外售卖，那么该企业必须无条件公开所有修改后的源代码 59。这对于寻求构建独立商业壁垒、希望保护自身知识产权的商业软件企业来说，是一道难以逾越的法律红线。因此，除非团队仅仅是编写与其交互的外部脚本或合规的独立插件，否则绝不应在 PVE 的核心代码上进行深度的闭源二次开发。

2.4. 云原生超融合领域的颠覆性新星：Harvester

Harvester 是由著名的 Kubernetes 管理平台提供商 Rancher（现已归属 SUSE 旗下）发起并主导的一款 100% 免费开源的现代超融合基础架构（HCI）解决方案 61。它代表了整个 IaaS 架构向“云原生”演进的最新技术结晶，其底层核心设计理念极具颠覆性：“摒弃传统的虚拟化管理工具，用 Kubernetes 统一管理一切资源”。
  • 革命性的技术架构解析：
    • 底层承载系统：Harvester 摒弃了臃肿的通用 Linux 发行版，而是直接运行在裸金属服务器上，其底层采用的是类似 Elemental for SUSE Linux 这样精简且“不可变（Immutable）”的操作系统，旨在将操作系统的日常维护需求降至最低 63。
    • KubeVirt 核心基石：这是云原生计算基金会（CNCF）旗下的明星项目，也是 Harvester 的灵魂。传统的云计算思路是用强大的虚拟机去运行轻量级的容器，而 KubeVirt 彻底反转了这一逻辑——它实现了在 Kubernetes 的容器（Pod）内部直接运行 KVM 虚拟机 65。在 Harvester 眼中，虚拟机不再是特殊的存在，它被彻底转化为了一种标准的 Kubernetes 自定义资源定义（CRD）。这带来了惊人的红利：虚拟机立刻继承并享受了与容器完全相同的自动化调度、故障自愈、网络隔离和存储生命周期管理能力 67。
    • 原生解耦的存储与网络：在默认状态下，Harvester 使用 Longhorn 项目提供分布式的底层块存储引擎，并使用 Multus CNI 提供虚拟机所需的多网卡和复杂 VLAN 网络接入能力 63。
  • 产品竞争力与二次开发潜力评估：Harvester 最大的历史突破在于，它用一套极其优雅的云原生控制平面，统一了传统的虚拟机工作负载与现代的容器化微服务工作负载，彻底消除了长期存在于企业 IT 基础设施中的新旧两套管理“孤岛” 62。它的用户界面清爽现代，完全开源，且不存在像 PVE 那样令人担忧的 AGPL 传染性协议风险，极其适合那些正处于云原生转型焦虑期的大中型企业 52。对于具备开发能力的小微团队而言，Harvester 的架构高度模块化和插件化。例如，它默认的 Longhorn 存储系统在处理大规模数据或追求极致性能时存在瓶颈，这恰好是本团队的优势所在。团队完全可以将底层的存储组件无缝替换为自研的、性能更为强悍的 CephFS 或 JuiceFS 引擎，以此作为切入点，打造一款具有鲜明特色的独立 IaaS 品牌基座 63。
对比 Harvester 与 OpenStack 之类的传统的 IaaS 集成解决方案，Harvester 的优势：
  • 统一的容器与虚拟机：在单一的 k8s 集群里可以同时运行容器应用以及传统的虚拟机应用。通过 Rancher，可以从一个单一屏幕同时管理所有类型的 workload。这是 Harvester 最革命性的一点，完全打通了现代云原生计算环境与传统虚拟化集群之间的鸿沟。
  • 显著降低的复杂性：OpenStack 以其复杂性而闻名，需要专门的团队来管理其众多组件（Nova、Neutron、Cinder 等）。Harvester 是一个一体化设备，它以单个操作系统镜像的形式安装，即可立即使用。
  • 云原生友好的 Kubernetes 核心：由于 Harvester 构建于 Kubernetes 之上，因此它使用 k8s 生态系统内标准的 API 和工具链，例如用于分布式存储的 Longhorn 和用于虚拟化的 KubeVirt。如果团队已经熟悉 Kubernetes 生态系统，那么几乎不需要学习成本。
  • 原生的超融合基础设施 (HCI) ：Harvester 提供原生的 HCI 架构。将计算、存储和网络集成到同一节点中。无需单独部署各种不同类型（计算、存储）的节点。
  • 简洁友好的图形用户界面 (GUI)：Harvester 提供了一个现代化的、用户友好的仪表板（尤其是在与 Rancher 集成时），其体验更接近 VMware，而不是 OpenStack 繁杂的管理面板。
Harvester 的缺点（与 OpenStack 相比）：
  • 扩展性限制：OpenStack 支持管理超大规模的服务器集群（物理节点数量可达数万个）。Harvester 针对中小型集群（边缘、实验室或区域生产环境）进行了优化，在大规模部署时可能会遇到性能瓶颈。典型的生产环境 Harvester 集群的物理节点数量在几百个左右。
  • 网络功能有限：OpenStack 的 Neutron 提供极其强大且复杂的软件定义网络 (SDN) 功能。Harvester 的网络功能则较为基础，主要侧重于 VLAN 和基于桥接（bridging）的网络。
  • 控制平面资源开销较大：由于 Harvester 运行完整的 Kubernetes 集群 (RKE2) 作为其管理层，因此对于小型部署来说，它存在相对较多的性能开销。因为运行控制平面可能占用每个节点数 GB 的内存。
  • 成熟度和生态系统：OpenStack 已经发展了十多年，拥有庞大的插件生态系统，几乎涵盖了所有硬件供应商。Harvester 仍然是一个较新的产品，缺乏对传统硬件的深度支持。
除了上述四大代表性方案，市场上还存在 Apache CloudStack 与 OpenNebula 这样老牌的轻量级 IaaS 平台。相较于笨重的 OpenStack，它们采用了更趋向于单体的紧凑架构设计，部署和日常运维难度显著降低，对各种底层 Hypervisor（不仅是 KVM，还包括 VMware 等）的兼容性较好 9。它们更适合纯粹的中小企业“虚拟机简单租赁”和传统的资源池化场景 9。但必须指出的是，这两者在开源社区的绝对活跃度、生态扩展的活力，尤其是对未来不可逆转的 Kubernetes 云原生底层原生整合程度上，远不如 Harvester 这样的后起之秀。考虑到未来云计算的发展方向正不可避免地走向分布式与云原生 2，如果团队将其作为未来三到五年自主研发的战略基座，可能在技术前瞻性上面临生态护城河不足的长远风险。

2.5. 主流 IaaS 平台总结

为了便于直观对比，总结主流 IaaS 平台特性如下表：
IaaS 平台名称
核心技术底座与架构
主要优势与市场定位
对本团队的二次开发适用度评估
OpenStack
微服务架构，各组件（Nova, Neutron 等）松耦合
极度可扩展，多租户隔离强，适合大型公有云与政务云。
不建议作为整体基座。 架构过重，团队可开发对应的独立 Cinder 存储驱动。
Proxmox VE
单体架构，Debian + KVM + LXC + pmxcfs
部署极简，自带高可用集群，极受中小企业欢迎。
极高法律风险。 AGPLv3 协议限制了闭源商业化定制的可能，仅限开发外挂存储插件。
Harvester
云原生微服务，Kubernetes + KubeVirt + 容器化底层
架构代表未来，统一纳管虚拟机与容器，消除 IT 孤岛。
最佳基座候选。 架构完全云原生，可利用团队长处直接替换其内置的开源存储层。
CloudStack
Java 单体架构，支持多 Hypervisor 混合管理
运维比 OpenStack 简单得多，界面友好，适合传统私有云。
不推荐。 可作为兜底的备选方案，但其技术栈陈旧，缺乏云原生革命性的特性，难以形成降维打击优势。

3. 小微存储团队的二次开发可行性评估与战略定位

在充分厘清了底层的技术逻辑，并深度剖析了市场上主流产品的优劣势之后，团队在动手编写第一行代码之前，必须进行冷静而客观的自我剖析，清晰界定自身在 IaaS 洪流中的战略定位。
现有资源盘点与优劣势精准识别：
  • 显著的核心优势：团队在分布式存储领域，尤其是基于 CephFS 和 JuiceFS 的二次开发上，已经积累了真正的核心技术壁垒。团队不仅了解代码，更懂得在严苛生产环境中关于存储集群的性能极致调优、高并发下的元数据一致性保障以及灾备高可用架构设计。在面对当下极其火爆的 AI 大模型预训练与推理、海量小文件高并发读写、自动驾驶数据回放等高阶复杂场景时，团队的专业存储产品拥有远远超越市面上通用 HCI 平台内置免费存储（例如 PVE 的原生 Ceph 块存储或 Harvester 默认的 Longhorn）的处理能力 76。这是团队最锋利的矛。
  • 不可忽视的劣势：团队的核心研发力量不足十人，日常的代码维护和测试资源极度受限。在这样的资源盘子下，如果盲目去从零开始研发一套类似于 VMware ESXi 那样底层的计算调度器，或者去从头手写一套复杂的 SDN 网络控制器，不仅周期漫长，而且极大概率会造出一个千疮百孔的“劣质轮子”，导致实际产品缺乏市场竞争力。
基于上述客观现实，我们向决策层提出的核心战略定位建议是：“以存托算，借船出海”。
团队绝不应该浪费宝贵的研发工时去重复制造通用的计算管理平台或网络基础设施，而应当极其坚决地将所有的服务器底层资源抽象、虚拟机的生命周期调度、网络虚拟接口的分配统统交给久经考验的 Kubernetes（通过 KubeVirt）或现有成熟的轻量级平台去完成 67。团队仅有的一点研发资源，必须做到 100% 的聚焦，将其全部倾注在以下三个能直接产生高溢价的领域：
  1. “零门槛”的控制台（Dashboard）体验定制：打造极其贴合本土客户习惯、降低管理门槛的交互界面。
  1. 特色存储能力的深度无缝融合：让 IaaS 平台能够原生地发挥出 JuiceFS/CephFS 在 AI、海量数据场景下的全部性能潜力。
  1. 面向特定高价值行业的一体化打包方案交付：不做大而全的通用云平台，而是提供诸如“AI 深度学习训推一体机”、“广电级三维图形渲染云基础架构”等具有鲜明行业标签的专用解决方案 32。
针对目前团队熟悉 Python / Go 等语言生态（CephFS / JuiceFS 等软件由 Python / Go 等语言开发 30）以及希望尽可能规避开源协议商业化限制的初衷，本报告强烈建议将 KubeVirt 云原生生态（或直接站在 Harvester 项目的肩膀上）作为团队迈向独立一体化 IaaS 解决方案提供商的唯一核心战略基座。

4. 迈向独立交付：分阶段企业级产品线扩展与演进路线图

云计算的拓展绝非一蹴而就。基于“小步快跑验证市场、严格控制资金风险、分步摆脱对原生伙伴依赖”的指导思想，以下为团队详细规划的一份为期三十六个月（三年期），分三个阶段稳步推进的企业软件产品线演进与二次开发实施路线图。

4.1. 阶段一：强化自身存储基座，全面推行插件化生态集成（第 1-12 个月）

阶段战略目标：本阶段的第一要务是“活下去并广结善缘”。在绝对不脱离当前合作伙伴（如安超云等）提供基础现金流的前提下，动用少量精锐研发力量，大幅扩充团队自研分布式存储产品的向上兼容生态接口。让团队的存储不再只能被特定超融合平台“包养”，而是能够通过标准接口，单独向外进行横向销售。本阶段的核心开发任务是构建一系列极其稳健的 “南向基础设施接口插件”。
重点实施的开发工作与技术领域：
  1. Kubernetes CSI (Container Storage Interface) 驱动的深度开发
      • 开发内容：依托团队深谙代码逻辑的 JuiceFS 与 CephFS 存储底座，使用 Go 语言开发并对外发布达到企业生产级可用标准的 CSI 插件。该驱动不仅需要实现 CreateVolume（创建卷）、DeleteVolume（删除卷）、ControllerPublishVolume（挂载卷）等最基础的标准 RPC 生命周期接口 35。更重要的是，为了建立技术壁垒，必须实现对高阶功能的支持，例如存储卷的不停机动态扩容、支持极速回滚的动态快照备份（VolumeSnapshot），以及对于未来 AI 多节点推理场景至关重要的 ReadWriteMany (RWX) 多点并发读写模式支持 35。
      • 商业战略意义：只要握有一份经过认证且运行稳健的 CSI 驱动，团队的存储产品立刻就具备了独立战斗的能力。它可以作为强大的后端存储资源池，无缝且合规地出售给市面上任何正在使用原生 Kubernetes、Red Hat OpenShift 或者是 Rancher 集群的政企客户，这是实现产品解绑和走向独立的第一步 35。
  1. OpenStack Cinder 驱动程序的定制与适配
      • 开发内容：由于 OpenStack 的核心主要是 Python 生态，需要安排人员利用 Python 编写专属的 Cinder Volume Driver 模块。在代码层面实现虚拟机存储卷在 CephFS/JuiceFS 后端的映射、挂载、卸载、瞬时快照与卷克隆等核心逻辑，并将其封装为一个独立的安装包，作为官方默认驱动之外的性能增强模块提供给客户 50。
      • 商业战略意义：在国内庞大的政务云、大型国有企业及运营商数据中心市场，OpenStack 架构占据了绝对的市场份额 8。具备了企业级的 Cinder 驱动，公司的销售团队就可以大胆地向这些金字塔顶端的大型企业单独兜售我们的高性能分布式存储资源池，用于替换他们数据中心里昂贵且性能遇到瓶颈的传统商用 SAN 存储阵列。
  1. Proxmox VE (PVE) 自定义存储后端插件研发
      • 开发内容：由于 PVE 极其受广大小微企业和初创团队开发者的欢迎，团队需要深入钻研 PVE 的 PVE::Storage::Plugin Perl 语言接口规范。为团队的定制版 JuiceFS 编写合规的自定义存储后端插件（Custom Storage Plugin），实现存储池容量和健康状态的实时监控、虚拟磁盘文件的动态分配与销毁等控制流功能 56。此举无需修改 PVE 的底层核心，因此完美避开了 AGPL 协议的制裁。

4.2. 阶段二：试水“存算一体”，向轻量级自主 HCI 进军（第 13-24 个月）

阶段战略目标：依托阶段一积累的丰富插件开发经验和底层系统融合 know-how，团队的野心将不再局限于做一家单纯的“存储插件提供商”。在此阶段，开始尝试以自有品牌，打包并推出一套独立的、包含“计算+网络+存储”完整闭环的轻量级超融合（HCI）初级产品。初期的目标客群应避开大型政企，重点针对边缘计算分支节点、中小型企业的内部研发测试环境，以及迫切需要轻量级部署的 AI 边缘推理节点。
技术路线的终极选型与具体实施内容：
在这一承前启后的关键阶段，团队的架构师将面临两条截然不同的技术分岔路：
  • 路线 A（稳健但存在知识产权天花板的妥协派）：深度定制基于 Proxmox VE 的软装载包
    • 操作方式：充分利用 PVE 社区极其成熟的 Debian 底层生态，开发一套基于 Ansible 的自动化统一部署脚本。销售人员到达客户现场后，通过一键执行脚本，将原生的 PVE 平台与团队自研的 JuiceFS 存储底座同时安装并粘合。网络层面直接复用 PVE 原生且简单的 SDN 桥接配置 47。
    • 商业优势：技术开发成本极其低廉，团队几乎不需要编写任何关于计算虚拟化的底层代码。PVE 在中小企业群体中口碑极佳，客户教育成本低，容易快速签单回笼资金 8。
    • 致命的长期劣势：如前文深究，AGPL v3 协议是一颗定时炸弹 57。如果公司试图为了构建自身品牌，对 PVE 的 Web 管理界面进行改版（俗称换壳 White-labeling），或者修改了虚拟机的控制逻辑层，甚至仅仅是将该一体机作为商业闭源产品兜售，都会面临严重的侵权起诉风险；其次，PVE 的 Perl 技术栈相对陈旧，未来想要支撑诸如 AI 调度引擎等复杂的微服务架构时，将显得力不从心。
  • 路线 B（本报告强烈推荐的具备长远价值的战略派）：基于 KubeVirt 构建纯正的自研云原生轻量平台
    • 实施内容：彻底抛弃传统的 IaaS 历史包袱。以纯粹的原生 Kubernetes 集群作为大厦的唯一地基，果断引入 CNCF 顶级项目 KubeVirt 来实现底层的计算虚拟化调度 66。同时，将团队在阶段一精心打磨的 CSI 驱动 作为整个集群的绝对主力持久化存储基座 35。团队极其宝贵的研发力量（尤其是熟练掌握 Go 语言的开发人员 30），将全部集中于开发一个功能贴心、视觉现代的全新 Web 控制平面 / Dashboard。
    • 产品功能规划：这个自研的 Web 控制平面实际上是一个高级的 Kubernetes API 翻译器。它通过调用 K8s 的 API（本质上是操作后端的各种 CRD，例如 VirtualMachine, VirtualMachineInstance），为非技术背景的普通客户提供一种类似于使用阿里云、腾讯云等公有云一样简单的体验，通过鼠标点击即可实现“创建虚拟机”、“划拨存储卷”、“配置虚拟网卡”的图形化交互 67。
    • 商业战略意义：这条路线不仅让团队完全避开了与复杂的 KVM 底层控制流硬刚，把整个 IaaS 平台在各种极端情况下的容灾稳定性，全权托付给了已被全球验证过无数次的 Kubernetes 引擎。更具前瞻性的是，该平台从诞生第一天起，就是一个“双擎驱动”的现代化基础设施——它既能无缝运行传统老旧的业务（放在 KubeVirt 虚拟机中），又能以最原生的方式运行现代化的微服务应用（放在标准的 Kubernetes 容器中） 65。这是直击当下广大企业在数字化转型中“既要兼顾历史遗产，又要拥抱云原生”这一核心痛点的终极武器。并且，由于 Web 控制平面是团队从零自主研发的，底层采用的大多是 Apache 2.0 这种极其宽容的开源协议，团队彻底掌握了核心产品的版权、定价权与品牌自主权。

4.3. 阶段三：云原生行业专有 HCI 解决方案的独立交付与生态破局（第 25-36 个月）

阶段战略目标：经过前两年的技术积累与市场磨合，在第三年，公司将正式向市场推出一款具有完全自主知识产权的、体验卓越的完整云原生超融合基础设施（HCI）平台。此时，公司已具备完全独立落地的能力，可彻底摆脱对诸如安超云等第三方大型 HCI 厂商的渠道依赖。并且，为了避免在同质化严重的通用私有云市场与华为、新华三等巨头打消耗战，公司将利用自身所特有的高性能存储性能优势，在特定的高价值细分市场（如 AI 算力底座、高性能渲染云）构成降维打击，实现生态破局。
纵深技术实施与行业生态商业闭环构建：
  1. 吸收顶级开源精髓，升华网络与存储底座
      • 实施内容：SUSE 旗下的 Harvester 架构设计堪称云原生 HCI 的典范，且其开源协议对商业化极为友好。进入深水区后，团队的资深架构师可以深入剖析并借鉴 Harvester 的控制面源码精髓，但必须果断将其默认的、性能平庸的 Longhorn 存储组件剥离出局 63，通过深度的内核级 API 绑定，将团队引以为傲的高并发、低延迟 JuiceFS/CephFS 引擎作为整个平台的神经中枢。
      • 高阶网络增强：在 SDN 虚拟网络层面，原有的基于 iptables 的传统 CNI 插件在面对未来万兆或十万兆规模的跨节点数据吞吐时必将成为瓶颈。团队应率先引入基于 eBPF 革命性技术的 Cilium 项目来替换底层的网络基础网络插件 20。Cilium 能够绕过繁杂的内核网络栈，提供微秒级的网络包转发性能以及极其直观的应用层网络流量可视化能力，这将极大提升团队 IaaS 整体产品在面对极客客户或大型项目招投标时的技术含金量与评分优势 22。
  1. 构建面向 AI 与大数据的垂直行业“杀手级”解决方案
      • 业务场景与市场洞察：在 2026 年的市场语境下，通用 IaaS 市场的价格战已是一片红海。但是，随着大语言模型（LLM）的普及，各个传统行业都在试图构建自己的私有化 AI 基础设施。大模型在预训练的过程中，会产生数以亿计的微小 Checkpoint 文件；在分布式推理时，极其依赖数十个 GPU 节点对同一套庞大模型文件的低延迟并发读取。这种场景对底层文件存储系统的要求之高，是普通的超融合平台根本无法企及的灾难级挑战，但这恰恰是 JuiceFS 这种元数据解耦架构的绝对主场 31。
      • 产品最终形态：团队最终向高价值大客户交付的，不应该仅仅是冷冰冰的虚拟机和磁盘，而是一套名为“AI 算力原生融合基础设施一体机”的全栈交钥匙方案。这套方案自底向上包含了：底层精简的不可变操作系统、KubeVirt 统一计算虚拟化引擎、Cilium 高性能极速网络、JuiceFS 无限扩展的极速存储池，以及最上层预装且优化过的 AI 训练与数据流转平台（如预置的 Kubeflow 模型开发模板） 31。
      • 商业闭环的最终完成：在这个终极产品形态下，团队真正向客户输出了一套不可替代的、具备深度技术护城河的私有云基础设施。客户在一个极简的管理界面下，既能平稳运行传统的企业管理软件数据库（传统 IaaS 场景），又能丝滑地为 AI 研发团队瞬间拉起包含成百上千个容器的分布式训练微服务网络 62。至此，公司将彻底完成从一个受制于人的“附属存储组件开发商”，向一家拥有具有市场竞争力、自主知识产权的完整产品线的“软硬一体化现代 IaaS 平台供应商”的技术转型与商业进化。

引用文献

  1. Gartner Says Worldwide IaaS Public Cloud Services Market Grew 22.5% in 2024, 3月 4, 2026にアクセス、 https://www.gartner.com/en/newsroom/press-releases/2025-08-06-gartner-says-worldwide-iaas-public-cloud-services-market-grew-22-point-5-percent-in-2024
  1. Distributed Hybrid Infrastructure: The Future of Cloud Computing | Nutanix, 3月 4, 2026にアクセス、 https://www.nutanix.com/info/cloud-computing/distributed-hybrid-infrastructure
  1. 安超云操作系统ArcherOS, 3月 4, 2026にアクセス、 https://www.archeros.com/storage/file/20210820/BHTGZGhJgbyVdlpyov7GKoqFupmiPdI8CShVb9RS.pdf
  1. 安超虚拟化平台软件ArcherOSStack - 数字技术基础架构提供商, 3月 4, 2026にアクセス、 https://www.archeros.com/product/ArcherOS_Stack
  1. Similarity/differences between NFV and SDN | TM Forum Community, 3月 4, 2026にアクセス、 https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?GroupId=433&MessageKey=1dd758d2-ef9f-4629-bcac-90cf09ad5f49&CommunityKey=5ff76f9b-920e-4cb6-9180-9091d781e186&ReturnUrl=%2Fcommunities%2Fcommunity-home%2Fdigestviewer%3FMessageKey%3D941f0a3b-4a3f-4c2d-8bd5-6d32b45b8bb5%26CommunityKey%3D5ff76f9b-920e-4cb6-9180-9091d781e186
  1. Virtualization on Linux using the KVM/QEMU/Libvirt stack | bitgrounds.tech, 3月 4, 2026にアクセス、 https://bitgrounds.tech/posts/kvm-qemu-libvirt-virtualization/
  1. Defining Virtualization Terms: What Are Libvirt, QEMU, and KVM? - YouTube, 3月 4, 2026にアクセス、 https://www.youtube.com/watch?v=qEuuN1rkPw0
  1. Openstack vs Proxmox: Which Virtualization Solution is Right for Me? - Cloudification, 3月 4, 2026にアクセス、 https://cloudification.io/cloud-blog/openstack-vs-proxmox-which-virtualization-solution-is-right-for-me/
  1. CloudStack vs OpenStack: A Practical Comparison for Private Cloud Platforms, 3月 4, 2026にアクセス、 https://cloudification.io/cloud-blog/cloudstack-vs-openstack-a-practical-comparison-for-private-cloud-platforms/
  1. Namespaces and Cgroups – the basis of Linux Containers Rami Rosen - andrew.cmu.ed, 3月 4, 2026にアクセス、 https://www.andrew.cmu.edu/course/14-712-s20/applications/ln/Namespaces_Cgroups_Conatiners.pdf
  1. Chapter 1. Introduction to Linux Containers | Overview of Containers in Red Hat Systems, 3月 4, 2026にアクセス、 https://docs.redhat.com/en/documentation/red_hat_enterprise_linux_atomic_host/7/html/overview_of_containers_in_red_hat_systems/introduction_to_linux_containers
  1. What Are Namespaces and cgroups, and How Do They Work? - NGINX Community Blog, 3月 4, 2026にアクセス、 https://blog.nginx.org/blog/what-are-namespaces-cgroups-how-do-they-work
  1. The 7 most used Linux namespaces - Red Hat, 3月 4, 2026にアクセス、 https://www.redhat.com/en/blog/7-linux-namespaces
  1. SDN vs NFV - Interconnections - The Equinix Blog, 3月 4, 2026にアクセス、 https://blog.equinix.com/blog/2020/03/10/sdn-vs-nfv-understanding-their-differences-similarities-and-benefits/
  1. OVN Kubernetes - What Makes It Different - DEV Community, 3月 4, 2026にアクセス、 https://dev.to/nurudeen_kamilu/ovn-kubernetes-what-makes-it-different-2dli
  1. Setting up container based Openstack with OVN networking - ZHAW Blog, 3月 4, 2026にアクセス、 https://blog.zhaw.ch/icclab/setting-up-container-based-openstack-with-ovn-networking/
  1. Understanding the Open Virtual Network - Red Hat Emerging Technologies, 3月 4, 2026にアクセス、 https://next.redhat.com/2017/08/15/understanding-the-open-virtual-network/
  1. OVN: Open Virtual Network for Open vSwitch, 3月 4, 2026にアクセス、 https://www.openvswitch.org/support/slides/OVN_BANV.pdf
  1. Understanding VXLANs | Junos OS - Juniper Networks, 3月 4, 2026にアクセス、 https://www.juniper.net/documentation/us/en/software/junos/ovsdb-vxlan/evpn/topics/topic-map/sdn-vxlan.html
  1. Calico vs. Cilium: Which Kubernetes CNI Is Right for You? - Zesty.co, 3月 4, 2026にアクセス、 https://zesty.co/finops-glossary/calico-vs-cilium-in-kubernetes-networking/
  1. Calico vs. Cilium: 9 Key Differences and How to Choose - Tigera.io, 3月 4, 2026にアクセス、 https://www.tigera.io/learn/guides/cilium-vs-calico/
  1. Cilium vs Calico: We Run Both in Production - Here's What Won (2026) | Tasrie IT Services, 3月 4, 2026にアクセス、 https://tasrieit.com/blog/cilium-vs-calico-cni-comparison-2026
  1. Cilium vs Calico: Comparing Kubernetes Networking Solutions - DEV Community, 3月 4, 2026にアクセス、 https://dev.to/mechcloud_academy/cilium-vs-calico-comparing-kubernetes-networking-solutions-10if
  1. 安超云操作系统ArcherOS, 3月 4, 2026にアクセス、 https://www.archeros.com/product/ArcherOS
  1. Nova System Architecture - OpenStack Documentation, 3月 4, 2026にアクセス、 https://docs.openstack.org/nova/2024.1/admin/architecture.html
  1. How to Build a Ceph Cluster and Integrate with the JuiceFS File System, 3月 4, 2026にアクセス、 https://juicefs.com/en/blog/usage-tips/build-ceph-cluster-integrate-juicefs-file-system
  1. Ceph: Can I use ceph storage as VM filesystem or object storage? | Proxmox Support Forum, 3月 4, 2026にアクセス、 https://forum.proxmox.com/threads/ceph-can-i-use-ceph-storage-as-vm-filesystem-or-object-storage.55048/
  1. JuiceFS vs. CephFS | JuiceFS Document Center, 3月 4, 2026にアクセス、 https://juicefs.com/docs/community/comparison/juicefs_vs_cephfs/
  1. How to Set Up Object Storage | JuiceFS Document Center, 3月 4, 2026にアクセス、 https://juicefs.com/docs/community/reference/how_to_set_up_object_storage/
  1. avelino/awesome-go: A curated list of awesome Go frameworks, libraries and software - GitHub, 3月 4, 2026にアクセス、 https://github.com/avelino/awesome-go
  1. NAVER, Korea's No.1 Search Engine, Chose JuiceFS over Alluxio for AI Storage, 3月 4, 2026にアクセス、 https://juicefs.com/en/blog/user-stories/juicefs-vs-alluxio-ai-storage-naver
  1. Building AI Inference with JuiceFS: Supporting Multi-Modal Complex I/O, Cross-Cloud, and Multi-Tenancy, 3月 4, 2026にアクセス、 https://juicefs.com/en/blog/solutions/ai-inference-multi-cloud-storage-multi-tenancy
  1. Ideal Car x JuiceFS: Evolution and Thinking from Hadoop to Cloud Native, 3月 4, 2026にアクセス、 https://segmentfault.com/a/1190000042370647/en
  1. Storage Solution for Rendering Scenarios - JuiceFS, 3月 4, 2026にアクセス、 https://juicefs.com/en/storage-solution-for-rendering-scenarios
  1. Storage - Docs - Kubermatic Documentation, 3月 4, 2026にアクセス、 https://docs.kubermatic.com/kubermatic-virtualization/main/architecture/concepts/storage/
  1. Kubernetes CSI Drivers: The Complete Guide - Portworx, 3月 4, 2026にアクセス、 https://portworx.com/knowledge-hub/a-complete-guide-to-kubernetes-csi/
  1. Portworx, Red Hat OpenShift Virtualization, and KubeVirt, 3月 4, 2026にアクセス、 https://portworx.com/blog/portworx-redhat-openshift-virtualization-and-kubevirt/
  1. 安超云成功入选2025年江苏省软件核心竞争力企业, 3月 4, 2026にアクセス、 https://www.archeros.com/News/index/id/1609
  1. 安超云再度入选Gartner中国超融合市场竞争格局报告, 3月 4, 2026にアクセス、 https://www.archeros.com/research_report/index/id/1533
  1. OpenStack: Open Source Cloud Computing Infrastructure, 3月 4, 2026にアクセス、 https://www.openstack.org/
  1. OpenStack - Wikipedia, 3月 4, 2026にアクセス、 https://en.wikipedia.org/wiki/OpenStack
  1. Chapter 1. Components | Architecture Guide | Red Hat OpenStack Platform | 10, 3月 4, 2026にアクセス、 https://docs.redhat.com/en/documentation/red_hat_openstack_platform/10/html/architecture_guide/components
  1. What is OpenStack? | Mirantis, 3月 4, 2026にアクセス、 https://www.mirantis.com/cloud-native-concepts/understanding-openstack/what-is-openstack/
  1. A Deep Dive into Key OpenStack Services: Nova, Neutron, and Cinder | by Radhika Singh, 3月 4, 2026にアクセス、 https://rbaccrets.medium.com/a-deep-dive-into-key-openstack-services-nova-neutron-and-cinder-44f6008cbe56
  1. What Is OpenStack? Benefits and Components - Fortinet, 3月 4, 2026にアクセス、 https://www.fortinet.com/resources/cyberglossary/openstack
  1. Boost Your Cloud Storage: Best Practices for OpenStack Cinder, 3月 4, 2026にアクセス、 https://trilio.io/openstack-training/openstack-cinder/
  1. Proxmox vs OpenStack: Virtualization / Private Cloud Platform Comparison Guide, 3月 4, 2026にアクセス、 https://www.baculasystems.com/blog/proxmox-vs-openstack/
  1. Proxmox vs OpenStack: Comparing Open Source Cloud Software - OpenMetal, 3月 4, 2026にアクセス、 https://openmetal.io/resources/blog/proxmox-vs-openstack-comparing-open-source-cloud-software/
  1. Comparing all open 'cloud infrastructure platforms' : r/sysadmin - Reddit, 3月 4, 2026にアクセス、 https://www.reddit.com/r/sysadmin/comments/1h61iub/comparing_all_open_cloud_infrastructure_platforms/
  1. cinder.volume.driver module - OpenStack Documentation, 3月 4, 2026にアクセス、 https://docs.openstack.org/cinder/latest/contributor/api/cinder.volume.driver.html
  1. Available Drivers — cinder 27.1.0.dev181 documentation, 3月 4, 2026にアクセス、 https://docs.openstack.org/cinder/latest/drivers.html
  1. Proxmox vs Harvester - Virtualization Meets Cloud-Native Infrastructure - simplyblock, 3月 4, 2026にアクセス、 https://www.simplyblock.io/blog/proxmox-vs-harvester/
  1. Proxmox vs. OpenStack: Choosing Your Virtualization Platform - Trilio, 3月 4, 2026にアクセス、 https://trilio.io/resources/proxmox-vs-openstack/
  1. Proxmox VE Administration Guide, 3月 4, 2026にアクセス、 https://pve.proxmox.com/pve-docs/pve-admin-guide.html
  1. Proxmox VE vs. OpenStack: Comparison of open source virtualization solutions for cloud infrastructures - Cloud&Heat Technologies, 3月 4, 2026にアクセス、 https://www.cloudandheat.com/en/proxmox-ve-vs-openstack-comparison-of-open-source-virtualisation-solutions-for-cloud-infrastructures/
  1. Storage Plugin Development - Proxmox VE, 3月 4, 2026にアクセス、 https://pve.proxmox.com/wiki/Storage_Plugin_Development
  1. Proxmox VE license, 3月 4, 2026にアクセス、 https://forum.proxmox.com/threads/proxmox-ve-license.23324/
  1. Contributor License Agreement, AGPL | Proxmox Support Forum, 3月 4, 2026にアクセス、 https://forum.proxmox.com/threads/contributor-license-agreement-agpl.153198/
  1. Open Source Software Licenses 101: The AGPL License | FOSSA Blog, 3月 4, 2026にアクセス、 https://fossa.com/blog/open-source-software-licenses-101-agpl-license/
  1. [SOLVED] - AGPL license as a system vendor | Proxmox Support Forum, 3月 4, 2026にアクセス、 https://forum.proxmox.com/threads/agpl-license-as-a-system-vendor.72198/
  1. Harvester - Open-source hyperconverged infrastructure, 3月 4, 2026にアクセス、 https://harvesterhci.io/
  1. Harvester HCI: A New Approach to Hyperconverged Infrastructure - Kloia, 3月 4, 2026にアクセス、 https://www.kloia.com/blog/new-way-of-hci-harvester
  1. GitHub - harvester/harvester: Open source hyperconverged infrastructure (HCI) software, 3月 4, 2026にアクセス、 https://github.com/harvester/harvester
  1. Harvester Overview | Harvester, 3月 4, 2026にアクセス、 https://docs.harvesterhci.io/
  1. What is KubeVirt? - Red Hat, 3月 4, 2026にアクセス、 https://www.redhat.com/en/topics/virtualization/what-is-kubevirt
  1. KubeVirt Part 1 - Run VMs like a Pod | D2iQ Engineering, 3月 4, 2026にアクセス、 https://eng.d2iq.com/blog/kubevirt-part-1-run-vms-like-a-pod/
  1. Architecture - KubeVirt user guide, 3月 4, 2026にアクセス、 https://kubevirt.io/user-guide/architecture/
  1. What Is KubeVirt? Understanding Virtual Machines on Kubernetes - Portworx, 3月 4, 2026にアクセス、 https://portworx.com/knowledge-hub/understanding-kubevirt/
  1. Harvester vs Proxmox for homelab kubernetes in 2022 - Reddit, 3月 4, 2026にアクセス、 https://www.reddit.com/r/homelab/comments/rxnus3/harvester_vs_proxmox_for_homelab_kubernetes_in/
  1. Proxmox vs. Harvester: Can the enterprise-grade platform beat the community favorite?, 3月 4, 2026にアクセス、 https://www.xda-developers.com/proxmox-vs-harvester/
  1. Harvester HCI or Proxmox VE? (Kubernetes, Storage) - Reddit, 3月 4, 2026にアクセス、 https://www.reddit.com/r/kubernetes/comments/rabgj0/harvester_hci_or_proxmox_ve_kubernetes_storage/
  1. Harvester HCI 1.5: Revolutionizing Infrastructure for Government and Enterprise, 3月 4, 2026にアクセス、 https://blog.alphabravo.io/harvester-hci-1-5-revolutionizing-infrastructure-for-government-and-enterprise/
  1. CloudStack vs. OpenStack Comparison - What you need to know before choosing a cloud management system - ShapeBlue, 3月 4, 2026にアクセス、 https://www.shapeblue.com/cloudstack-vs-openstack-comparison/
  1. Comparing CloudStack, OpenNebula & OpenStack - LINBIT, 3月 4, 2026にアクセス、 https://linbit.com/blog/comparing-cloudstack-opennebula-openstack/
  1. STATE OF CLOUD NATIVE DEVELOPMENT Q3 2025, 3月 4, 2026にアクセス、 https://www.cncf.io/wp-content/uploads/2025/11/cncf_report_stateofcloud_111025a.pdf
  1. TAL: Building a Low-Operation Model Repository Based on JuiceFS in a Multi-Cloud Environment, 3月 4, 2026にアクセス、 https://juicefs.com/en/blog/user-stories/multi-cloud-llm-model-repository-storage
  1. Hai Robotics Achieved High Availability & Easy Operations in a Hybrid Cloud Architecture with JuiceFS, 3月 4, 2026にアクセス、 https://juicefs.com/en/blog/user-stories/high-availability-easy-operations-hybrid-cloud-ai-storage
  1. NFS to JuiceFS: Building a Scalable Storage Platform for LLM Training & Inference, 3月 4, 2026にアクセス、 https://juicefs.com/en/blog/user-stories/ai-storage-platform-large-language-model-training-inference
  1. Go for Cloud & Network Services - The Go Programming Language, 3月 4, 2026にアクセス、 https://go.dev/solutions/cloud
  1. Filesystems, Disks and Volumes - KubeVirt user guide, 3月 4, 2026にアクセス、 https://kubevirt.io/user-guide/storage/disks_and_volumes/
  1. OpenShift virtualization: Containers, KVM, and your VMs - Red Hat, 3月 4, 2026にアクセス、 https://www.redhat.com/en/blog/openshift-virtualization-containers-kvm-and-your-vms
  1. Drivers — cinder 27.1.0.dev181 documentation - OpenStack Docs, 3月 4, 2026にアクセス、 https://docs.openstack.org/cinder/latest/contributor/drivers.html
  1. Proxmox VE Storage, 3月 4, 2026にアクセス、 https://pve.proxmox.com/pve-docs/chapter-pvesm.html
  1. Custom storage plugins for Proxmox | ServeTheHome Forums, 3月 4, 2026にアクセス、 https://forums.servethehome.com/index.php?threads/custom-storage-plugins-for-proxmox.12558/
  1. Most popular Go Open Source projects that beat alternatives in all other languages : r/golang - Reddit, 3月 4, 2026にアクセス、 https://www.reddit.com/r/golang/comments/17qsct0/most_popular_go_open_source_projects_that_beat/
  1. KubeVirt in the real world and how to run VMs on Kubernetes - Spectro Cloud, 3月 4, 2026にアクセス、 https://www.spectrocloud.com/blog/kubevirt-in-the-real-world