Submariner项目在OCP升级过程中网关Pod卡在Container-creating状态的故障排查指南

问题现象

在将OpenShift Container Platform(OCP)从4.14版本升级到4.15版本的过程中，Submariner网络组件的网关Pod可能会陷入"Container-creating"状态，导致跨集群网络连接中断。这一现象通常伴随着以下典型症状：

1. 网关Pod无法正常启动，持续显示为Container-creating状态
2. subctl diagnose命令输出显示"Error getting the Broker's REST config: error getting auth rest config: Unauthorized"错误
3. 跨集群连接状态显示为"connecting"而非"established"

根本原因分析

经过深入调查，发现该问题主要源于Kubernetes/OpenShift平台的安全机制变更。自Kubernetes 1.24版本起，平台不再自动为ServiceAccount创建对应的Secret令牌。这一变更影响了Submariner组件的正常运行，具体表现为：

1. 服务账户令牌缺失：Submariner组件依赖的ServiceAccount缺少必要的Secret令牌，导致认证失败
2. 权限问题：由于缺少有效的认证凭据，组件无法访问Broker API，进而无法建立跨集群连接
3. 版本兼容性问题：在OCP升级过程中，平台安全策略的变更可能意外删除了原有的Secret

解决方案

临时解决方案

对于已经出现问题的环境，可以通过重新执行subctl join命令来修复：

subctl join --kubeconfig=<集群kubeconfig> --operator-debug --pod-debug --clusterid=<集群ID> broker-info.subm

此命令会重新创建必要的ServiceAccount及其关联的Secret令牌。需要注意的是：

1. 需要在所有受影响的集群上执行此命令
2. 执行前应确保broker-info.subm文件可用
3. 建议添加--operator-debug和--pod-debug参数以便获取更详细的日志

长期预防措施

为避免类似问题再次发生，建议采取以下预防措施：

1. 版本规划：确保使用的Submariner版本不低于0.13，该版本已包含对ServiceAccount Secret的手动创建逻辑
2. 权限监控：定期检查submariner-operator和submariner-k8s-broker命名空间下的Secret资源
3. 升级前检查：在OCP升级前，使用subctl diagnose命令验证所有必要组件状态

关键检查点

当遇到类似问题时，技术人员应重点检查以下方面：

1. Secret资源：确认以下Secret存在于相应命名空间：

   • submariner-operator命名空间下的broker-client-token-*
   • submariner-k8s-broker命名空间下的cluster-*相关Secret

2. Pod日志：检查网关Pod和operator Pod的日志，寻找认证相关的错误信息

3. RBAC配置：验证ServiceAccount的权限绑定是否完整

最佳实践建议

1. 升级策略：在OCP升级前，先升级Submariner到最新稳定版本
2. 备份机制：重要操作前备份关键资源，特别是broker-info.subm文件
3. 监控告警：设置对Submariner组件状态的监控，及时发现连接问题
4. 文档记录：维护集群状态文档，记录所有Submariner相关配置变更

总结

Submariner在OCP环境中的稳定运行依赖于正确的权限配置和Secret管理。平台升级过程中的安全策略变更可能导致原有配置失效。通过理解问题的根本原因，采取正确的修复措施，并实施有效的预防策略，可以确保跨集群网络的持续可用性。对于生产环境，建议在非关键时段进行升级操作，并做好完整的回滚预案。