Kubernetes 部署自托管 LangSmith 任务控制中心指南

核心要点

• Mission Control 整合了自托管 LangSmith 的运维操作。 平台团队可以通过一个集群内的统一界面，管理配置、预检、健康状态、发布历史、诊断和支持工作流。
• 它专为具有严格网络边界的 Kubernetes 环境设计。 Mission Control 运行在集群内部，通过本地方式访问，无需配置入口网关、外部控制平面或额外的数据库。
• 运维人员能够以更少的手动关联进行故障排查和变更验证。 预检功能可以提前捕获常见的部署问题，而健康视图、日志、告警、全局搜索、数据库检查和诊断包则能帮助团队更快定位故障点。

在 Kubernetes 上自托管 LangSmith，让平台团队获得了对基础设施、网络边界、安全策略和部署拓扑的控制权，但同时也意味着更多的运维责任。

随着 LangSmith 的部署跨越多个集群、环境和团队，日常运维工作通常会分散在多种工具之间：

• Helm 部署和 values.yaml 文件
• kubectl logs、describe 命令和事件检查
• 可观测性仪表盘和监控栈
• 用于诊断和支持任务的内部脚本

这种模式之所以有效，是因为它紧贴 Kubernetes 的原生操作，但也带来了上下文切换的负担。运维人员不得不在 Helm、kubectl、仪表盘、日志、脚本和文档之间来回切换，只为回答关于部署状态或排查问题的基本疑问。

认识 Mission Control

Mission Control 是一个解耦的、运行在集群内的应用程序，专门用于部署、配置、观测和排查自托管的 LangSmith 及相关 LangChain 基础设施。它在 Kubernetes 集群内部运行并通过本地方式访问，无需入口网关、外部控制平面，也无需额外的数据库。

Mission Control 直接使用 Kubernetes 原语，并在此基础上增加了一个理解 LangSmith 部署的运维层。运维人员仍然需要与 Helm、Pod、服务、命名空间、日志和事件打交道，但 Mission Control 让这些资源在 LangSmith 的上下文中变得更易于检查和操作。这使运维人员能够通过单一界面完成最常见的 LangSmith 运维任务：

• 查看集群和工作负载健康状态
• 检查待处理或失败的部署
• 跨命名空间检查 Pod 级别的 CPU 和内存使用情况
• 在发布前验证变更

Mission Control 维护着集群的实时运维视图，从而帮助团队减少在不同工具间手动关联状态的时间。

核心运维功能面

1. 快速启动与功能启用

大多数 LangSmith 部署都依赖于一组通用的运维功能，包括入口网关、Gateway API 支持、部署、洞察和智能体工具。配置这些功能通常意味着将设置要求转化为 Helm 配置值，检查哪些选项适用于当前环境，并确保生成的 YAML 在部署前是有效的。

Mission Control 提供了一个引导式的入门流程，能为一次部署生成最小必需的 values.yaml 文件。

运维人员可以通过经过验证的配置变更来启用功能，而无需为每个设置步骤手动编辑 YAML。

2. 配置管理

管理 Helm 配置值容易出错。运维人员需要编辑环境特定的配置、安全地处理密钥，并在应用更新前理解即将发生的变化。Mission Control 包含一个为 Kubernetes 运维人员设计的双向 Helm 值编辑器。

它可以：

• 直接从 GitHub 拉取上游的 values.yaml
• 支持离线环境的文件上传
• 提供简单和高级两种模式
• 对敏感值（如 Fernet 密钥、盐值和令牌）进行掩码处理

在部署之前，Mission Control 会显示当前配置与提议配置之间的安全差异对比，包括对密钥的感知比较。

3. 预检检查

部署失败常常是由本可以提前检查的集群状况引起的。在部署变更之前，Mission Control 会运行集群感知的验证检查，针对常见的故障点：

• 节点容量和调度约束
• Kubernetes 版本兼容性
• DNS 解析
• 存储类的可用性
• 命名空间配额和资源限制

