环境信息/ Environment

• CI 环境：Argo 流水线 E2E 测试（每日定时执行）
• 失败阶段：EnsureCerts（集群初始化早期阶段）
• 集群状态：InitializationFailed
• 失败用例：应该支持从https格式仓库安装chart（installation_test.go:1799）

问题简述/ Brief Description

EnsureCerts 阶段中，LookUpOrGenerate() 创建证书 secret 后立即调用 NeedGenerate() 检查，由于 lookupRegularCert() 没有重试机制，Informer cache 同步延迟导致 client.Get() 返回 NotFound，误判证书不存在，返回 certs need generate again 错误，集群进入 InitializationFailed 状态。该问题在本地单用例执行时不触发（环境干净、API server 负载低），仅在流水线中前序批次执行后（API server 负载较高）才暴露。

问题详情&复现步骤 / Details & Reproduction Steps

1. 在流水线中执行 installation.post-init 批次测试后，继续执行 installation 兜底批次
2. 用例"应该支持从https格式仓库安装chart"开始执行，集群进入 EnsureCerts 阶段
3. LookUpOrGenerate() 成功创建证书 secret（写入 API Server / etcd）
4. 紧接着 NeedGenerate() 调用 lookupRegularCert() 通过 client.Get() 读取 Informer cache
5. 由于 Informer cache 异步更新，此时 cache 尚未同步，client.Get() 返回 NotFound
6. lookupRegularCert() 直接返回 false（无重试），NeedGenerate() 返回 true
7. Execute() 返回错误 "certs need generate again"
8. 集群状态变为 InitializationFailed

关键日志：

{"level":"WARNING","msg":"Update bkeCluster \"bke-test-addon-1786577355/bke-test-addon-1786577355\" failed error: Operation cannot be fulfilled on configmaps \"bke-test-addon-1786577355\": the object has been modified; please apply your changes to the latest version and try again","source":{"file":"pkg/phaseframe/phases/phase_flow.go","function":"cleanupUnexecutedPhases","line":248}}

{"level":"ERROR","msg":"Reconcile bkeCluster \"bke-test-addon-1786577355/bke-test-addon-1786577355\" phase flow failed: certs need generate again","source":{"file":"controllers/capbke/bkecluster_controller.go","function":"Reconcile","line":139}}

注意： the object has been modified 是附带错误（状态更新时的并发冲突），certs need generate again 才是触发错误。

复现命令：

# 本地单用例执行通常不会触发（环境干净）
ginkgo --label-filter="install-chart-from-https-repo" ./e2e/installation/

# 需要在流水线环境中复现：先执行前序批次（pre-init、post-init、mgmt），再执行 installation 兜底批次

期望结果/ Expected Results

EnsureCerts 阶段应能正确处理 Informer cache 同步延迟，在 LookUpOrGenerate() 创建 secret 后，NeedGenerate() 检查时应能正确读取到已创建的 secret，集群正常进入下一阶段。

实际结果/Actual Results

lookupRegularCert() 通过 controller-runtime 的 client.Get() 读取 Informer cache，由于 cache 异步更新，Create 后立即 Get 可能返回 NotFound。lookupRegularCert() 没有重试机制，一次 Get 不到就认为"不存在"，导致 NeedGenerate() 返回 true，触发 certs need generate again 错误。

可疑源码模块：

• pkg/certs/generator.go — lookupRegularCert() 函数（L354-364）
• pkg/phaseframe/phases/ensure_certs.go — Execute() 函数（L55-69）

建议排查方向：

1. 根因分析： controller-runtime 的 client 对读写操作走不同路径：

   • client.Create()（写）→ Direct client → 直接写入 API Server / etcd
   • client.Get()（读）→ Cached client → 读 Informer Cache（本地缓存）
   • Create 成功后，Informer cache 是异步更新的，存在同步窗口

2. 代码对比： lookupKubeConfigCert()（L367-414）已有重试机制（kubeConfigMaxRetries 次重试 + kubeConfigRetryDelay 间隔），但 lookupRegularCert()（L354-364）完全没有重试，NotFound 直接返回 false。

3. 修复方案建议：

   • 方案 A（推荐）： 给 lookupRegularCert 添加重试机制，与 lookupKubeConfigCert 保持一致
   • 方案 B： Execute() 中 NeedGenerate() 返回 true 时，不直接返回 error，而是返回 ctrl.Result{RequeueAfter: 2*time.Second}，利用 controller-runtime 的 reconcile 循环天然重试能力
   • 方案 C： LookUpOrGenerate() 和 NeedGenerate() 之间增加短暂等待，确保 cache 同步完成

4. 为什么本地通过、流水线失败： 本地环境干净，API server 负载低，Informer cache 同步快，Create→Get 之间 cache 已同步。流水线中前序批次（pre-init、post-init、mgmt）执行后，API server 中有更多资源在 watch，informer 同步压力更大，cache 同步窗口被拉长，更容易触发此问题。

附件：

• E2E 测试产物：e2e-artifacts/installation/installation_test_1799
• Controller-manager 日志已采集
• 流水线配置：argo/e2e-test/e2e-test.yaml