企业存储正在从“预先买足容量”转向按工作负载动态匹配性能与规模。Google Cloud Filestore 近期将云原生后端存储层直接构建在 Colossus 之上，并通过 GKE 深度集成、独立 IOPS 配置和 multishares for GKE，为容器化应用、海量数据集以及 AI Agent 协作工作空间提供了新的共享存储基础。
从 VM 架构走向 Colossus 原生存储
Filestore 是 Google Cloud 的一方托管 NFS 文件服务，面向企业应用、容器平台和 AI 工作负载提供安全、可扩展的共享文件系统。升级后的后端使用 Colossus，也就是支撑 YouTube、Gmail 和 Gemini 等 Google 全球服务的分布式存储基础设施。
这种变化的价值不只是“底层换了一个存储系统”。它让 Filestore 更接近云原生服务的运行方式：存储容量、性能和故障恢复可以分别处理，资源扩展也不必完全依赖传统的单体式存储架构。
对于应用团队而言，最直接的变化是可以通过 Custom Performance 独立调整 IOPS。一个开发环境可能只需要较小的容量，但在编译、模型加载或批处理期间需要更高的吞吐；过去为了获得性能，团队可能不得不同时预留更多容量。容量和性能解耦后，可以更精确地匹配实际需求，并在工作负载变化时调整成本结构。
GKE 上的共享存储更适合规模化部署
Filestore CSI driver 可以让 GKE 工作负载使用持久化、高性能的 NFS 存储。对于需要多个 Pod 访问相同文件的应用，例如训练数据准备、模型缓存、检查点共享和流水线中间结果，NFS 的共享语义比为每个 Pod 分配独立磁盘更自然。
Filestore multishares for GKE 进一步改变了资源分配方式。一个较大的 Filestore 实例可以被切分成多个更小的共享空间，单个 share 的起始容量可以低至 10 GiB。这样，平台团队可以在保持高性能实例能力的同时，为不同项目、命名空间或租户分配独立的文件共享。
下面是一个可以改造使用的 Kubernetes 示例。它假设集群中已经安装并配置了 Filestore CSI driver，并且已经创建了名为 filestore-csi 的 StorageClass。实际环境中，StorageClass 的名称、参数和访问范围需要按集群配置调整。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: agent-shared-workspace
namespace: ai-agents
spec:
accessModes:
- ReadWriteMany
storageClassName: filestore-csi
resources:
requests:
storage: 100Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: agent-worker
namespace: ai-agents
spec:
replicas: 3
selector:
matchLabels:
app: agent-worker
template:
metadata:
labels:
app: agent-worker
spec:
containers:
- name: worker
image: REGION-docker.pkg.dev/PROJECT_ID/agents/worker:latest
env:
- name: SHARED_WORKSPACE
value: /workspace
volumeMounts:
- name: shared-workspace
mountPath: /workspace
volumes:
- name: shared-workspace
persistentVolumeClaim:
claimName: agent-shared-workspace
部署前可以先创建命名空间并检查 PVC 状态：
kubectl create namespace ai-agents
kubectl apply -f agent-workspace.yaml
kubectl get pvc -n ai-agents
kubectl get pods -n ai-agents -o wide
这个例子中的关键点是 ReadWriteMany。它允许多个 Pod 同时挂载同一个共享文件系统，但并不意味着应用可以忽略并发控制。应用仍然需要设计清晰的文件命名、事务边界和锁策略。
为 Agent Swarm 提供共同工作空间
AI Agent Swarm 通常由多个职责不同的自治 Agent 组成：一个 Agent 负责检索资料，另一个负责执行工具调用，还有 Agent 负责验证结果或生成最终输出。它们往往需要同时读取和写入共同数据，包括任务状态、上下文文件、工具结果、检查点和中间产物。
在这种架构中，Filestore 文件共享可以充当所有 Agent 都能访问的工作空间。NFS 提供一致的文件系统访问方式，而 NFS 文件锁可以帮助协调并发读写，减少多个 Agent 同时修改同一文件造成的冲突。
一种简单的目录布局可以是：
/workspace/
tasks/
task-001/
state.json
input/
artifacts/
locks/
shared/
knowledge-cache/
model-assets/
agents/
researcher/
executor/
reviewer/
应用可以使用文件锁保护关键状态文件。下面的 Python 示例使用标准库 fcntl，适用于 Linux 容器；生产环境仍应补充超时、异常恢复和陈旧锁处理逻辑。
from pathlib import Path
import fcntl
import json
state_path = Path("/workspace/tasks/task-001/state.json")
state_path.parent.mkdir(parents=True, exist_ok=True)
with state_path.open("a+", encoding="utf-8") as state_file:
fcntl.flock(state_file.fileno(), fcntl.LOCK_EX)
try:
state_file.seek(0)
try:
state = json.load(state_file)
except json.JSONDecodeError:
state = {"events": []}
state["events"].append({
"agent": "researcher",
"status": "completed"
})
state_file.seek(0)
state_file.truncate()
json.dump(state, state_file, ensure_ascii=False, indent=2)
state_file.flush()
finally:
fcntl.flock(state_file.fileno(), fcntl.LOCK_UN)
需要注意的是，共享文件系统适合存放 Agent 的共享状态和文件型产物，但不应自动替代数据库、消息队列或专门的任务编排系统。高频小对象更新、复杂查询、精确的任务调度和跨服务事件传递，通常仍然应该由更合适的系统负责。
运维控制与安全边界
Colossus 后端带来的另一个收益是运维灵活性。Filestore 可以独立调整 IOPS，而不必因为性能变化重建整个集群。分布式存储层也有助于更快恢复故障，并支持容量变化时减少停机影响。具体的可用性、性能上限和变更行为仍应以所选 Filestore 服务等级与区域能力为准。
安全控制需要同时覆盖云资源权限和 NFS 文件系统权限：
- 使用 Google Cloud IAM 控制谁可以管理 Filestore 资源。
- 使用 NFS UID/GID 映射，让容器内用户身份与文件权限保持一致。
- 使用 IP ACL 限制哪些网络来源可以访问文件共享。
- 对不同团队或项目使用独立 share，降低误读和误写风险。
- 对 Agent 产生的文件设置生命周期、配额和清理策略，避免共享空间无限增长。
尤其是在多租户 GKE 集群中，ReadWriteMany 并不等于“所有 Pod 都应该拥有全部权限”。平台团队仍需要结合命名空间隔离、网络策略、Unix 权限和应用身份设计访问边界。
采用时的检查清单
Filestore on Colossus 更适合以下场景：应用需要共享文件访问，工作负载规模会动态变化，或者 GKE 中有大量需要持久化共享空间的容器。部署前可以检查几个问题：
- 工作负载需要的是文件系统语义，还是数据库、对象存储或块存储语义？
- 多个 Pod 是否真的需要同时读写同一目录？
- IOPS、容量和吞吐是否已经分别测量，而不是只用容量估算成本？
- Agent 是否有明确的锁、状态更新和冲突恢复机制？
- IAM、UID/GID 和 IP ACL 是否共同形成了最小权限边界？
- 是否已经准备好容量增长、文件清理和故障恢复的监控指标？
Filestore 通过 Colossus 获得了更具弹性的存储基础，并把这种能力延伸到了 GKE 和 AI Agent 协作场景。对于需要共享数据、动态性能和企业级控制的团队，合理的落地路径通常是先用一个可观测的小规模工作负载验证 NFS 并发行为，再逐步引入 multishares、独立 IOPS 配置以及更细粒度的租户隔离。