本文是《拆解 Palantir：企业 AI 与 FDE 架构指南》第 6 篇。
AIP、Foundry 和 Apollo 都运行在 Palantir Rubix 上。Rubix 是一个经过强化、可自动扩缩、高可用的 Kubernetes 实现，目标是在复杂和高安全环境中提供一致的计算底座。
它的价值不只是“可以运行容器”，而是把安全、临时性、故障恢复和持续运维固化成平台默认行为。
默认安全
Rubix 同时考虑常见攻击与高级持续性威胁。工作负载按需要隔离，高权限运维任务与普通应用执行相互区分。
环境中的数据和通信默认加密。工作负载之间的交互必须经过认证和授权，并留下记录。部署依赖不可变配置，减少人工修改造成的漂移和不可追踪状态。
这套安全模型很适合 Agent 系统。Agent 会动态调用工具、访问数据并触发业务动作，如果基础设施层缺少统一认证、授权和日志，上层应用很难补救。
临时节点
Rubix 会主动轮换计算节点。中文编译资料将节点生命周期描述为不超过 48 小时；Palantir 当前其他架构页面也存在 72 小时内轮换容器的表述。具体参数可能随产品版本或描述对象变化，重要的是其设计原则：计算资源不应长期保持不变。
主动轮换带来两方面价值：
- 从安全角度，攻击者难以在单一节点长期驻留；
- 从可靠性角度，每项服务都必须真正具备中断恢复和故障切换能力。
节点排空、替换和终止由策略控制，基础设施团队不需要依赖大量手工维护。
高可用与弹性
Rubix 通过多节点部署、自动扩缩和需求感知调度，提高服务的可用性并优化成本。
基础设施发生故障或节点被轮换时，上层服务需要自动恢复。容量变化时，计算资源可以根据负载动态调整。这让平台既能承载持续在线的业务应用，也能运行波动明显的数据处理和模型任务。
一个统一的服务底座
Rubix 让 AIP、Foundry、Apollo 及其扩展产品可以部署到 AWS、Azure、Google Cloud、Oracle Cloud、本地机房或边缘环境，并尽量保持相同运营特性。
除了 Palantir 自身服务，Rubix 也能运行定制应用、容器化模型以及其他符合 Kubernetes 规范的工作负载。
对软件团队来说，这意味着同一套产品不用为每一种客户环境重新发明部署和运维方式。
Apollo 与 Day 2 运维
Rubix 负责资源和工作负载运行，Apollo 负责持续交付。二者共同解决系统上线后的 Day 2 问题。
Apollo 为大量服务计算安装、升级和回滚计划。Rubix 的 API 层再把部署意图转化成具体资源指令。
为了降低升级风险，服务可以采用多节点和蓝绿发布：
- 建立新的绿色环境；
- 部署并观察新版本；
- 确认稳定后逐步切换流量；
- 按策略销毁旧的蓝色环境；
- 出现问题时快速回滚。
持续交付因此不再依赖运维人员逐台机器操作。
一次构建，跨环境运行
Kubernetes 提供了通用容器编排能力，Rubix 在其基础上进一步加入安全、高可用、跨环境部署和自治运维特性。
这使软件可以进入普通 SaaS 很难覆盖的环境，例如受严格监管的行业、本地隔离网络和资源有限的边缘场景。
对 AI FDE 的启发
一个 Agent 原型在开发者电脑上成功，只是开始。进入生产环境后，还要回答：
- 是否能够部署到客户指定环境；
- 服务失败后能否自动恢复；
- 模型和工具调用是否完整留痕；
- 新版本能否无停机发布；
- 多个客户环境能否持续升级；
- 安全策略能否在基础设施层统一执行。
Rubix 展示了 AI FDE 容易忽略的一面：AI 落地不仅需要模型和业务理解，还需要长期可靠的软件交付与运行能力。
小结
Rubix 不只是托管容器，而是把安全、节点临时性、高可用、弹性扩缩和自治运维变成基础设施默认行为。它让上层平台可以在不同环境中保持一致运行，并持续接收 Apollo 交付的新能力。
参考资料
中文内容来源：https://x.com/oops073111/status/2095359297094074422
官方资料：https://www.palantir.com/docs/foundry/architecture-center/rubix
上一篇：互操作性 · 系列总览 · 下一篇：AIP 架构全景