Fission项目升级至1.20.4版本后模型创建失败问题分析

问题背景

在Fission项目从1.20.1版本升级到1.20.4版本的过程中，用户遇到了模型创建失败的问题。具体表现为在升级后，虽然执行器日志显示已创建池管理器部署，但实际上在fission-function命名空间中并没有相应的Pod运行。

问题现象

升级后，系统出现以下异常表现：

1. 路由组件日志显示无法从执行器获取函数服务，报错"context deadline exceeded"
2. 执行器日志显示成功创建了多个环境池，但实际检查fission-function命名空间时发现没有对应的Pod
3. 执行器尝试访问的Pod（如poolmgr-python-env-build-2-default-535606343-67b4589b89-2xlfq）不存在

根本原因分析

经过深入调查，发现问题的根源在于1.20.4版本中引入的OwnerReferences机制。具体表现为：

1. 当使用跨命名空间配置（如builderNamespace和functionNamespace设置为不同的命名空间）时，池管理器部署的创建过程会出现异常
2. 执行器在清理并重新创建池管理器部署时，虽然日志显示成功，但实际上由于OwnerReferences的限制，部署并未真正创建成功
3. 这种跨命名空间的访问方式在Fission的设计中原本就不是推荐做法，新版本中更严格的所有权引用机制使得这种配置不再可行

解决方案

临时解决方案

对于需要立即解决问题的用户，可以采用以下两种临时方案之一：

1. 移除跨命名空间配置： 修改Helm配置，将builderNamespace和functionNamespace设置为空字符串：

   builderNamespace: ""
   functionNamespace: ""
   

   这样所有资源都会创建在默认命名空间中，避免了跨命名空间访问问题。

2. 使用1.20.5版本： 升级到1.20.5版本，该版本引入了DISABLE_OWNER_REFERENCES环境变量，可以通过设置该变量为true来临时禁用OwnerReferences机制：

   executor:
     disableOwnerReferences: true
   

长期解决方案

从架构设计的角度，Fission项目计划逐步淘汰跨命名空间的访问模式。建议用户：

1. 将所有Fission相关资源部署在同一个命名空间中
2. 避免使用builderNamespace和functionNamespace的显式配置
3. 为不同环境或项目使用不同的Fission实例，而不是依赖命名空间隔离

技术细节

OwnerReferences是Kubernetes中的一种资源所有权机制，它确保了资源的生命周期管理。在Fission 1.20.4版本中，这一机制的引入带来了以下变化：

1. 资源创建时会自动设置OwnerReferences，指向创建它的控制器
2. 当控制器被删除时，所有拥有对应OwnerReferences的资源也会被自动清理
3. 跨命名空间的OwnerReferences在Kubernetes中是不被允许的，这导致了资源创建失败

最佳实践建议

1. 升级前检查：在升级Fission版本前，应检查当前的命名空间配置，确保没有使用跨命名空间的设置
2. 测试环境验证：先在测试环境中验证升级过程，确认所有功能正常后再在生产环境执行
3. 监控部署状态：升级后密切监控fission-function命名空间中的Pod状态，确保所有资源正常创建
4. 遵循官方推荐配置：尽量使用Fission的默认配置，避免自定义复杂的命名空间布局

总结

Fission 1.20.4版本引入的OwnerReferences机制暴露了跨命名空间配置的兼容性问题。虽然提供了临时解决方案，但从长远来看，遵循单一命名空间的设计模式才是最佳实践。用户在升级时应充分了解这一变化，并相应调整自己的部署策略。