欢迎来到 openFuyao 社区

Hey @x_chao183 , 感谢你对社区的贡献.

机器人使用手册

有关指令的使用，可以点击 此处 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。您可以自助配置此仓库的 PR 合并规则，更多详情，请参阅此处。

联系指引

有疑问可以联系 SIG: sig-Installation ,
维护者是： @foxbit, @javadoors, @regandy, @xuyouhong, @zqw1 ,
审核者是： @piamposer-li .

openFuyao 安装部署 26.06 → 26.09-rc.2 整体安装流程变慢原因分析与整改方向

---

一、一页结论

26.09-rc.2 的安装流程没有加入任何新相位——变慢全部来自四个"老相位变慢",且已通过同规格硬件复核确认全部为版本代码效应,与硬件无关。 变慢集中在"集群创建"阶段;"引导节点初始化"两轮对比均无版本回归。

同规格硬件下的总时长对比(26.06v2 新机 vs 26.09-rc.2,日志口径,对象创建→cluster ready):

场景	26.06v2(新机)	26.09-rc.2	Δ
引导节点初始化(带管理面)	6:21(381s)	6:19(379s)	-2s(打平)
引导节点初始化(无管理面)	3:46(226s)	3:25(205s)	-21s(26.09 快,全部来自源包下载)
管理集群创建(带管理面)	9:03(543s)	9:12(552s)	+9s
业务集群创建(带管理面)	7:01(421s)	8:37(517s)	+96s
管理集群创建(无管理面)	3:48(228s)	4:16(256s)	+28s
业务集群创建(无管理面)	2:29(149s)	3:15(195s)	+46s

为什么总时长差在两轮之间波动(v1 旧机 +74~96s,v2 同规格 +9~+96s)? 因为单相位的运行噪声可达 ±30s(v2 中 26.06 自己的 MasterInit 就比旧机慢 17~18s、calico 等待一次 84s 孤例),它们会在总时长上部分掩盖或放大真实回归。但相位级回归在两轮独立样本中全部稳定复现(见 §二.2),这才是可靠的信号:

回归源(按影响排序)	v1(旧机)实测	v2(同规格)实测	判定
1. 健康门禁轮询 10s→30s(!445)	门禁 +37s/+101s	门禁 +30s/+90s/+16s(轮距 12s×25 轮 vs 31s×12 轮)	版本效应,复现
2. EnsureNodesEnv 环境脚本链 + RepoUpdate	+22~27s	+21/+24/+23/+26s(四场景全中)	版本效应,复现
3. cluster-api 组件 Ready 门禁(!310)	+26~36s(51→83s)	+29~36s(54/49s→83/85s,两轮幅度一致)	版本效应,复现

二、数据全景

2.1 两轮部署样本总览

数据集	26.06 机器	26.09 机器	硬件	采集
v1(09-18)	.62/.59(CPU8)+.63/.60	.82/.76/.58/.122/.121/.77(CPU4/8G)	不一致	两版本各自部署
v2(09-21)	.127/.128(CPU4/8G)+.136/.137	同 v1	一致	同日交叉复核

2.2 相位级版本回归(三轮数据对照,单位秒)

相位/因子	26.06 旧机	26.06 v2 新机	26.09-rc.2	回归量(26.09−26.06v2)	机制
EnsureCluster 门禁(带管理面长流)	283s(25 轮@~11s)	290s/273s(25 轮@10-13s,中位 11.5s)	320s/363s(11-12 轮@31s)	+30s/+90s	!445 requeue 分级 30s 档;管理面 pod 就绪的感知被拖慢
EnsureNodesEnv	24~38s	26/39/24/24s	47/63/47/50s	+21~+26s	环境脚本链扩充 + RepoUpdate(yum 全量重建,!492 已修)
cluster-api addon 等待	47~54s	54s/49s	83s/85s	+29~36s	!310 Ready 门禁(须过 readiness,不再只等 Running)

2.3 v1 全景(旧机样本,参考)

场景	26.06	26.09	Δ
引导 init(带/无管理面)	6:54 / 3:58	6:19 / 3:25	-35s / -33s(26.09 快,下载+硬件混杂)
管理集群创建(带管理面)	7:58	9:12	+74s
业务集群创建(带管理面)	7:01	8:37	+96s
管理集群创建(无管理面)	3:31	4:16	+45s
业务集群创建(无管理面)	3:01	3:15	+14s

三、根因详解(现象 → 代码 → 日志证据 → 两轮复核)

根因 1:健康门禁轮询粒度 10s → 30s(第一回归源)

