尧图网站建设 
云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载KubeVela 内置的garbage-collect策略Policy用于控制 Application 生命周期内资源的回收时机与方式例如在应用更新时保留不再使用的旧资源、或让某类 trait 生成的资源只在应用删除时才被回收。读完本文你将掌握keepLegacyResource、rulesselector strategy propagation两种配置模式的完整写法理解底层基于 ResourceTracker 的三阶段 GC 执行原理并能在自己的 Application 中直接套用可运行的配置示例。什么是 garbage-collect 策略在 KubeVela 中Application 的spec.policies区域可以声明一类名为garbage-collect的治理策略内置策略类型garbage-collect定义见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go 中的GarbageCollectPolicyType常量。它解决的核心问题是当 Application 被更新产生新版本或删除时由 KubeVela 管控的那些资源应该如何处置。默认情况下KubeVela 会在应用更新后自动回收旧版本遗留的资源并在应用删除时级联清理全部管控资源。但某些场景并不希望如此灰度/回滚场景更新时误删旧版本资源可能导致回滚失败希望保留旧资源有状态数据某些由 trait 生成的资源如 Ingress、PVC 等在组件更新后不应立即删除而应保留到应用整体删除时才清理精细化管控只对特定组件、特定 trait 或特定类型的资源应用不同的回收策略。garbage-collect策略通过两种配置粒度解决上述问题全局级的keepLegacyResource开关以及资源级的rules规则列表。官方文档示例位于 references/docgen/def-doc/policy/garbage-collect.eg.md本文以该文档为骨架结合仓库源码与测试展开详解。全局模式keepLegacyResource 保留旧版本资源当你在 Application 更新时希望不回收旧版本遗留资源例如回滚备份、临时保留上一版 workload可以按下面的方式声明策略来自原文档示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: first-vela-app spec: components: - name: express-server type: webservice properties: image: oamdev/hello-world port: 8000 traits: - type: ingress-1-20 properties: domain: testsvc.example.com http: /: 8000 policies: - name: keep-legacy-resource type: garbage-collect properties: keepLegacyResource: true要点说明type固定为garbage-collectproperties.keepLegacyResource: true是核心开关。置为true后过期的带版本 ResourceTracker 将不会被自动回收其管辖的旧资源会一直保留直到对应 ResourceTracker 被手动删除该模式是全局生效的影响所有组件与 trait 生成的资源。从源码实现看keepLegacyResource对应 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go 中GarbageCollectPolicySpec.KeepLegacyResource字段其注释明确说明开启后 outdated 的版本化 ResourceTracker 不会被自动回收资源将保留至 ResourceTracker 被手动删除。在 pkg/resourcekeeper/gc.go 的buildGCConfig中当该字段为true时会追加PassiveGCOption{}将 GC 切换为被动模式scan阶段只有在新旧资源确认“完全移交”旧资源不存在或已由最新 ResourceTracker 接管时才以MarkWithProbability 0.1的概率标记过期 ResourceTracker 回收从而显著降低误删旧资源的风险。资源级模式rules 规则精细化回收如果只想对特定资源如某类 trait、某类组件定制回收策略可以使用rules。官方文档给出了完整示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: garbage-collect-app spec: components: - name: hello-world-new type: webservice properties: image: oamdev/hello-world traits: - type: expose properties: port: [8000] policies: - name: garbage-collect type: garbage-collect properties: rules: - selector: traitTypes: - expose strategy: onAppDelete这段配置的含义是由expose这类 trait 生成的资源在组件/应用更新时不被回收只有整个 Application 被删除时才回收。当组件hello-world-new再次更新时旧的 expose 相关资源如 Service不会像默认行为那样被立刻清理从而避免流量中断。rules中的每条规则由三个字段构成定义见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go 的GarbageCollectPolicyRule字段必填说明selector是资源选择器声明本规则作用的目标资源集合strategy是回收策略可选never/onAppDelete/onAppUpdatepropagation否删除传播方式可选orphan/cascading多条规则的匹配顺序如果某个资源同时被多条规则命中第一条匹配的规则生效FindStrategy按rules顺序遍历见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go因此声明规则时要把更具体的规则放在前面。selector 选择器六种匹配维度与 AND 组合逻辑selector基于 apis/core.oam.dev/v1alpha1/resource_policy_types.go 中的ResourcePolicyRuleSelector实现支持六个匹配维度selector 字段匹配依据典型取值componentNames组件名称labelapp.oam.dev/componenthello-world-newcomponentTypes组件类型workload 类型 labelwebserviceoamTypesOAM 资源类型 labelCOMPONENT、TRAITtraitTypestrait 类型 labelexpose、ingressresourceTypes资源的 Kubernetes KindService、DeploymentresourceNames资源名称my-svc匹配逻辑要点来自Match实现与 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types_test.go 的用例验证多条件 AND同一 selector 内同时填写多个维度时所有非空条件必须同时满足才命中至少一个条件命中如果填写的维度全部匹配成功则规则命中一个都没命中则规则不适用未填写的维度不参与判断视为不限制测试用例覆盖了 trait 类型匹配/不匹配、组件类型匹配、组件名称匹配、OAM 资源类型匹配以及“同一资源同时命中组件类型与 trait 类型规则时取第一条规则”等场景可用于验证自己的 selector 写法。三种回收策略的取舍strategy决定目标资源的回收时机枚举定义于 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.gostrategy行为适用场景never永不回收目标资源资源在应用删除后也保留保存审计数据、持久化产物onAppDelete应用更新时不回收只有整个 Application 被删除时才回收保持 Service/Ingress 在更新期间不中断流量如官方文档中的expose示例onAppUpdate资源不在最新版本中使用inUse 判定为 false时即回收默认的按版本清理行为控制资源数量需要注意onAppDelete意味着即使资源已不在最新版本中被引用它也会一直保留到应用删除因此长期存在的应用会积累历史版本资源需要结合applicationRevisionLimit等参数权衡。在实现层面删除资源时 pkg/resourcekeeper/delete.go 会调用h.garbageCollectPolicy.FindStrategy(manifest)为每个待删除的 manifest 查找匹配策略并把策略包装成GarbageCollectStrategyOption传入删除流程无匹配规则时走默认回收行为。传播方式 propagationorphan 与 cascadingpropagation控制删除目标资源时其子资源的处理方式语义与 Kubernetes 的DeletionPropagation对齐propagation行为orphan孤儿删除删除目标资源但保留其子资源cascading级联删除在后台删除目标资源及其子资源源码中FindDeleteOption会将orphan映射为metav1.DeletePropagationOrphan、将cascading映射为metav1.DeletePropagationBackground见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go。例如想删除某 Deployment 但保留其关联的 PVC可以在对应规则中设置propagation: orphan。其他重要参数applicationRevisionLimit / continueOnFailure / order除keepLegacyResource与rules外garbage-collect策略还支持以下参数同样定义在GarbageCollectPolicySpec中applicationRevisionLimitint可选为该 Application 单独设置保留的 ApplicationRevision 数量上限覆盖全局配置。底层由 pkg/resourcekeeper/gc_rev.go 的cleanUpApplicationRevision执行按版本号排序后超出「limit 正在使用的 revision 数」的旧 revision 会被清理。continueOnFailurebool可选默认 GC 只在工作流workflow执行成功后进行置为true后即使工作流失败也会继续执行 GC。对应 pkg/resourcekeeper/gc.go 中PhaseFrom(ctx) common.ApplicationWorkflowFailed时的处理逻辑——它会移除DisableMarkStageGCOption允许在失败阶段执行 Mark 阶段。orderstring可选指定回收顺序。目前支持dependency即按组件依赖关系回收先回收没有依赖者引用的独立组件资源再回收依赖方deleteIndependentComponent会结合DependsOn与 Inputs/Outputs 引用关系判断依赖避免先删父资源导致依赖方清理失败。底层原理ResourceTracker 三阶段垃圾回收garbage-collect策略最终作用于 KubeVela 控制器的 GC 主流程实现在 pkg/resourcekeeper/gc.go 的GarbageCollect中整个过程分为三个阶段Mark 阶段标记控制器找出所有目标 Application 的 ResourceTracker决定哪些应被删除。规则包括根 RT 与当前 RT 仅在应用本身被删除DeletionTimestamp非空时标记历史 RT 在 GC 非被动模式或其所管理资源已全部回收时标记。该阶段每次 reconcile 都会执行。Sweep 阶段清扫检查被标记删除的 ResourceTracker当其管理资源全部回收成功后移除其 finalizer。Finalize 阶段终结真正回收被标记删除的 ResourceTracker 所管理的全部资源按配置的 order 顺序或默认顺序逐个删除。其中keepLegacyResource: true会切换到被动模式使历史 RT 只有在资源确认不再被使用后才可能被标记回收。整个流程受garbageCollectPolicy中各字段驱动buildGCConfig组装配置这解释了前文所有参数为何能影响资源回收结果。小结garbage-collect策略是 KubeVela 应用生命周期治理的重要内置策略全局粒度keepLegacyResource: true让旧版本资源随版本化 ResourceTracker 一起保留适合需要回滚兜底的场景资源粒度rules通过selector组件名/组件类型/OAM 类型/trait 类型/资源类型/资源名多条件 ANDstrategynever/onAppDelete/onAppUpdatepropagationorphan/cascading实现精准回收控制进阶参数applicationRevisionLimit控制 revision 保留数量continueOnFailure允许工作流失败时仍执行 GCorder: dependency按依赖顺序安全回收原理支撑所有配置最终作用于 ResourceTracker 三阶段 GCMark/Sweep/Finalize相关实现与测试可在 pkg/resourcekeeper/gc.go、pkg/resourcekeeper/delete.go、apis/core.oam.dev/v1alpha1/garbagecollect_policy_types_test.go 中深入研读。将官方文档中的两个示例keepLegacyResource与rules onAppDelete直接应用到自己的 Application 中即可快速获得可控、可回滚的应用资源回收能力。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐uutils coreutils factor 基准测试实践指南微基准设计、理想化条件与可复现性能评估uutils coreutils factor 基准测试实践指南微基准设计、理想化条件与可复现性能评估 factor 是 GNU coreutils 中用于输云原生DevOps运维微服务Game Concept: [Working Title]Game Concept: Working Title Created: Date Status: Draft / Under Review / Approve云原生DevOps运维微服务KubeVela ApplyOnce 策略实战用 apply-once 策略精细控制配置漂移与资源回收行为KubeVela ApplyOnce 策略实战用 apply once 策略精细控制配置漂移与资源回收行为 KubeVela 的 Application 控制云原生DevOps运维微服务上一篇如何永久保存微信聊天记录三步打造你的专属数字记忆库下一篇单图 0.5 秒生成 3D 网格TripoSR 调参笔记创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KubeVela garbage-collect 策略详解：用 keepLegacyResource 与 rules 精细化控制应用资源回收
云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载KubeVela 内置的garbage-collect策略Policy用于控制 Application 生命周期内资源的回收时机与方式例如在应用更新时保留不再使用的旧资源、或让某类 trait 生成的资源只在应用删除时才被回收。读完本文你将掌握keepLegacyResource、rulesselector strategy propagation两种配置模式的完整写法理解底层基于 ResourceTracker 的三阶段 GC 执行原理并能在自己的 Application 中直接套用可运行的配置示例。什么是 garbage-collect 策略在 KubeVela 中Application 的spec.policies区域可以声明一类名为garbage-collect的治理策略内置策略类型garbage-collect定义见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go 中的GarbageCollectPolicyType常量。它解决的核心问题是当 Application 被更新产生新版本或删除时由 KubeVela 管控的那些资源应该如何处置。默认情况下KubeVela 会在应用更新后自动回收旧版本遗留的资源并在应用删除时级联清理全部管控资源。但某些场景并不希望如此灰度/回滚场景更新时误删旧版本资源可能导致回滚失败希望保留旧资源有状态数据某些由 trait 生成的资源如 Ingress、PVC 等在组件更新后不应立即删除而应保留到应用整体删除时才清理精细化管控只对特定组件、特定 trait 或特定类型的资源应用不同的回收策略。garbage-collect策略通过两种配置粒度解决上述问题全局级的keepLegacyResource开关以及资源级的rules规则列表。官方文档示例位于 references/docgen/def-doc/policy/garbage-collect.eg.md本文以该文档为骨架结合仓库源码与测试展开详解。全局模式keepLegacyResource 保留旧版本资源当你在 Application 更新时希望不回收旧版本遗留资源例如回滚备份、临时保留上一版 workload可以按下面的方式声明策略来自原文档示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: first-vela-app spec: components: - name: express-server type: webservice properties: image: oamdev/hello-world port: 8000 traits: - type: ingress-1-20 properties: domain: testsvc.example.com http: /: 8000 policies: - name: keep-legacy-resource type: garbage-collect properties: keepLegacyResource: true要点说明type固定为garbage-collectproperties.keepLegacyResource: true是核心开关。置为true后过期的带版本 ResourceTracker 将不会被自动回收其管辖的旧资源会一直保留直到对应 ResourceTracker 被手动删除该模式是全局生效的影响所有组件与 trait 生成的资源。从源码实现看keepLegacyResource对应 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go 中GarbageCollectPolicySpec.KeepLegacyResource字段其注释明确说明开启后 outdated 的版本化 ResourceTracker 不会被自动回收资源将保留至 ResourceTracker 被手动删除。在 pkg/resourcekeeper/gc.go 的buildGCConfig中当该字段为true时会追加PassiveGCOption{}将 GC 切换为被动模式scan阶段只有在新旧资源确认“完全移交”旧资源不存在或已由最新 ResourceTracker 接管时才以MarkWithProbability 0.1的概率标记过期 ResourceTracker 回收从而显著降低误删旧资源的风险。资源级模式rules 规则精细化回收如果只想对特定资源如某类 trait、某类组件定制回收策略可以使用rules。官方文档给出了完整示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: garbage-collect-app spec: components: - name: hello-world-new type: webservice properties: image: oamdev/hello-world traits: - type: expose properties: port: [8000] policies: - name: garbage-collect type: garbage-collect properties: rules: - selector: traitTypes: - expose strategy: onAppDelete这段配置的含义是由expose这类 trait 生成的资源在组件/应用更新时不被回收只有整个 Application 被删除时才回收。当组件hello-world-new再次更新时旧的 expose 相关资源如 Service不会像默认行为那样被立刻清理从而避免流量中断。rules中的每条规则由三个字段构成定义见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go 的GarbageCollectPolicyRule字段必填说明selector是资源选择器声明本规则作用的目标资源集合strategy是回收策略可选never/onAppDelete/onAppUpdatepropagation否删除传播方式可选orphan/cascading多条规则的匹配顺序如果某个资源同时被多条规则命中第一条匹配的规则生效FindStrategy按rules顺序遍历见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go因此声明规则时要把更具体的规则放在前面。selector 选择器六种匹配维度与 AND 组合逻辑selector基于 apis/core.oam.dev/v1alpha1/resource_policy_types.go 中的ResourcePolicyRuleSelector实现支持六个匹配维度selector 字段匹配依据典型取值componentNames组件名称labelapp.oam.dev/componenthello-world-newcomponentTypes组件类型workload 类型 labelwebserviceoamTypesOAM 资源类型 labelCOMPONENT、TRAITtraitTypestrait 类型 labelexpose、ingressresourceTypes资源的 Kubernetes KindService、DeploymentresourceNames资源名称my-svc匹配逻辑要点来自Match实现与 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types_test.go 的用例验证多条件 AND同一 selector 内同时填写多个维度时所有非空条件必须同时满足才命中至少一个条件命中如果填写的维度全部匹配成功则规则命中一个都没命中则规则不适用未填写的维度不参与判断视为不限制测试用例覆盖了 trait 类型匹配/不匹配、组件类型匹配、组件名称匹配、OAM 资源类型匹配以及“同一资源同时命中组件类型与 trait 类型规则时取第一条规则”等场景可用于验证自己的 selector 写法。三种回收策略的取舍strategy决定目标资源的回收时机枚举定义于 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.gostrategy行为适用场景never永不回收目标资源资源在应用删除后也保留保存审计数据、持久化产物onAppDelete应用更新时不回收只有整个 Application 被删除时才回收保持 Service/Ingress 在更新期间不中断流量如官方文档中的expose示例onAppUpdate资源不在最新版本中使用inUse 判定为 false时即回收默认的按版本清理行为控制资源数量需要注意onAppDelete意味着即使资源已不在最新版本中被引用它也会一直保留到应用删除因此长期存在的应用会积累历史版本资源需要结合applicationRevisionLimit等参数权衡。在实现层面删除资源时 pkg/resourcekeeper/delete.go 会调用h.garbageCollectPolicy.FindStrategy(manifest)为每个待删除的 manifest 查找匹配策略并把策略包装成GarbageCollectStrategyOption传入删除流程无匹配规则时走默认回收行为。传播方式 propagationorphan 与 cascadingpropagation控制删除目标资源时其子资源的处理方式语义与 Kubernetes 的DeletionPropagation对齐propagation行为orphan孤儿删除删除目标资源但保留其子资源cascading级联删除在后台删除目标资源及其子资源源码中FindDeleteOption会将orphan映射为metav1.DeletePropagationOrphan、将cascading映射为metav1.DeletePropagationBackground见 apis/core.oam.dev/v1alpha1/garbagecollect_policy_types.go。例如想删除某 Deployment 但保留其关联的 PVC可以在对应规则中设置propagation: orphan。其他重要参数applicationRevisionLimit / continueOnFailure / order除keepLegacyResource与rules外garbage-collect策略还支持以下参数同样定义在GarbageCollectPolicySpec中applicationRevisionLimitint可选为该 Application 单独设置保留的 ApplicationRevision 数量上限覆盖全局配置。底层由 pkg/resourcekeeper/gc_rev.go 的cleanUpApplicationRevision执行按版本号排序后超出「limit 正在使用的 revision 数」的旧 revision 会被清理。continueOnFailurebool可选默认 GC 只在工作流workflow执行成功后进行置为true后即使工作流失败也会继续执行 GC。对应 pkg/resourcekeeper/gc.go 中PhaseFrom(ctx) common.ApplicationWorkflowFailed时的处理逻辑——它会移除DisableMarkStageGCOption允许在失败阶段执行 Mark 阶段。orderstring可选指定回收顺序。目前支持dependency即按组件依赖关系回收先回收没有依赖者引用的独立组件资源再回收依赖方deleteIndependentComponent会结合DependsOn与 Inputs/Outputs 引用关系判断依赖避免先删父资源导致依赖方清理失败。底层原理ResourceTracker 三阶段垃圾回收garbage-collect策略最终作用于 KubeVela 控制器的 GC 主流程实现在 pkg/resourcekeeper/gc.go 的GarbageCollect中整个过程分为三个阶段Mark 阶段标记控制器找出所有目标 Application 的 ResourceTracker决定哪些应被删除。规则包括根 RT 与当前 RT 仅在应用本身被删除DeletionTimestamp非空时标记历史 RT 在 GC 非被动模式或其所管理资源已全部回收时标记。该阶段每次 reconcile 都会执行。Sweep 阶段清扫检查被标记删除的 ResourceTracker当其管理资源全部回收成功后移除其 finalizer。Finalize 阶段终结真正回收被标记删除的 ResourceTracker 所管理的全部资源按配置的 order 顺序或默认顺序逐个删除。其中keepLegacyResource: true会切换到被动模式使历史 RT 只有在资源确认不再被使用后才可能被标记回收。整个流程受garbageCollectPolicy中各字段驱动buildGCConfig组装配置这解释了前文所有参数为何能影响资源回收结果。小结garbage-collect策略是 KubeVela 应用生命周期治理的重要内置策略全局粒度keepLegacyResource: true让旧版本资源随版本化 ResourceTracker 一起保留适合需要回滚兜底的场景资源粒度rules通过selector组件名/组件类型/OAM 类型/trait 类型/资源类型/资源名多条件 ANDstrategynever/onAppDelete/onAppUpdatepropagationorphan/cascading实现精准回收控制进阶参数applicationRevisionLimit控制 revision 保留数量continueOnFailure允许工作流失败时仍执行 GCorder: dependency按依赖顺序安全回收原理支撑所有配置最终作用于 ResourceTracker 三阶段 GCMark/Sweep/Finalize相关实现与测试可在 pkg/resourcekeeper/gc.go、pkg/resourcekeeper/delete.go、apis/core.oam.dev/v1alpha1/garbagecollect_policy_types_test.go 中深入研读。将官方文档中的两个示例keepLegacyResource与rules onAppDelete直接应用到自己的 Application 中即可快速获得可控、可回滚的应用资源回收能力。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐uutils coreutils factor 基准测试实践指南微基准设计、理想化条件与可复现性能评估uutils coreutils factor 基准测试实践指南微基准设计、理想化条件与可复现性能评估 factor 是 GNU coreutils 中用于输云原生DevOps运维微服务Game Concept: [Working Title]Game Concept: Working Title Created: Date Status: Draft / Under Review / Approve云原生DevOps运维微服务KubeVela ApplyOnce 策略实战用 apply-once 策略精细控制配置漂移与资源回收行为KubeVela ApplyOnce 策略实战用 apply once 策略精细控制配置漂移与资源回收行为 KubeVela 的 Application 控制云原生DevOps运维微服务上一篇如何永久保存微信聊天记录三步打造你的专属数字记忆库下一篇单图 0.5 秒生成 3D 网格TripoSR 调参笔记创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考