云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载KubeVela 的resource-update策略Policy允许用户在 Application 级别为选定资源自定义更新行为既可以通过recreateFields让特定字段变化时触发整资源重建recreate也可以将默认的三方合并补丁patch升级为整对象替换replace。本文以 官方文档 为主体结合 KubeVela 源码与测试讲解该策略的完整配置方式、字段语义、底层实现原理与适用场景。为什么需要 resource-update 策略KubeVela Application 在每次部署时会通过 ResourceKeeper 将组件渲染出的资源统一 dispatch 到目标集群见 pkg/resourcekeeper/resourcekeeper.go。默认情况下资源更新走“三方合并补丁”three-way merge patch只修改由 KubeVela Application 管理的字段集群中其他实体如其他控制器、人工改动写入的字段会原样保留。但在实际生产中这种“温柔”的默认行为并不总是符合需求某些资源例如Secret字段一旦被修改就可能产生不可预期的行为KubeVela 需要在其受管字段变化时直接删除并重建该资源某些资源需要被整体覆盖任何未被 Application 管理的字段都应被抹除而不是保留某些资源例如v1/Service由系统控制器自动填充 spec 字段不适合整对象替换。resource-update策略正是为这类场景而生它以规则rule为单位通过选择器精准命中目标资源再为其指定更新策略实现“资源粒度”的更新行为定制。策略定义与配置骨架resource-update是一个内置 PolicyDefinition其 CUE 模板定义位于 vela-templates/definitions/internal/policy/resource-update.cue对应的部署产物为 charts/vela-core/templates/defwithtemplate/resource-update.yaml。策略类型常量ResourceUpdatePolicyType resource-update定义在 apis/core.oam.dev/v1alpha1/resource_update_policy_types.go。一个完整的 Application 配置骨架如下apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-app spec: components: # ... 组件定义 policies: - type: resource-update name: resource-update properties: rules: - selector: componentNames: [my-comp] # 可选按组件名选择 componentTypes: [k8s-objects] # 可选按组件类型选择 oamTypes: [COMPONENT, TRAIT] # 可选按 OAM 类型选择 traitTypes: [scaler] # 可选按 Trait 类型选择 resourceTypes: [Deployment] # 可选按资源类型选择如 Secret、ConfigMap resourceNames: [my-deploy] # 可选按资源名称选择 strategy: op: patch # 可选默认 patch可填 replace recreateFields: [data.key] # 可选字段变化时触发重建策略的properties.rules是规则列表每条规则由两部分组成selector规则选择器选择器支持六种维度均为可选的字符串数组语义为“命中任一即匹配”字段说明componentNames按组件名称选择资源componentTypes按组件类型选择资源oamTypes按 OAM 类型选择值为COMPONENT或TRAITtraitTypes按 Trait 类型选择资源resourceTypes按资源类型选择如Deployment、Secret、ConfigMapresourceNames按资源名称选择这些字段对应 Go 类型ResourcePolicyRuleSelector与 pkg/resourcekeeper/utils.go 中的匹配逻辑一一对应。strategy更新策略字段类型默认值说明opstringpatch更新操作符patch三方合并补丁或replace整对象替换recreateFields[...string]空指定字段路径如data.key字段发生变化时触发资源重建从 CUE 模板可见op: *patch | replace使用默认值语法即未显式指定时默认为patchrecreateFields为可选字段。场景一字段变化触发资源重建recreateFields最典型的场景是管理 Kubernetes 中不可就地更新的资源例如带immutable: true的Secret。原始文档给出了如下示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: recreate spec: components: - type: k8s-objects name: recreate properties: objects: - apiVersion: v1 kind: Secret metadata: name: recreate data: key: dgo immutable: true policies: - type: resource-update name: resource-update properties: rules: - selector: resourceTypes: [Secret] strategy: recreateFields: [data.key]通过指定recreateFields: [data.key]当 Application 渲染出的 Secret 的data.key字段与集群中的现有值不一致时KubeVela 会先删除、再重建该 Secret如果字段未变化则走正常更新默认 patch。重建判定的底层实现重建判定逻辑位于 pkg/utils/apply/apply.go 的needRecreate函数apply.go 附近将existing与desired两个对象分别转换为非结构化unstructured数据遍历recreateFields中的每个字段路径用 Kubernetes 的fieldpath.Pave(...).GetValue(field)从现有对象中取出对应值若字段路径取值失败直接返回错误说明路径不合法或对象结构不符逐字段比较新旧值任一字段发生变化即判定需要重建。触发重建后apply.go会先删除现有对象若其DeletionTimestamp为空再调用Create创建期望对象同时代码注释明确说明recreate does not support dryrun即该分支不支持 dry-run 预览。字段路径语法recreateFields使用 Kubernetes 标准字段路径语法例如data.key读取data映射下的keyspec.template.spec.containers[0].image读取首个容器的镜像顶层字段直接写字段名如immutable。选择器 字段路径的组合使 KubeVela 可以精确到“某个资源的某个字段变化才重建”极大降低不必要的重建频率。场景二整对象替换更新op: replace默认的patch基于三方合并只修改 Application 管理的字段而replace会把整个对象当作一个整体提交更新即使某字段并非由 KubeVela Application 管理也会一并被期望值覆盖抹除。原始文档的第二个示例apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: recreate spec: components: - type: k8s-objects name: recreate properties: objects: - apiVersion: v1 kind: ConfigMap metadata: name: recreate data: key: val policies: - type: resource-update name: resource-update properties: rules: - selector: resourceTypes: [ConfigMap] strategy: op: replace通过op: replaceKubeVela 对命中的 ConfigMap 采用整对象替换更新。可以将其理解为“Application 级别的ApplyResourceByReplace”——它把原本作为 FeatureGate见下文全局生效的替换行为收敛到单个 Application 内的具体资源上。replace 与 patch 的执行差异在 pkg/utils/apply/apply.go 的更新主流程中replace 分支将desired的ResourceVersion设置为现有对象的版本号后直接调用Update提交整个对象即“以期望对象整体覆盖现有对象”patch 分支调用三方 diff 计算补丁patcher.patch仅将差异字段打补丁到现有对象若补丁为空无差异则直接返回不产生任何 API 请求。与 ApplyResourceByReplace FeatureGate 的关系如果策略未显式指定op则 apply 逻辑会检查全局 FeatureGateApplyResourceByReplacepkg/features/controller_features.goFeatureGate 开启且目标资源属于可更新类型时默认行为变为replace否则默认回落到patch。值得注意的是isUpdatableResource做了特例处理apply.gov1/Service的 spec 会被 Service 控制器自动填充 IP 等字段因此即使开启该 FeatureGate 也不会被替换以避免破坏系统字段。这一特例同时说明op: replace并非在所有资源上都安全使用前需评估目标资源是否存在系统控制器写入的字段。规则匹配与分发链路resource-update策略在控制器运行时被解析并注入到每次资源下发中核心链路如下解析策略ResourceKeeper 在创建时调用parseApplicationResourcePolicypkg/resourcekeeper/resourcekeeper.go通过policy.ParsePolicy[v1alpha1.ResourceUpdatePolicySpec]从 Application 中解析出resourceUpdatePolicy对象命中规则下发每个 manifest 时getUpdateStrategypkg/resourcekeeper/utils.go调用resourceUpdatePolicy.FindStrategy(manifest)——遍历规则列表返回第一条命中选择器的策略apis/core.oam.dev/v1alpha1/resource_update_policy_types.go注入 ApplyOption在 pkg/resourcekeeper/dispatch.go 与 pkg/resourcekeeper/statekeep.go 中将命中的策略包装为apply.WithUpdateStrategy(*strategy)的 ApplyOption随 manifest 一起交给 Applicator执行更新Applicator 依据策略执行 recreate / replace / patch 三种路径上文所述。从源码结构可以看出该策略与read-only、take-over、apply-once等策略共享同一套 dispatch 扩展机制isReadOnly、canTakeOver、getUpdateStrategy等检查在 dispatch.go 中依次叠加 ApplyOption互不冲突、可组合使用。端到端验证e2e 测试用例仓库在 test/e2e-multicluster-test 中提供了完整的端到端验证测试数据 app-recreate-test.yaml 同时演示了recreateFieldsSecret 的data.key与op: replaceConfigMap两条规则且两条规则作用于同一个 Application 的不同资源证明规则列表可以并行生效测试用例Test application with resource-update policytest/e2e-multicluster-test/multicluster_test.go将该 YAML 解析后创建 Application验证策略在真实控制器链路中的行为。此外pkg/utils/apply/apply_resource_test.go 从单元测试层面对比了 patch 与 replace 的差异在外部修改 Deployment 增加一个容器后patch 模式会保留该外部新增容器而 replace 模式会将其抹除——这正是“三方补丁保留外部字段、替换整对象抹除外部字段”语义的直接证据。使用建议与注意事项recreateFields适用于不可就地更新的资源如immutable: true的 Secret、部分 CRD 字段。字段路径必须与现有对象结构匹配否则 apply 会直接报错请先用kubectl get确认实际字段结构op: replace是“强覆盖”语义它会抹掉非 Application 管理的字段请勿对v1/Service等系统控制器维护字段的资源使用也不建议对多控制器共享的 ConfigMap 随意使用规则列表按序匹配FindStrategy返回第一条命中的规则策略resource_update_policy_types.go如需“通用 patch 特殊 recreate”的叠加效果应将更具体的规则放在前面可与其它策略组合资源下发时 read-only、take-over、apply-once、resource-update 等策略的 ApplyOption 会同时叠加dispatch.go可按需组合版本前提本策略为 KubeVela 内置 PolicyDefinition随 vela-core 一起安装见 charts/vela-core/templates/defwithtemplate/resource-update.yaml使用kubectl apply部署 Application 即可无需额外安装组件。小结resource-update策略将资源更新行为从“全局统一”升级为“资源粒度可控”recreateFields解决字段变化需重建的场景op: replace提供整对象强覆盖的语义同时默认的patch依旧保留对非受管字段的友好性。理解其选择器、字段路径与底层 apply 三路分支能帮助你在 KubeVela 中精准编排各类资源的更新策略。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐GRBL-Plotter终极指南如何用免费开源软件控制你的CNC雕刻机GRBL Plotter终极指南如何用免费开源软件控制你的CNC雕刻机 GRBL Plotter是一款功能强大的开源G代码发送软件专为GRBL控制器设计支桌面应用智能硬件KubeVela ApplyOnce 策略实战用 apply-once 策略精细控制配置漂移与资源回收行为KubeVela ApplyOnce 策略实战用 apply once 策略精细控制配置漂移与资源回收行为 KubeVela 的 Application 控制云原生DevOps运维微服务terraform-provider-azurerm策略定义资源合规规则创建terraform provider azurerm策略定义资源合规规则创建 策略定义概述 策略定义Policy Definition是Azure资源管理基础设施DevOps云原生上一篇如何通过ALFWorld实现跨模态智能交互从零开始的五大实践维度下一篇serverless-ml-course实战信用卡欺诈检测系统开发全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考