这些检查能在部署前发现问题，从而减少回滚和调试的循环。

4. 健康状态与可观测性

当出现问题时，运维人员需要快速定位问题是出在工作负载、服务、命名空间、网络路径还是存储层。健康视图为运维人员提供了 LangSmith 工作负载的统一快照。

运维人员可以检查：

• Pod 的 CPU 和内存使用率
• 服务的就绪状态和状态
• 实时工作负载日志
• 跨服务的网络拓扑
• PVC 容量和存储压力

其目标是快速回答一个实际的运维问题：LangSmith 现在是否健康？如果不健康，故障点在哪里？

5. 发布管理

当运维人员能够看到当前部署的版本、版本间的变更以及之前部署尝试的情况时，升级管理会变得更容易。Mission Control 为 LangSmith Helm 发布提供了版本感知的部署管理。

运维人员可以看到：

• 附带变更日志的可用 Chart 版本
• 当前部署的版本
• 发布历史记录
• 可下载的部署尝试日志

这为团队提供了关于升级、配置漂移、失败部署和回滚路径的更清晰视图。

6. 专为 LangSmith 打造的运维助手

有些运维问题是 LangSmith 特有的，而不仅仅是 Kubernetes 层面的。运维人员可能需要了解某个设置如何工作、某个问题是否有文档记录，或者当前的部署适用哪些指导。Mission Control 包含一个面向 LangSmith 运维人员的集群内聊天助手。

该助手可以：

• 使用 Chat LangChain 回答 LangSmith 相关问题
• 使答案与当前的 LangSmith 文档和已知问题保持一致
• 在数据离开集群前清理外发的密钥
• 将对话历史范围限定在每个 Mission Control 实例内

这为运维人员提供了一条从集群状态到相关指导的更快路径，而无需在文档、支持工单和故障排查笔记之间来回跳转。

7. 告警与运维信号

当集群状况发生变化时，运维人员需要一份清晰的记录，了解发生了什么以及何时发生。Mission Control 包含基于规则的告警功能，针对诸如以下运维事件：

• 工作负载性能下降
• 节点压力
• HPA 伸缩约束
• 资源耗尽

告警会在 Mission Control 内部创建持久的审计跟踪，为团队提供共享的运维历史记录。

8. 其他功能

全局搜索

运维问题常常会体现在多个资源中。一个故障可能出现在日志、事件、ConfigMap、发布历史、告警或支持脚本里。

Mission Control 提供跨以下资源的统一搜索：

• Pod 日志和描述信息
• Kubernetes 事件
• 发布记录
• 告警历史

数据库工具

LangSmith 部署通常依赖于 Redis、PostgreSQL 和 ClickHouse。Mission Control 提供了受控的工具，用于检查和验证这些集成，而无需授予运维人员不受限制的数据库访问权限。

功能包括：

• 自动发现已配置的外部数据库
• 连接性预检
• 针对常见运维查询的精选支持脚本
• 可下载的 CSV 导出，用于支持工作流

这为团队提供了用于常见数据库检查的可审计工作流，特别是在那些限制或不鼓励直接 Pod 访问的托管数据库环境中。

诊断与事件响应

当发生故障时，Mission Control 可以生成一个诊断包，包含：

• 跨命名空间的 Pod 日志
• 集群元数据快照
• kubectl describe 输出
• 部署和事件时间线

该诊断包被打包成单个可下载的文件，从而减少了在事件处理和支持升级过程中手动收集信息的工作量。

总结

Mission Control 为平台团队提供了一种管理自托管 LangSmith 部署的方式，这种方式契合了他们已经在使用的 Kubernetes 运维模型。配置、验证、健康状态、发布历史、诊断、数据库工具和支持工作流都保留在集群内部，处于现有的安全边界之内。

对于在私有、受监管或离线环境中运行 LangSmith 的团队而言，这意味着更少的临时脚本、更少的上下文切换，以及一条从部署到日常运维的更清晰路径。