• 现象:集群装完后的 EnsureCluster 相位反复健康检查直到全部组件就绪;26.09 该段显著变长,且只打带管理面的场景(无管理面集群门禁两版本都是秒级,因为 calico/coredns 在 AddonDeploy 内已等就绪)。
• 代码:!445 把 26.06 固定 10s 轮询改为分级 requeue(critical 5s / important 15s / optional 30s / normal 5m),选档按失败错误中最高优先级(critical>important>否则 optional)。分类缺口:rc.2 的配置清单只登记了 8 个组件(critical=控制面四件套,important=calico/kube-proxy/coredns),而门禁实际等待的 metrics-server、local-harbor、oauth-server、console、monitoring 栈、user-mgmt、web-terminal 均未登记——未登记组件失败后落入"否则"分支=30s 档。即:安装完成的定义恰恰取决于这批组件,它们却被按最低 active 档位轮询;26.06 的 10s 固定档对谁都是 10s,26.09 把"未登记组件"挪到了 30s。每轮另加一次远端健康配置 CM Get。
• 日志证据:26.06 两轮样本均为 25 轮 × 10-13s(中位 11.5s,逐行原文见证据附录);26.09 为 10-12 次 requeue after 30s(恒 31-32s 间距),失败原文点名等待对象(metrics-server、local-harbor、oauth-server、console、monitoring 栈、user-mgmt、web-terminal)。
• 复核结论:同规格硬件下完全复现,轮距 12s vs 31s 是时钟般的清晰对比,硬件无关。

根因 2:EnsureNodesEnv 变长(+21~26s,每个创建场景都付)

• 现象:四条创建流的节点环境准备相位全部变长;每台节点都要重跑一遍环境检查+小工具安装(helm/calicoctl/lxcfs/etcdctl)+ RepoUpdate(yum clean all+makecache 全量重建)。
• 代码:RepoUpdate 在 26.06 与 rc.2 逐字相同(共有慢点),master !492 已改 120s 超时+跳过 clean all;其余脚本链增量为 26.09 新增内容。
• 复核结论:v2 四场景 26/39/24/24s ≈ v1 旧机 25/38/23/25s(同版本跨硬件几乎不变),26.09 为 47/63/47/50s —— +21~26s 是纯版本差异,硬件零影响。

根因 3:组件就绪判定 Running → Running+Ready(+29~36s)

• 现象:管理集群创建流中 cluster-api 组件等待从 ~50s 涨到 ~84s。
• 代码:!310 把等待判定从 Phase==Running 收紧为 Running 且 PodReady=True(必须过 readiness 探针,Service Endpoints 才会填充),等待范围新增 cluster-system,并加 10min deadline(旧版是无 deadline 死循环)。
• 复核结论:26.06 旧机 47-54s → 新机 54/49s → 26.09 83/85s,两轮幅度一致(+29~36s),复现。业务集群流无 cluster-api addon、无此回归——进一步印证因果。
• 评价:这是正确性的设计改进,不应回退;应整改的是根因 1 的轮询节奏与根因 4 的阻塞方式。

变快项与噪声相位(完整画面)

项	两轮结论
MasterInit"变快"	v2 降级为噪声相位:26.06 新机本身比旧机慢 17-18s(50~53s vs 32~45s),26.09 的 20~25s 相对两者都快;镜像预拉取并入 init 的方向真实存在,但幅度被硬件/运行噪声污染,不宜作为 26.09 的确定性收益宣传
calico addon 等待	两轮均 42~54s(v2 一次 84s 孤例为首次拉镜像),typha 1→3 无影响
集群删除 -55%、底噪 CPU -27%	rc.2 内真实改善(reset 强化/组件精简/日志降级),不受本轮复核影响
在线升级 3~5 分→1:51	组件 4→2(交付形态变化,非性能优化)

四、整改方向(按预期收益排序)

P0-1:安装期健康门禁恢复细粒度轮询(预期 -30~-90s/带管理面集群)

