拓冰网站定制 
CLI开发工具云原生【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址https://gitcode.com/gh_mirrors/ku/kustomize点击查看免费下载导读Kustomize 的generatorOptions字段允许你全局调整configMapGenerator与secretGenerator的生成行为——包括是否禁用名称后的内容哈希后缀、是否批量注入 labels 与 annotations以及设置immutable属性。本文以仓库中的 generatorOptions.md 演示为主线结合 kustomize 源码与测试用例为你拆解每个选项的底层实现、合并优先级规则和实战验证方法。1. 什么是 Generator Options在 kustomize 的声明式配置体系中configMapGenerator与secretGenerator负责把literals、files、envs等键值对来源转译为 Kubernetes 的 ConfigMap 与 Secret 对象。默认情况下kustomize 会在生成资源的名称后面追加一个基于资源内容计算的哈希后缀例如my-configmap-bh645k7tmg并支持为生成资源统一附加 labels 与 annotations。generatorOptions正是用来修改这些默认行为的一组全局选项它定义在 api/types/generatoroptions.go字段包括字段类型说明disableNameSuffixHashbool设为true时禁用默认的在生成资源名称后追加内容哈希后缀行为labelsmap[string]string为所有生成资源添加的标签annotationsmap[string]string为所有生成资源添加的注解immutablebool设为true时为所有生成资源设置immutable: true与 kustomization 中其他配置一样这些选项对kustomize build输出的最终资源生效并且遵循全局选项 局部覆盖的合并模型详见第 5 节。2. 官方示例从零体验 generatorOptions仓库中的演示文档 examples/zh/generatorOptions.md英文原版见 examples/generatorOptions.md给出了一个完整可运行的示例。我们将其整理为可直接复制的脚本说明如何创建 kustomization、配置生成器选项并逐一验证效果。2.1 创建工作空间DEMO_HOME$(mktemp -d)2.2 创建带 ConfigMapGenerator 的 kustomizationcat $DEMO_HOME/kustomization.yaml EOF configMapGenerator: - name: my-configmap literals: - foobar - bazqux EOF这里configMapGenerator声明了一个名为my-configmap的 ConfigMap数据来自两条literalsfoobar与bazqux。2.3 添加 generatorOptionscat $DEMO_HOME/kustomization.yaml EOF generatorOptions: disableNameSuffixHash: true labels: kustomize.generated.resource: somevalue annotations: annotations.only.for.generated: othervalue EOF三个选项分别对应本文要讲解的三类行为不追加哈希后缀、添加 label、添加 annotation。2.4 运行 build 并验证结果运行kustomize build生成最终资源然后用三组断言逐一验证验证一名称没有哈希后缀test 1 \ $(kustomize build $DEMO_HOME | grep name: my-configmap$ | wc -l); \ echo $?如果没有配置disableNameSuffixHash: true生成的名称通常是my-configmap-hash形式例如my-configmap-bh645k7tmggrep name: my-configmap$将匹配不到任何行而禁用后缀后名称恰好为my-configmap因此匹配行数为 1test命令成功。验证二labelkustomize.generated.resource: somevalue存在test 1 \ $(kustomize build $DEMO_HOME | grep -A 1 labels | grep kustomize.generated.resource | wc -l); \ echo $?验证三annotationannotations.only.for.generated: othervalue存在test 1 \ $(kustomize build $DEMO_HOME | grep -A 1 annotations | grep annotations.only.for.generated | wc -l); \ echo $?最终生成的 ConfigMap 形态如下预期输出apiVersion: v1 data: baz: qux foo: bar kind: ConfigMap metadata: annotations: annotations.only.for.generated: othervalue labels: kustomize.generated.resource: somevalue name: my-configmap注意这三组验证脚本在文档中被标记为test/testAgainstLatestRelease是 kustomize 持续集成中实际运行的测试片段因此这套流程在不同版本的 kustomize 上都能复现。3. 选项一disableNameSuffixHash——控制内容哈希后缀3.1 为什么默认会有哈希后缀kustomize 对生成的 ConfigMap / Secret 默认启用名称哈希后缀目的是在资源内容发生变化时让资源名称随之变化从而强制触发 Deployment 等控制器的滚动更新。该机制从 Kubernetes 官方kubectl的 hash 工具移植而来实现在 api/hasher/hasher.go先对资源内容序列化后的字符串数组做排序与 JSON 序列化计算 SHA-256 摘要见hex256api/hasher/hasher.go取十六进制摘要的前 10 个字符再做一次字母化替换0→g、1→h、3→k、a→m、e→t得到最终后缀见encodeapi/hasher/hasher.go。这就是my-configmap-bh645k7tmg这类名称中后缀的来源。3.2 选项如何生效哈希后缀是否附加由生成资源的 factory 决定。在 api/resource/factory.go 的makeOne中if o.Options nil || !o.Options.DisableNameSuffixHash { resource.EnableHashSuffix() }也就是说只要没有显式声明disableNameSuffixHash: true生成资源就会被标记为需要哈希后缀。EnableHashSuffix/NeedHashSuffix的实现见 api/resource/resource.go它通过一个内部注解BuildAnnotationsGenAddHashSuffix标记该资源下游的HashTransformer见 api/internal/builtins/HashTransformer.go再据此为资源名称追加哈希。3.3 为什么需要禁用哈希后缀虽然能保证内容变更时名称变化但也带来两个常见问题名称稳定性需求某些场景如被其他资源按固定名称引用、或与外部系统约定名称要求 ConfigMap / Secret 名称恒定避免无谓的滚动更新如果每次构建仅因元数据差异导致哈希变化可能触发不必要的 Pod 重建。当disableNameSuffixHash: true时名称稳定为声明值内容变更不再通过改名来触发更新。需要留意的是此时若 ConfigMap 内容变化依赖它的 Deployment 不会自动感知需要自行处理版本控制或滚动更新策略。4. 选项二与三labels 与 annotations——为生成资源批量注入元数据generatorOptions.labels与generatorOptions.annotations会在生成 ConfigMap / Secret 的底层创建阶段被直接写入资源。生成器内部通过copyLabelsAndAnnotations实现见 api/internal/generators/utils.go遍历选项中的键值对调用yaml.SetLabel/yaml.SetAnnotation写入metadata.labels/metadata.annotations。该函数被MakeConfigMapapi/internal/generators/configmap.go与MakeSecretapi/internal/generators/secret.go同时调用因此这两个选项对 ConfigMap 和 Secret一视同仁。典型用途包括标记由 kustomize 生成的资源便于运维排查与清理如示例中的kustomize.generated.resource: somevalue注入审计、归属、成本归属等元数据为生成资源统一补充注解以对接外部工具链。5. 进阶选项四 immutable 与全局/局部合并规则5.1 immutable 选项除文档演示的三个选项外源码中还定义了第四个选项immutableapi/types/generatoroptions.go。当其为true时setImmutable会为生成资源写入immutable: true见 api/internal/generators/utils.go使 ConfigMap / Secret 不可变从 Kubernetes 侧禁止运行中修改进一步提升安全性。5.2 合并规则局部与全局、base 与 overlaygeneratorOptions是全局选项但同时允许在单个 generator 条目中通过options字段做局部覆盖。两者的合并逻辑在MergeGlobalOptionsIntoLocalapi/types/generatoroptions.go中实现规则如下labels / annotationsmap以局部local为准——局部已有的键不会被全局覆盖局部缺失的键才从全局补充overrideMap见 api/types/generatoroptions.godisableNameSuffixHash / immutablebool采用true 优先规则——只要全局为true即使局部显式写了false也无法覆盖反之全局为false时局部可以自行置true。源码注释解释得很直白对于布尔值无法区分有意的 false与默认的 false因此局部的 false 永远无法覆盖全局的 true。这些规则均有对应的单元测试验证api/types/generatoroptions_test.go 中的TestMergeGlobalOptionsIntoLocal以及 base/overlay 场景的集成测试api/krusty/generatoroptions_test.go 中的TestGeneratorOptionsWithBases与TestGeneratorOptionsOverlayDisableNameSuffixHash。其中TestGeneratorOptionsWithBases展示了一个非常典型的覆盖场景base 中声明disableNameSuffixHash: true并带 labelfoo: baroverlay 中声明disableNameSuffixHash: false并带 labelfruit: apple。最终结果里base 的 ConfigMap 名称没有哈希shouldNotHaveHash而 overlay 新声明的 ConfigMap 名称带哈希shouldHaveHash-c9867f8446并且两者的 label 互不影响——印证了全局 true 优先 map 键级合并的行为# base 中的生成结果 kind: ConfigMap metadata: labels: foo: bar name: shouldNotHaveHash --- # overlay 中的生成结果 kind: ConfigMap metadata: labels: fruit: apple name: shouldHaveHash-c9867f84466. 在 Secret 生成器上的应用由于generatorOptions同时作用于 ConfigMap 与 Secret 生成器你可以用同一份选项同时管理两类资源。例如generatorOptions: disableNameSuffixHash: true labels: kustomize.generated.resource: true secretGenerator: - name: app-secret literals: - PASSWORDxxxx生成结果中 Secret 的 metadata 同样携带 label且名称不带哈希。相关行为可参考 api/krusty/generatoroptions_test.go 中TestSecretGenerator的测试数据该用例默认保留了哈希后缀与disableNameSuffixHash的效果形成对照。7. 小结与最佳实践围绕generatorOptions可以沉淀出以下实践要点按需禁用哈希后缀只有当资源名称必须稳定时才设置disableNameSuffixHash: true同时要为内容变更设计替代的更新触发机制善用 labels / annotations 标记生成资源配合kubectl get cm -l kustomize.generated.resourcesomevalue等命令可以快速筛选出由 kustomize 生成的资源理解布尔合并规则在 base/overlay 或多层 kustomization 场景下局部 false 无法覆盖全局 true是容易踩坑的点务必通过kustomize build实际验证输出用测试片段做回归验证仓库中的示例验证脚本grep test 断言可直接移植到 CI 中确保生成结果符合预期保持配置最小化优先在 overlay 中声明与覆盖选项避免在 base 中写入过强的全局约束。完整的可运行示例位于 examples/zh/generatorOptions.md 与 examples/generatorOptions.md选项类型的完整定义可查阅 api/types/generatoroptions.go生成器实现与测试分别位于 api/internal/generators/utils.go、api/krusty/generatoroptions_test.go 与 api/types/generatoroptions_test.go供你在实际项目中按需深入。赞分享CLI开发工具云原生【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址https://gitcode.com/gh_mirrors/ku/kustomize点击查看免费下载相关推荐Kustomize 标签与注解完整指南commonLabels、labels 与 includeSelectors 正确用法Kustomize 标签与注解完整指南commonLabels、labels 与 includeSelectors 正确用法 Kustomize 是 KubeCLI开发工具云原生Faker::University 数据生成器完全指南高校名称、前缀后缀与希腊字母组织的源码级解析Faker::University 数据生成器完全指南高校名称、前缀后缀与希腊字母组织的源码级解析 Faker::University 是 faker 库A测试开发工具External Secrets Operator 生成器Generator完全指南通过 DataFrom 与 ClusterGenerator 动态生成 Kubernetes Secret 值External Secrets Operator 生成器Generator完全指南通过 DataFrom 与 ClusterGenerator 动态生成云原生运维上一篇Fleet 条件访问Conditional Access基于策略状态控制 macOS 与 Windows 主机登录准入的实现解析下一篇TaskScheduler 开源项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kustomize Generator Options 完全指南：掌控 ConfigMap 与 Secret 生成器的哈希后缀、标签与注解
CLI开发工具云原生【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址https://gitcode.com/gh_mirrors/ku/kustomize点击查看免费下载导读Kustomize 的generatorOptions字段允许你全局调整configMapGenerator与secretGenerator的生成行为——包括是否禁用名称后的内容哈希后缀、是否批量注入 labels 与 annotations以及设置immutable属性。本文以仓库中的 generatorOptions.md 演示为主线结合 kustomize 源码与测试用例为你拆解每个选项的底层实现、合并优先级规则和实战验证方法。1. 什么是 Generator Options在 kustomize 的声明式配置体系中configMapGenerator与secretGenerator负责把literals、files、envs等键值对来源转译为 Kubernetes 的 ConfigMap 与 Secret 对象。默认情况下kustomize 会在生成资源的名称后面追加一个基于资源内容计算的哈希后缀例如my-configmap-bh645k7tmg并支持为生成资源统一附加 labels 与 annotations。generatorOptions正是用来修改这些默认行为的一组全局选项它定义在 api/types/generatoroptions.go字段包括字段类型说明disableNameSuffixHashbool设为true时禁用默认的在生成资源名称后追加内容哈希后缀行为labelsmap[string]string为所有生成资源添加的标签annotationsmap[string]string为所有生成资源添加的注解immutablebool设为true时为所有生成资源设置immutable: true与 kustomization 中其他配置一样这些选项对kustomize build输出的最终资源生效并且遵循全局选项 局部覆盖的合并模型详见第 5 节。2. 官方示例从零体验 generatorOptions仓库中的演示文档 examples/zh/generatorOptions.md英文原版见 examples/generatorOptions.md给出了一个完整可运行的示例。我们将其整理为可直接复制的脚本说明如何创建 kustomization、配置生成器选项并逐一验证效果。2.1 创建工作空间DEMO_HOME$(mktemp -d)2.2 创建带 ConfigMapGenerator 的 kustomizationcat $DEMO_HOME/kustomization.yaml EOF configMapGenerator: - name: my-configmap literals: - foobar - bazqux EOF这里configMapGenerator声明了一个名为my-configmap的 ConfigMap数据来自两条literalsfoobar与bazqux。2.3 添加 generatorOptionscat $DEMO_HOME/kustomization.yaml EOF generatorOptions: disableNameSuffixHash: true labels: kustomize.generated.resource: somevalue annotations: annotations.only.for.generated: othervalue EOF三个选项分别对应本文要讲解的三类行为不追加哈希后缀、添加 label、添加 annotation。2.4 运行 build 并验证结果运行kustomize build生成最终资源然后用三组断言逐一验证验证一名称没有哈希后缀test 1 \ $(kustomize build $DEMO_HOME | grep name: my-configmap$ | wc -l); \ echo $?如果没有配置disableNameSuffixHash: true生成的名称通常是my-configmap-hash形式例如my-configmap-bh645k7tmggrep name: my-configmap$将匹配不到任何行而禁用后缀后名称恰好为my-configmap因此匹配行数为 1test命令成功。验证二labelkustomize.generated.resource: somevalue存在test 1 \ $(kustomize build $DEMO_HOME | grep -A 1 labels | grep kustomize.generated.resource | wc -l); \ echo $?验证三annotationannotations.only.for.generated: othervalue存在test 1 \ $(kustomize build $DEMO_HOME | grep -A 1 annotations | grep annotations.only.for.generated | wc -l); \ echo $?最终生成的 ConfigMap 形态如下预期输出apiVersion: v1 data: baz: qux foo: bar kind: ConfigMap metadata: annotations: annotations.only.for.generated: othervalue labels: kustomize.generated.resource: somevalue name: my-configmap注意这三组验证脚本在文档中被标记为test/testAgainstLatestRelease是 kustomize 持续集成中实际运行的测试片段因此这套流程在不同版本的 kustomize 上都能复现。3. 选项一disableNameSuffixHash——控制内容哈希后缀3.1 为什么默认会有哈希后缀kustomize 对生成的 ConfigMap / Secret 默认启用名称哈希后缀目的是在资源内容发生变化时让资源名称随之变化从而强制触发 Deployment 等控制器的滚动更新。该机制从 Kubernetes 官方kubectl的 hash 工具移植而来实现在 api/hasher/hasher.go先对资源内容序列化后的字符串数组做排序与 JSON 序列化计算 SHA-256 摘要见hex256api/hasher/hasher.go取十六进制摘要的前 10 个字符再做一次字母化替换0→g、1→h、3→k、a→m、e→t得到最终后缀见encodeapi/hasher/hasher.go。这就是my-configmap-bh645k7tmg这类名称中后缀的来源。3.2 选项如何生效哈希后缀是否附加由生成资源的 factory 决定。在 api/resource/factory.go 的makeOne中if o.Options nil || !o.Options.DisableNameSuffixHash { resource.EnableHashSuffix() }也就是说只要没有显式声明disableNameSuffixHash: true生成资源就会被标记为需要哈希后缀。EnableHashSuffix/NeedHashSuffix的实现见 api/resource/resource.go它通过一个内部注解BuildAnnotationsGenAddHashSuffix标记该资源下游的HashTransformer见 api/internal/builtins/HashTransformer.go再据此为资源名称追加哈希。3.3 为什么需要禁用哈希后缀虽然能保证内容变更时名称变化但也带来两个常见问题名称稳定性需求某些场景如被其他资源按固定名称引用、或与外部系统约定名称要求 ConfigMap / Secret 名称恒定避免无谓的滚动更新如果每次构建仅因元数据差异导致哈希变化可能触发不必要的 Pod 重建。当disableNameSuffixHash: true时名称稳定为声明值内容变更不再通过改名来触发更新。需要留意的是此时若 ConfigMap 内容变化依赖它的 Deployment 不会自动感知需要自行处理版本控制或滚动更新策略。4. 选项二与三labels 与 annotations——为生成资源批量注入元数据generatorOptions.labels与generatorOptions.annotations会在生成 ConfigMap / Secret 的底层创建阶段被直接写入资源。生成器内部通过copyLabelsAndAnnotations实现见 api/internal/generators/utils.go遍历选项中的键值对调用yaml.SetLabel/yaml.SetAnnotation写入metadata.labels/metadata.annotations。该函数被MakeConfigMapapi/internal/generators/configmap.go与MakeSecretapi/internal/generators/secret.go同时调用因此这两个选项对 ConfigMap 和 Secret一视同仁。典型用途包括标记由 kustomize 生成的资源便于运维排查与清理如示例中的kustomize.generated.resource: somevalue注入审计、归属、成本归属等元数据为生成资源统一补充注解以对接外部工具链。5. 进阶选项四 immutable 与全局/局部合并规则5.1 immutable 选项除文档演示的三个选项外源码中还定义了第四个选项immutableapi/types/generatoroptions.go。当其为true时setImmutable会为生成资源写入immutable: true见 api/internal/generators/utils.go使 ConfigMap / Secret 不可变从 Kubernetes 侧禁止运行中修改进一步提升安全性。5.2 合并规则局部与全局、base 与 overlaygeneratorOptions是全局选项但同时允许在单个 generator 条目中通过options字段做局部覆盖。两者的合并逻辑在MergeGlobalOptionsIntoLocalapi/types/generatoroptions.go中实现规则如下labels / annotationsmap以局部local为准——局部已有的键不会被全局覆盖局部缺失的键才从全局补充overrideMap见 api/types/generatoroptions.godisableNameSuffixHash / immutablebool采用true 优先规则——只要全局为true即使局部显式写了false也无法覆盖反之全局为false时局部可以自行置true。源码注释解释得很直白对于布尔值无法区分有意的 false与默认的 false因此局部的 false 永远无法覆盖全局的 true。这些规则均有对应的单元测试验证api/types/generatoroptions_test.go 中的TestMergeGlobalOptionsIntoLocal以及 base/overlay 场景的集成测试api/krusty/generatoroptions_test.go 中的TestGeneratorOptionsWithBases与TestGeneratorOptionsOverlayDisableNameSuffixHash。其中TestGeneratorOptionsWithBases展示了一个非常典型的覆盖场景base 中声明disableNameSuffixHash: true并带 labelfoo: baroverlay 中声明disableNameSuffixHash: false并带 labelfruit: apple。最终结果里base 的 ConfigMap 名称没有哈希shouldNotHaveHash而 overlay 新声明的 ConfigMap 名称带哈希shouldHaveHash-c9867f8446并且两者的 label 互不影响——印证了全局 true 优先 map 键级合并的行为# base 中的生成结果 kind: ConfigMap metadata: labels: foo: bar name: shouldNotHaveHash --- # overlay 中的生成结果 kind: ConfigMap metadata: labels: fruit: apple name: shouldHaveHash-c9867f84466. 在 Secret 生成器上的应用由于generatorOptions同时作用于 ConfigMap 与 Secret 生成器你可以用同一份选项同时管理两类资源。例如generatorOptions: disableNameSuffixHash: true labels: kustomize.generated.resource: true secretGenerator: - name: app-secret literals: - PASSWORDxxxx生成结果中 Secret 的 metadata 同样携带 label且名称不带哈希。相关行为可参考 api/krusty/generatoroptions_test.go 中TestSecretGenerator的测试数据该用例默认保留了哈希后缀与disableNameSuffixHash的效果形成对照。7. 小结与最佳实践围绕generatorOptions可以沉淀出以下实践要点按需禁用哈希后缀只有当资源名称必须稳定时才设置disableNameSuffixHash: true同时要为内容变更设计替代的更新触发机制善用 labels / annotations 标记生成资源配合kubectl get cm -l kustomize.generated.resourcesomevalue等命令可以快速筛选出由 kustomize 生成的资源理解布尔合并规则在 base/overlay 或多层 kustomization 场景下局部 false 无法覆盖全局 true是容易踩坑的点务必通过kustomize build实际验证输出用测试片段做回归验证仓库中的示例验证脚本grep test 断言可直接移植到 CI 中确保生成结果符合预期保持配置最小化优先在 overlay 中声明与覆盖选项避免在 base 中写入过强的全局约束。完整的可运行示例位于 examples/zh/generatorOptions.md 与 examples/generatorOptions.md选项类型的完整定义可查阅 api/types/generatoroptions.go生成器实现与测试分别位于 api/internal/generators/utils.go、api/krusty/generatoroptions_test.go 与 api/types/generatoroptions_test.go供你在实际项目中按需深入。赞分享CLI开发工具云原生【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址https://gitcode.com/gh_mirrors/ku/kustomize点击查看免费下载相关推荐Kustomize 标签与注解完整指南commonLabels、labels 与 includeSelectors 正确用法Kustomize 标签与注解完整指南commonLabels、labels 与 includeSelectors 正确用法 Kustomize 是 KubeCLI开发工具云原生Faker::University 数据生成器完全指南高校名称、前缀后缀与希腊字母组织的源码级解析Faker::University 数据生成器完全指南高校名称、前缀后缀与希腊字母组织的源码级解析 Faker::University 是 faker 库A测试开发工具External Secrets Operator 生成器Generator完全指南通过 DataFrom 与 ClusterGenerator 动态生成 Kubernetes Secret 值External Secrets Operator 生成器Generator完全指南通过 DataFrom 与 ClusterGenerator 动态生成云原生运维上一篇Fleet 条件访问Conditional Access基于策略状态控制 macOS 与 Windows 主机登录准入的实现解析下一篇TaskScheduler 开源项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考