让 Operator 调整副本
配置目标工作负载、副本上下界、扩缩容步长和冷却时间。模块和全局开关均授权 Auto 后,Operator 才依据有效建议执行。
直接在平台模块上管理:Operator 读取模块并写副本,不在集群里创建任何资源。同一个目标只能有一个副本所有者。
同一目标只有一个控制者
不能让 Operator 与 HPA、KEDA 或重复 scaler 同时写同一工作负载的副本。切换前先停止原控制器并释放控制权,再检查新控制器的观察结果。
为新 Pod 应用资源建议
准入路径只读取最新有效推荐,按配置调整新 Pod 的 CPU / 内存 requests,以及允许的 limits。推荐不可用时保留原资源,避免阻塞发布。
推荐更新不会立即改变运行中的 Pod。通过新建或滚动更新应用配置,调低内存 limits 前需单独评估和授权。
检查实际效果
在执行、准入及相关明细中查看建议、应用结果、暂停或失败原因。继续检查实际与 Ready 副本、负载和资源用量,区分配置提交成功与容量就绪。
扩容是否赶上了负载
在扩容记录中打开“扩容及时性”,查看及时率、迟到时长 P90、实时兜底占比、峰值低估 P90、预测范围与提前量之比,以及决策等待时间。每项显示样本量与判定;样本不足时为待积累,配置满足要求不等于扩容效果已经达标。
向上决策会结合后续实际负载与 Ready 副本,区分及时、偏晚和负载未到来。已评估的就绪与迟到时长反馈到后续提前量;当前这类结果评估针对扩容,不代表缩容效果。
失联期间的执行记录补报
Operator 先把上报放入发件箱,平台恢复后按发生顺序补报。设置 --report-spool-file 可写入挂载文件,部署清单提供 emptyDir:同一个 Pod 内容器重启可保留,Pod 被替换后不保证保留。
队列最多 10,000 条,超出丢最早记录并计数;平台明确拒绝的记录会被移除,避免阻塞后续记录。文件不是无限保留的审计存储。
执行记录可选列包括 record_id、动作时间、上报时间、决策来源、失联状态与 Operator 标识。平台按记录 ID 去重,迟到上报仍按实际发生时间归档。
Request、Limit 比例与 OOM 地板
模块配置 Limit 比例时,按最终 Request 计算:例如内存 Request 为 10 GiB,比例 1.2,Limit 为 12 GiB。OOM 系数抬高 Request 的保护地板,不再与 Limit 比例重复叠加。
准入询问携带 request_uid 和 operation 后才能关联调用来源并去重;没有请求 UID 的查询仍返回建议,但不生成准入记录。