把机房交给 AI 管（五）：存储与容器
前言：两座孤岛
存储团队管 vSAN。
容器团队管 Tanzu。
两拨人，两套工具，出问题互相甩锅。
vmware-skills 家族把这两块也做成了 AI 技能：Storage 和 VKS。
一、项目身份
VMware-Storage：vSphere 存储管理。数据存储、iSCSI、vSAN，11 个工具的领域专用 MCP 技能。
VMware-VKS：vSphere with Tanzu（VKS）。Supervisor、Namespace、TanzuKubernetesCluster 全生命周期，MCP 技能 + CLI。需要 vSphere 8.x+。
VMware-PrivateAI：VMware Private AI Foundation with NVIDIA。GPU 清单、vGPU/DirectPath 配置、利用率、模型服务。社区项目，与 VMware/Broadcom/NVIDIA 无隶属关系。
二、主执行链路
VKS 的日常：
以前开发团队要个 K8s 集群，提单、等审批、等运维排期。
现在 AI 一条链路：查 Supervisor → 建 Namespace → 绑存储策略 → 部署 TKC 集群 → 验证就绪。
三、核心模块
Storage（11 个工具）：
- 数据存储：容量、挂载、浏览
- iSCSI：适配器、目标、会话
- vSAN：集群状态、策略、容量
VKS（三层）：
- Supervisor：vSphere 的 K8s 控制面
- Namespace：资源分配和配额的单元
- TKC：跑在 vSphere 上的 Tanzu K8s 集群
PrivateAI：
- GPU 清单：哪台主机有什么卡
- vGPU/DirectPath：GPU 分配配置
- 模型服务：AI 负载的部署支撑
四、跨端边界
Storage：vSphere 全版本兼容，和家族其他包一致。
VKS：硬性要求 vSphere 8.x+。老环境用不了。
PrivateAI：依赖 NVIDIA 的 GPU 虚拟化栈。没有 vGPU license 就只能看 DirectPath 直通。
职责边界：
- 存储策略的定义在 Storage
- 存储策略的消费在 VKS（Namespace 绑定策略）
- GPU 分配在 PrivateAI
- AI 代理可以跨包编排，但每个包只干自己领域的事
五、数据与状态流
组合价值：
单看存储，只知道 vSAN 快满了。
单看 K8s，只知道集群要扩容。
AI 把两边数据一拼：这个 Namespace 的 PVC 都落在快满的 vSAN 上，扩容前先腾存储——这是单包看不到的结论。
六、配置边界
Storage：
- vCenter 连接，只读场景只读账号即可
- vSAN 和 iSCSI 分开的工具集，按需接入
VKS：
- Supervisor 的 K8s 凭证 + vCenter 凭证，两套都要
- Namespace 配额和存储策略是关键配置
PrivateAI：
- vGPU license 状态影响可用工具面
- 模型服务的镜像源配置
七、扩展点
- CLI + MCP 双模式：VKS 和家族一致，小模型走 CLI 省 token
- Namespace 即服务：配合 Pilot 工作流，可以做带审批门的自动化开通
- GPU 池化报表：PrivateAI 的利用率数据可以喂给 Aria 做长期趋势
八、风险点
1. VKS 版本门槛
vSphere 7.x 环境直接出局。升级前别规划这套自动化。
2. 存储操作的不可逆
删数据存储、改 vSAN 策略，出问题就是数据事故。这类操作沿用家族惯例：双重确认 + 审计，账号权限卡死。
3. Namespace 配额漂移
AI 自动建 Namespace 很爽，忘了配额就是资源黑洞。开通流程里必须包含配额步骤。
4. GPU 争抢
vGPU profile 分配超售会互相影响。AI 做 GPU 分配时要看实时利用率，不能只看清单。
5. PrivateAI 的独立性
它是社区项目，NVIDIA 的栈变得快，跟进有滞后。生产依赖前先在测试环境跑通。
记住
存储和容器不该是两座孤岛。
Storage 管 vSAN，VKS 管 Tanzu，PrivateAI 管 GPU。
AI 跨包编排，才能给出单包看不到的结论。
GitHub：
- https://github.com/vmware-skills/VMware-Storage
- https://github.com/vmware-skills/VMware-VKS
- https://github.com/vmware-skills/VMware-PrivateAI License：MIT
"