CoHDI 已正式成为 CNCF Sandbox 项目。这个里程碑不仅意味着项目进入云原生社区的公开治理与孵化轨道，也指向一个更具体的问题：当计算、内存、加速器和网络资源不再固定封装在同一台服务器里，Kubernetes 应该如何发现、组合并调度这些资源？
从“选择一台节点”到“组合一组资源”
传统 Kubernetes 调度以节点为中心。Pod 声明 CPU、内存等需求，调度器寻找一台满足条件的节点，然后由 kubelet 在该节点上启动容器。这种模型适合资源边界清晰的服务器，却很难完整表达解耦基础设施。
在可组合解耦架构中，资源可能分布在不同设备或资源池中，例如：
- 计算单元来自一个计算池；
- GPU、DPU 或其他加速器独立部署；
- 内存容量可以按工作负载需求组合；
- 高速互连决定哪些资源能够低延迟协同工作。
这会把调度问题从“哪台机器还能放下这个 Pod”改写成“哪些资源能够组成满足性能、拓扑和隔离要求的运行环境”。CoHDI 所代表的方向，就是推动 Kubernetes 面向这种组合式基础设施继续演进。
进入 Sandbox 意味着什么
CNCF Sandbox 是早期云原生项目的入口。被接纳并不等于项目已经成熟，也不代表其接口已经成为 Kubernetes 标准；更准确地说，项目获得了在 CNCF 社区内公开协作、验证设计并扩大贡献者基础的机会。
对 CoHDI 来说，后续值得关注的不是单一版本号，而是几个工程问题：
- 如何描述可组合资源及其容量、健康状态和拓扑关系；
- 如何让调度器理解延迟、带宽、故障域和资源亲和性；
- 如何完成资源分配、挂载、回收和故障恢复；
- 如何与 Kubernetes 现有设备管理、调度和可观测性机制协作；
- 如何避免基础设施实现细节泄漏到每一个应用清单中。
Sandbox 阶段通常也意味着接口和部署方式可能快速变化。生产团队应把它视为架构验证窗口，而不是默认可直接承载关键业务的成熟组件。
可以这样实践：先验证拓扑感知调度
下面的示例不代表 CoHDI 的实际 API，而是一个可直接改造的 Kubernetes 实验，用节点标签模拟“位于同一高速互连区域的计算资源”。它只能验证工作负载放置策略，不会真正组合远端内存或加速器。
运行前，把 worker-01 替换为集群中的真实节点名：
kubectl get nodes
kubectl label node worker-01 infra.example.com/fabric-zone=zone-a --overwrite
创建 topology-demo.yaml：
apiVersion: apps/v1
kind: Deployment
metadata:
name: topology-demo
spec:
replicas: 1
selector:
matchLabels:
app: topology-demo
template:
metadata:
labels:
app: topology-demo
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: infra.example.com/fabric-zone
operator: In
values:
- zone-a
containers:
- name: web
image: nginx:1.27-alpine
resources:
requests:
cpu: 100m
memory: 64Mi
limits:
memory: 128Mi
应用并检查调度结果：
kubectl apply -f topology-demo.yaml
kubectl get pods -l app=topology-demo -o wide
kubectl describe pod -l app=topology-demo
验证完成后可以清理资源：
kubectl delete -f topology-demo.yaml
kubectl label node worker-01 infra.example.com/fabric-zone-
这个小实验暴露了真实系统必须解决的边界：标签只能表达静态分类，不能负责容量预留、并发冲突、设备健康检查或资源回收。要支持真正的解耦资源，通常还需要控制器、设备插件或资源驱动、调度扩展以及统一的状态模型。具体采用哪些机制，应以 CoHDI 后续公布的接口和文档为准。
评估 CoHDI 时应检查什么
准备试用时，可以建立一份面向生产的检查清单：
- 接口稳定性：资源模型是否有明确版本，升级时是否支持兼容或迁移。
- 调度一致性：资源预留与 Pod 调度是否具备原子性，失败后能否自动释放。
- 故障处理：设备、互连或控制器异常时，工作负载会等待、迁移还是失败。
- 多租户隔离：不同租户能否共享资源池，同时维持访问控制和性能隔离。
- 可观测性：是否能从 Pod 追踪到实际分配的计算、内存、设备和网络路径。
- 退出路径：停用项目后，工作负载是否能退回标准 Kubernetes 资源模型。
CoHDI 进入 CNCF Sandbox，为可组合解耦基础设施提供了一个值得跟踪的云原生探索方向。现阶段更稳妥的采用方式，是从测试集群和非关键工作负载开始，记录调度延迟、资源利用率、故障恢复时间与运维复杂度，再判断这种架构是否真正改善了现有资源池的效率。