• 改法(按阶段覆盖,不建议全局调档):分级本身是合理的稳态设计,问题在于它被安装完成判定复用。EnsureCluster 完成判定路径(安装/扩容场景)使用短 requeue —— 恢复固定 10s,或"首轮后 5s 连续快查 3 轮再进分级档";稳态 reconcile 维持 30s/5m 档。实现上 ensureClusterReady 失败路径已知集群是否已首次 Ready,按该状态覆盖档位即可(等价于 health-check-config 增加 installing 覆盖档)。
• 配套(顺手修):把 metrics-server / local-harbor / oauth-server / console-service / monitoring / user-management / web-terminal 登记进 health-check-config(建议 important 档)——它们是安装完成定义的一部分,不应按"未登记→optional(30s)"兜底。注意此项单独只把 30s 降为 15s,收益减半,必须与阶段覆盖叠加。
• 不要做的:把 optional 档全局调回 10s。修正后的理由(经代码核实,替代早期"API 负载"的粗粒度表述):组件检查的 API 调用次数不随节点数增长(每组件每轮 1 次 namespace LIST,同轮缓存共享;Deployment 副本数固定),真实随节点数线性增长的是三处——GetNodes 响应体(128 节点对象)、kube-system LIST payload(calico-node/kube-proxy 为 DaemonSet,各 128 pods)、controller 侧 128 goroutine 处理;且该负担仅在"组件异常窗口"存在(健康稳态走 normal 5m 档)。全局调档的代价 = 异常窗口内检查频率×3 × 线性放大的响应体/处理量,128 节点下的绝对量级未经实测。而按阶段覆盖只改安装完成判定路径,稳态行为零变化、零回归风险,机会成本不对称(安装等待期快查零成本,稳态需按长期成本设计),这才是反对全局调档的准确理由。
• 涉及:cluster-api-provider-bke ensure_cluster.go + config/health/health-check-config.yaml(!445 引入处)。
• 验证口径:门禁轮距回到 ~11s、带管理面创建的门禁段回落 30~90s;两轮样本已给出明确的 before/after 参照(25 轮@11.5s vs 12 轮@31s)。
• 配置修改路径(实施指引,经代码核实):档位当前值 critical 5s / important 15s / optional 30s / normal 5m;CheckClusterHealth 每次执行都实时 GET 被检集群的 ConfigMap bke-config/health-check-config(LoadHealthCheckConfig,无缓存)→ 运行时 kubectl edit cm 热改下一轮即生效,无需重启 provider;组件登记(补 metrics-server 等)也在此 CM 的 components 段热改。两个陷阱:①迁移仅在 CM 缺失时发生,管理集群侧改动不会传播到存量业务集群的已有 CM,需逐集群修改;②解析失败静默落代码内兜底值(5/15/30/5m),改后须核对日志 health check config loaded, intervals ... 行确认新值生效。仓库源头 = capbke config/health/health-check-config.yaml(新装集群经迁移继承),建议与 fallbackHealthCheckConfig() 保持一致;installing 覆盖档需改代码(IntervalConfig 结构体 + 选档逻辑)。另:ClusterReady 判定是连续 3 轮检查全绿(runHealthChecks for 0..2)。

P0-2:RepoUpdate 优化(!492)cherry-pick 回 26.9 维护分支 + NodesEnv 脚本链瘦身(预期 -20~27s/场景)

• 改法:!492(master 已实现:120s 超时+跳过 clean all+best-effort)直接 cherry-pick;同时审计 EnsureNodesEnv 的脚本链(下载器/lxcfs/etcdctl/helm/calicoctl 串行执行),可并行的并行、可裁剪的裁剪,目标压回 26.06 水平(24~26s)以内。
• 涉及:bkeadm。

P1:管理面组件就绪提速(治本,与 P0-1 相乘)

• 改法:门禁失败清单反复出现的 metrics-server、local-harbor、oauth-server、console、monitoring 栈、user-management、web-terminal,逐个核对镜像体积与预拉取覆盖、readiness 探针初始延迟/周期、启动依赖。任一组件早 Ready 一分钟,门禁直接少一分钟。

预期收益合计

场景	相位级回归(v2 复核)	P0-1	P0-2	合计预期
业务集群创建(带管理面)	门禁 +90s	-60~-90s	-20~26s	反超 26.06
管理集群创建(带管理面)	门禁 +30s + addon +30s	-30~-60s	-20~26s	基本清零
无管理面两场景	NodesEnv +21~26s	≈0	-20~26s	反超

另注:master 已合入而 rc.2 未含的修复(!492/!491/!489/!118/!344)在下版基线自然体现;!482/!493 静态 pod 热更新新增两个串行相位(+10~60s),下轮基线解读需单列。

安装加速操作指导:健康检查档位热调(适用于 latest 版本)

适用对象:openFuyao latest 版本(26.09-rc.2 及之后,含 master)的部署测试同学
收益预期:每个带管理面的集群创建,门禁等待段预计缩短约 2~3 分钟(管理集群创建 9:12→约 6~7 分,业务集群 8:37→约 6 分量级)
是否改代码:否,只改一个 ConfigMap | 是否需要重启组件:否,下一轮健康检查自动生效
不适用:26.06 版本(26.06 本来就是固定 10s 轮询,无需也无法做本操作);本操作不影响引导节点 init 阶段耗时(那段不读这个配置)

---

一、背景(30 秒读完)

latest 版本把集群"安装完成健康检查"的重试节奏从固定 10 秒改成了按组件分级(critical 5s / important 15s / 其余 30s)。安装要等的 metrics-server、harbor、oauth-server、console 等组件不在登记名单里,全部按 30s 一轮被轮询,导致每个带管理面的集群创建在最后"等所有组件就绪"的阶段多花 1~3 分钟。

