Litmus项目中的默认ChaosHub配置与离线环境适配方案

在云原生混沌工程平台Litmus的实际部署中，默认配置的ChaosHub（混沌实验资源库）会从GitHub仓库获取预定义的故障实验模板。这一设计在常规联网环境下运行良好，但在企业级隔离网络（Air-Gapped Environment）中却面临挑战。本文将深入分析该机制的技术原理，并提供两种可行的解决方案。

默认ChaosHub机制解析

Litmus核心架构包含一个预配置的中央ChaosHub，其本质是一个指向GitHub仓库的只读资源库。该仓库存储着：

• 标准化的混沌实验CRD模板
• 故障注入工作流定义文件
• 各类Kubernetes资源清单
• 实验验证指标收集配置

当用户通过Litmus控制台创建混沌实验时，系统会自动从该Hub拉取所需模板。这种设计降低了用户的使用门槛，但同时也带来了网络依赖问题。

离线环境下的问题表现

在隔离网络环境中，Litmus控制台会出现以下典型症状：

1. 控制台持续显示GitHub连接错误
2. 实验创建流程卡在模板加载阶段
3. 系统日志中出现DNS解析或连接超时记录
4. 依赖默认Hub的功能模块（如实验推荐）不可用

这些现象源于系统对默认Hub的硬编码依赖，即便用户已配置私有Hub，原始连接尝试仍会持续进行。

推荐解决方案：自定义Hub配置

实现原理

通过修改Litmus的部署配置，将默认Hub指向内部镜像仓库。这需要调整以下组件：

1. 前端配置：更新UI的默认Hub端点
2. 后端服务：重写Hub资源解析逻辑
3. CRD定义：确保自定义Hub的协议兼容性

实施步骤

1. 搭建内部Git镜像服务，同步官方ChaosHub仓库
2. 创建ConfigMap存储自定义Hub的访问凭证
3. 修改Deployment环境变量：

   env:
   - name: DEFAULT_HUB_URL
     value: "http://internal-git/repos/litmus-chaos"
   - name: DEFAULT_HUB_BRANCH
     value: "v2.7.x"
   

4. 重启控制平面组件使配置生效

该方案不仅能消除连接错误，还能实现：

• 企业级实验模板的集中管理
• 定制化故障场景的内部共享
• 符合安全审计要求的变更追踪

备选方案：完全禁用默认Hub

对于不需要中央仓库的场景，可通过以下方式彻底禁用：

1. 修补API Server的校验逻辑，跳过默认Hub检查
2. 在前端代码中移除Hub状态监测组件
3. 部署时添加注解：

   annotations:
     litmus.io/disable-default-hub: "true"
   

需要注意的是，该方案会导致：

• 所有实验模板必须通过私有Hub提供
• 部分向导功能可能受限
• 需要额外验证自定义模板的兼容性

最佳实践建议

对于生产环境，推荐采用混合策略：

1. 主配置禁用默认Hub连接
2. 部署企业级ChaosHub服务
3. 建立定期的内部仓库同步机制
4. 对实验模板进行签名验证

这种架构既满足了安全要求，又保持了实验模板的及时更新，是金融、关键基础设施等敏感场景的理想选择。Litmus的灵活设计允许用户根据实际需求选择最适合的Hub管理策略，体现了混沌工程工具在复杂环境中的适应能力。