Operator 运行时参数
OperatorRuntimeConfig 用于动态调整 disaster-operator 的运行时控制参数。它主要控制备份、恢复、容灾操作、容灾实例、数据同步、资源同步、存储仓库和集群管理等控制器中的超时、轮询、重试和 watchdog 行为。
这类参数面向平台管理员和运维人员。它不会替代业务资源自身的配置，例如单个备份、恢复或故障切换操作中的显式超时；它提供的是平台级默认值和控制器运行参数。
配置对象
operator 只读取管理命名空间中的 singleton 对象：
apiVersion: testudo.softcdata.com/v1
kind: OperatorRuntimeConfig
metadata:
name: default
namespace: disaster-system
spec: {}
约束：
metadata.name必须是default。metadata.namespace必须是 operator 管理命名空间，默认是disaster-system。- 其他名称或其他命名空间下的
OperatorRuntimeConfig不会影响运行参数。
生效优先级
运行时参数按以下优先级生效：
- 业务资源自身
spec，例如AppBackup.spec.timeout、AppRestore.spec.timeout、DisasterOperation.spec.timeoutMinutes、DisasterOperation.spec.retryPolicy。 - 容灾实例或策略中的业务默认值，例如
DisasterInstance.spec.operationTimeoutMinutes。 OperatorRuntimeConfig/default中的热加载配置。- operator 启动时环境变量或启动参数，例如兼容保留的
APPRESTORE_*环境变量。 - operator 内置默认值。
热加载行为
修改 OperatorRuntimeConfig/default 后，operator 会在该对象下一次 reconcile 时生成新的 runtime snapshot。已经启动的长流程不会被强制中断，但后续 reconcile、下一次 timeout 判断和下一次 requeue 计算会读取最新 snapshot。
热加载不是强实时。从 Kubernetes watch/cache 到具体控制器下一次 reconcile 会有延迟。
删除 OperatorRuntimeConfig/default 后，operator 会回退到启动时默认值和内置默认值。如果对象存在但参数不合法，operator 会保留最后一次有效 snapshot，并在对象 status 中写入 Invalid=True。
查看当前状态：
kubectl get operatorruntimeconfig default -n disaster-system
kubectl describe operatorruntimeconfig default -n disaster-system
校验与状态
CRD schema 只校验结构和基础类型。运行时范围、跨字段关系由 operator 校验。
不合法配置的行为：
- Kubernetes API server 可以保存对象。
- operator 不激活该 generation。
status.conditions中Ready=False、Invalid=True。status.activeGeneration仍保持最后一次成功激活的 generation。
常见非法值：
backupRuntime.pollInterval: 0soperationRuntime.defaultTimeoutMinutes: 0syncRuntime.historyRetention: 0instanceRuntime.transitionWatchdogTimeout小于instanceRuntime.minTransitionWatchdogTimeout
duration 使用 Kubernetes duration 格式，例如 5s、90s、10m、2h。
完整示例
apiVersion: testudo.softcdata.com/v1
kind: OperatorRuntimeConfig
metadata:
name: default
namespace: disaster-system
spec:
backupRuntime:
inProgressMaxWait: 2h
unknownMaxWait: 10m
pollInterval: 10s
restoreRuntime:
inProgressMaxWait: 1h
unknownMaxWait: 1h
inProgressPollInterval: 5s
unknownPollInterval: 10s
progressCompleteGrace: 5m
startupGrace: 5m
missingGrace: 90s
emptyStatusGrace: 5m
podVolumeRestorePendingMaxWait: 10m
retryBackoff: 15s
retryLimit: 1
retryLimitProgress: 1
retryLimitStartup: 1
retryLimitMissing: 2
retryLimitEmpty: 2
operationRuntime:
defaultTimeoutMinutes: 60
stepStartRequeue: 1s
stepRunningRequeue: 5s
defaultRetryInterval: 5s
instanceRuntime:
transitionWatchdogTimeout: 2m
minTransitionWatchdogTimeout: 30s
initializingRequeue: 10s
steadyRequeue: 60s
failedRequeue: 60s
syncRuntime:
schedulerUpdateTimeout: 30s
backupObserveRequeue: 2s
backupInProgressRequeue: 5s
historyMissingRequeue: 5s
restoreObserveRequeue: 10s
historyRetention: 20
storageRuntime:
requeueInterval: 10s
clusterRuntime:
reconcileInterval: 1m
deletionRetryInterval: 10s
veleroInstallTimeout: 10m
veleroZombieLockThreshold: 10m
backupRuntime
backupRuntime 影响 AppBackup 控制器对 Velero Backup 状态的观察、超时判断和轮询频率。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
backupRuntime.inProgressMaxWait | 2h | 1m 到 24h | Velero Backup 进入运行中状态后允许持续运行的最长时间。超过后，operator 会认为备份超时，并尝试终止该 Velero Backup，同时把 AppBackup 历史记录标记为失败。 |
backupRuntime.unknownMaxWait | 10m | 1m 到 24h | Velero Backup phase 为空或未知时允许等待的最长时间。用于处理 Backup 对象已经创建但状态长时间没有进入明确 phase 的情况。 |
backupRuntime.pollInterval | 10s | 1s 到 5m | 当最新备份仍处于进行中状态时，AppBackup 控制器下一次检查 Velero Backup 状态的间隔。 |
如果 AppBackup.spec.timeout 已设置，它会覆盖 inProgressMaxWait 和 unknownMaxWait。pollInterval 配得过小会增加管理集群和业务集群 API server 压力；inProgressMaxWait 配得过小可能导致大数据量备份被提前判定为超时。
restoreRuntime
restoreRuntime 影响 AppRestore 控制器对 Velero Restore 的运行超时、异常停滞检测、自动重试和下一次观察间隔。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
restoreRuntime.inProgressMaxWait | 1h | 1m 到 24h | Velero Restore 处于 InProgress 状态时允许持续运行的最长时间。超过后，operator 会按恢复超时处理，可能终止 restore 并清理待恢复资源。 |
restoreRuntime.unknownMaxWait | 1h | 1m 到 24h | Velero Restore phase 为空或未知时允许等待的最长时间。用于防止 restore 对象长时间没有有效状态。 |
restoreRuntime.inProgressPollInterval | 5s | 1s 到 5m | Restore 处于 InProgress 时下一次观察状态的 requeue 间隔。 |
restoreRuntime.unknownPollInterval | 10s | 1s 到 5m | Restore phase 为空或未知时下一次观察状态的 requeue 间隔。 |
restoreRuntime.progressCompleteGrace | 5m | 30s 到 24h | Velero Restore 进度已经显示全部对象恢复完成，但 phase 仍长时间停留在 InProgress 时的宽限时间。超过后，operator 会认为恢复进度停滞，并按自动重试或失败逻辑处理。 |
restoreRuntime.startupGrace | 5m | 30s 到 24h | Restore 创建后长时间没有 start 或 completion 状态时的启动宽限时间。超过后，operator 会认为 restore 启动停滞。 |
restoreRuntime.missingGrace | 90s | 30s 到 24h | 期望存在的 Velero Restore 对象缺失时的宽限时间。超过后，operator 会按 missing restore 停滞类型处理。 |
restoreRuntime.emptyStatusGrace | 5m | 30s 到 24h | Restore 对象存在但 status 长时间为空时的宽限时间。超过后，operator 会按 empty status 停滞类型处理。 |
restoreRuntime.podVolumeRestorePendingMaxWait | 10m | 1m 到 24h | PodVolumeRestore 长时间处于 pending 或未推进状态时允许等待的最长时间。用于识别 PVC 数据恢复卡住的场景。 |
restoreRuntime.retryBackoff | 15s | 1s 到 1h | 自动重试恢复前的等待时间，也用于重试后下一次 reconcile 的间隔。 |
restoreRuntime.retryLimit | 1 | 0 到 10 | 默认自动重试次数。设置后，如果未单独设置分类 retry limit，会作为各类恢复停滞重试次数的默认值。0 表示不自动重试。 |
restoreRuntime.retryLimitProgress | 1 | 0 到 10 | 针对进度已完成但 phase 仍停留在 InProgress 的恢复停滞类型，允许自动重试的次数。 |
restoreRuntime.retryLimitStartup | 1 | 0 到 10 | 针对恢复启动停滞或 Velero server starting 瞬时失败类型，允许自动重试的次数。 |
restoreRuntime.retryLimitMissing | 2 | 0 到 10 | 针对 Velero Restore 对象缺失类型，允许自动重试的次数。 |
restoreRuntime.retryLimitEmpty | 2 | 0 到 10 | 针对 Restore status 长时间为空类型，允许自动重试的次数。 |
如果 AppRestore.spec.timeout 已设置，它会覆盖 inProgressMaxWait 和 unknownMaxWait。各类 grace 时间配得过小，可能把 Velero 的短暂状态延迟误判为停滞。retryBackoff 和 poll interval 配得过小，会导致失败场景下频繁 reconcile。
operationRuntime
operationRuntime 影响 DisasterOperation 控制器，包括故障切换、反向保护、撤销、中止和演练等长流程步骤的默认超时、步骤状态轮询和重试间隔。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
operationRuntime.defaultTimeoutMinutes | 60 | 1 到 1440 | 当 DisasterOperation.spec.timeoutMinutes 未设置时，单个容灾操作使用的默认超时时间，单位是分钟。 |
operationRuntime.stepStartRequeue | 1s | 1s 到 5m | 某个操作步骤刚创建或刚启动后，控制器下一次检查步骤状态的间隔。 |
operationRuntime.stepRunningRequeue | 5s | 1s 到 5m | 某个操作步骤已经运行中时，控制器下一次检查步骤状态的间隔。 |
operationRuntime.defaultRetryInterval | 5s | 1s 到 1h | 当 DisasterOperation.spec.retryPolicy.retryIntervalSeconds 未设置或小于等于 0 时，操作失败重试的默认等待时间。 |
DisasterOperation.spec.timeoutMinutes 优先级高于 defaultTimeoutMinutes，DisasterOperation.spec.retryPolicy.retryIntervalSeconds 优先级高于 defaultRetryInterval。步骤 requeue 参数过小会增加控制器对 Kubernetes API 的访问频率。
instanceRuntime
instanceRuntime 影响 DisasterInstance 控制器对实例状态流转、长时间无进展 watchdog 和失败状态重试检查的频率。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
instanceRuntime.transitionWatchdogTimeout | 2m | 30s 到 24h | 容灾实例处于状态转换过程中，如果长时间没有观察到相关 operation 进展，超过该时间后会触发 watchdog 判断。 |
instanceRuntime.minTransitionWatchdogTimeout | 30s | 10s 到 1h | watchdog 超时时间的下限保护。即使实例自身配置了更小的 operationTimeoutMinutes 或运行时配置误设更小值，最终也不能低于该值。 |
instanceRuntime.initializingRequeue | 10s | 1s 到 10m | DisasterInstance 初始化阶段下一次 reconcile 的间隔。 |
instanceRuntime.steadyRequeue | 60s | 5s 到 30m | DisasterInstance 稳态阶段下一次常规检查的间隔。 |
instanceRuntime.failedRequeue | 60s | 5s 到 30m | DisasterInstance 失败阶段下一次重新检查的间隔。 |
如果 DisasterInstance.spec.operationTimeoutMinutes 大于 0，watchdog timeout 会优先使用该值换算出的分钟数。最终 watchdog timeout 会被 minTransitionWatchdogTimeout 兜底保护。transitionWatchdogTimeout 必须大于等于 minTransitionWatchdogTimeout。
syncRuntime
syncRuntime 同时影响 DataSync 和 ResourceSync 控制器，控制调度器更新、备份观察、恢复观察和历史记录保留。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
syncRuntime.schedulerUpdateTimeout | 30s | 1s 到 10m | DataSync 或 ResourceSync 更新底层调度器配置时使用的 context timeout。超过后本次调度器更新会失败并等待后续 reconcile。 |
syncRuntime.backupObserveRequeue | 2s | 1s 到 5m | 创建或触发备份后，等待观察备份对象和备份历史时的下一次 requeue 间隔。 |
syncRuntime.backupInProgressRequeue | 5s | 1s 到 5m | 底层备份仍在进行中时，下一次检查备份状态的间隔。 |
syncRuntime.historyMissingRequeue | 5s | 1s 到 5m | 期望的备份或恢复历史暂时没有同步到 status 时，下一次检查的间隔。 |
syncRuntime.restoreObserveRequeue | 10s | 1s 到 5m | 触发恢复后，等待观察恢复状态和恢复历史时的下一次 requeue 间隔。 |
syncRuntime.historyRetention | 20 | 1 到 500 | DataSync 和 ResourceSync status.history 最多保留的历史记录数量。超过后会裁剪旧记录。 |
historyRetention 过小会降低排障时可追溯的历史记录数量。observe/requeue 参数过小会让同步控制器更快发现状态变化，但也会增加 Kubernetes API 压力。
storageRuntime
storageRuntime 影响 StorageRepository 控制器对对象存储连通性、容量统计和 BackupStorageLocation 相关状态的周期性检查。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
storageRuntime.requeueInterval | 10s | 5s 到 1h | StorageRepository 每轮校验、状态同步或失败重试后的下一次 reconcile 间隔。 |
该值过小会增加对象存储 API、Kubernetes API 和控制器负载；该值过大则会降低存储配置变更、连通性恢复和容量状态刷新的可见速度。
clusterRuntime
clusterRuntime 影响 Cluster 控制器对业务集群连接、Velero 安装和删除流程的调谐。
| 参数 | 默认值 | 合法范围 | 作用 |
|---|---|---|---|
clusterRuntime.reconcileInterval | 1m | 10s 到 1h | Cluster 控制器常规状态检查和持续调谐的 requeue 间隔。 |
clusterRuntime.deletionRetryInterval | 10s | 1s 到 10m | 删除 Cluster 时，如果远端资源清理或 finalizer 处理未完成，下一次重试删除流程的间隔。 |
clusterRuntime.veleroInstallTimeout | 10m | 1m 到 2h | operator 执行 Velero Helm install 或 upgrade 命令时传入的 --timeout。只影响之后发起的安装或升级命令，不改变已经运行中的 Helm 命令。 |
clusterRuntime.veleroZombieLockThreshold | 10m | 5m 到 24h | 检测 Velero Helm release lock 或进行中状态是否长时间卡住的阈值。超过后控制器可以识别为疑似僵尸锁并进入相应处理逻辑。 |
veleroInstallTimeout 需要结合业务集群镜像拉取速度、节点规模和网络状况配置。veleroZombieLockThreshold 过小可能误判正常 Helm 操作，过大则会延迟发现卡住的安装或升级。
配置建议
- 不要把 requeue、poll、retry backoff 类参数统一压到很小。多个控制器同时高频 reconcile 会放大管理集群 API server 压力。
- timeout 和 grace 类参数应结合实际数据量、镜像拉取速度、跨集群网络和 Velero 插件性能配置。
- 自动重试次数过高可能掩盖真实配置错误，并持续消耗集群资源。
- 修改运行时参数前，建议先记录当前配置和 status，便于回滚。
- 生产环境建议先在测试环境验证，再逐项调小或调大，不要一次性修改大量参数。
回滚
回滚到启动默认值：
kubectl delete operatorruntimeconfig default -n disaster-system
回滚到上一个 YAML：
kubectl apply -f operator-runtime-config-backup.yaml
确认是否激活：
kubectl get operatorruntimeconfig default -n disaster-system \
-o jsonpath='{.status.activeGeneration}{"\n"}{.status.conditions}{"\n"}'