这个节奏存在一个 ConfigMap 里,每次健康检查都会实时读取,所以装完引导节点后改一处,后面创建的管理集群、业务集群会自动继承,全程不用改代码、不用重启任何组件。

二、什么时候操作

时机(关键):bke init 成功完成后、执行第一条 bke cluster create(创建管理集群)之前。

原理:创建管理集群时,管理集群上还没有这个配置,系统会自动从引导节点复制一份过去;创建业务集群时又会从管理集群复制。所以只要源头(引导节点)改了,整条链自动继承。

引导节点(你改这里) ──复制──> 管理集群 ──复制──> 业务集群(自动继承)

三、操作步骤(逐步可复制)

步骤 1:在引导节点上修改配置

登录引导节点 root,执行:

kubectl edit configmap health-check-config -n bke-config

在编辑器里找到 intervals: 段,改成:

    intervals:
      critical: 5s
      important: 10s
      optional: 10s
      normal: 5m

说明:critical 保持 5s 不动;important 和 optional 都调到 10s(即恢复到 26.06 的实际节奏)。normal: 5m 是集群正常后稳态巡检的间隔,不要改,它是底噪收益的来源之一。

保存退出(kubectl edit 即改即存)。

步骤 2:在引导节点上验证生效

kubectl get cm health-check-config -n bke-config -o jsonpath='{.data.config\.yaml}' | head -10

确认 optional: 10s 已出现。

步骤 3:正常创建管理集群(流程不变)

bke cluster create -f /bke/cluster/1master-cluster.yaml -n 1master-node.yaml

创建完成后,到管理集群 master 上验证继承结果:

kubectl get cm health-check-config -n bke-config -o jsonpath='{.data.config\.yaml}' | grep optional
# 预期输出:optional: 10s

步骤 4:创建业务集群(流程不变)

业务集群会自动从管理集群继承同样的配置,无需任何额外操作。如需核验,在业务集群 master 上执行与步骤 3 相同的 kubectl get cm ... | grep optional。

四、怎么确认加速有效(建议记录的数据)

在管理集群 master 上(或用采集到的日志),对照两次创建的门禁段:

# 方法 A:看 provider 日志的重试间距
grep "requeue after" /var/log/openFuyao/bke-controller*/*.log
# 改前:相邻两条间隔 ~31s;改后:应变为 ~11s

# 方法 B:看健康检查读取到的档位
grep "health check config loaded" /var/log/openFuyao/bke-controller*/*.log | tail -1
# 应显示 intervals critical=5s important=10s optional=10s normal=5m

# 方法 C:对比创建总时长(秒表或日志),记录改前/改后各一轮

把改前/改后的总时长各记一轮发回来,就能量化这条优化的实际收益。

五、回退方法

# 在对应的集群上(引导/管理/业务,视改了哪些)执行:
kubectl edit configmap health-check-config -n bke-config
# 把 intervals 恢复为:critical: 5s / important: 15s / optional: 30s / normal: 5m

下一轮健康检查即恢复原节奏。若要彻底恢复出厂,也可 kubectl delete cm health-check-config -n bke-config——下一轮 reconcile 会从上游(管理集群/引导节点)重新复制一份,注意:上游若还是改过的值,复制回来的也是改过的值,所以回退要改源头。

六、常见问题(FAQ)

Q1:改完没效果?
先看 health check config loaded 日志行(位置见步骤 4 方法 B)显示的 intervals 是不是新值。如果显示的还是旧值或 5s/15s/30s/5m:①CM 没保存成功,重新 edit;②CM 的 yaml 写坏了导致解析失败,系统会静默回落到内置默认值——检查 jsonpath 输出的 yaml 是否合法(缩进、单位 s/m)。

Q2:在管理集群上改了,业务集群会自动跟吗?
不会自动同步已存在的配置——跨集群复制只发生在"目标集群还没有这份配置"的时候。所以要么按本指导只改引导节点源头(让新集群在创建时继承),要么对已存在的集群逐个 edit。

Q3:这个改法有什么副作用?
集群正常运行时巡检节奏(normal 5m)不变,无影响;仅当出现组件异常时,重试频率变为每 10 秒一轮(原 30 秒),检查开销略增。测试环境可忽略;生产环境建议恢复默认值,或推动将"安装期快查"作为正式能力开发(见性能分析报告 P0-1)。

Q4:为什么 26.06 不需要做这个?
26.06 的健康检查本来就是固定 10 秒一轮,已经是加速后的状态;该操作本质上是把 latest 拉回 26.06 的门禁节奏。

Q5:改了之后安装会不会变快但不完整?
不会。检查频率只影响"多快发现组件就绪",组件没就绪照样等,ClusterReady 仍要求连续 3 轮检查全绿,判定标准没有被放松。

---