kustomize cfg list-setters 命令指南列出资源配置中的所有 Setter【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址: https://gitcode.com/gh_mirrors/ku/kustomize本指南围绕 kustomize 的kustomize cfg list-setters命令展开讲解如何列出指定目录下所有 Kubernetes 资源配置中已定义的 setter可配置项并深入剖析 setter 在 YAML 中的 OpenAPI 注释格式、输出表格各列含义以及它与set、create-setter命令的协作关系。读完本文你将能够通过list-setters快速盘点一批配置中所有可调参数并据此进行声明式、可复用的配置定制。命令概览list-setters是kustomize cfg子命令体系中的一员属于Alpha阶段功能其职责是列出某个目录下所有 Resource 配置中定义的 setter。DIR包含 Resource 配置的目录必填。NAME可选参数指定要显示的 setter 名称不传时列出目录下全部 setter。从使用流程上看list-setters通常与set、create-setter配合形成创建 → 查看 → 修改的完整工作流create-setter为字段创建自定义 setterlist-setters查看当前目录下所有可用的 setter 及其取值set按 setter 名称批量修改字段值。基础用法与输出解读在包含 Resource 配置的目录上直接运行命令$ kustomize cfg list-setters DIR/ NAME DESCRIPTION VALUE TYPE COUNT SETBY name-prefix PREFIX string 2输出是一个对齐的文本表格每一行对应一个 setter各列含义如下列名含义NAMEsetter 的名称即 OpenAPI 注释中x-kustomize.setter[].name的值DESCRIPTIONsetter 的描述信息来自注释中的description字段未设置时显示为VALUE当前字段值即注释中 setter 的valueTYPE字段类型如string、integer等来自注释中的type字段COUNT该 setter 在目录所有 Resource 中匹配的字段数量SETBY最后设置该值的用户/工具标识来自x-kustomize.setBy未设置时为空COUNT列是最有价值的统计信息它告诉你一个 setter 实际生效于多少个字段。例如上例中name-prefix的COUNT为 2说明目录内有两个字段被该 setter 标记后续执行kustomize cfg set DIR/ name-prefix new-value会同时更新这 2 处取值set 命令会输出set 2 values确认。如果只想查看某一个 setter 的详细信息可以传入 NAME$ kustomize cfg list-setters DIR/ name-prefixSetter 在 YAML 中的存储形式list-setters之所以能看见 setter是因为 setter 以OpenAPI 扩展注释的形式内联在 YAML 字段行尾。set命令在解析时同时读取 Kubernetes 官方 OpenAPI 以及配置中以注释形式内联发布的 OpenAPI 扩展。以下面来自 set.md 的示例 Resource 为例# DIR/resources.yaml ... metadata: name: PREFIX-app1 # {type:string,x-kustomize:{setter:[{name:name-prefix,value:PREFIX}]}} ... --- ... metadata: name: PREFIX-app2 # {type:string,x-kustomize:{setter:[{name:name-prefix,value:PREFIX}]}} ...关键点行尾注释是一段 JSON即内联的 OpenAPI schema 片段type声明字段类型string、integer等x-kustomize.setter是 kustomize 的自定义扩展其中name是 setter 名value是当前值x-kustomize.setBy记录最后一次由谁设置该值如devdescription用于描述该 setter 的用途。由于两个metadata.name字段都携带相同名称的 setter 注释list-setters会聚合出COUNT 2的一行记录。与 set 命令的联动查看修改前与修改后的状态list-setters最常见的实战场景是在执行set修改前先盘点当前取值修改后再用list-setters验证结果。以下完整示例演示了创建 → 列出 → 修改 → 再列出的闭环1. 初始状态name-prefix值为PREFIX无描述、无 setBy$ kustomize cfg list-setters DIR/ NAME DESCRIPTION VALUE TYPE COUNT SETBY name-prefix PREFIX string 22. 执行 set同时修改值、描述和 setBy$ kustomize cfg set DIR/ name-prefix test --description test environment --set-by dev set 2 values3. 修改后再次列出$ kustomize cfg list-setters DIR/ NAME DESCRIPTION VALUE TYPE COUNT SETBY name-prefix test environment test string 2 dev4. 对应 YAML 的变化两处metadata.name的行尾注释被同步更新description与x-kustomize.setBy被写入metadata: name: test-app1 # {description:test environment,type:string,x-kustomize:{setBy:dev,setter:[{name:name-prefix,value:test}]}} --- metadata: name: test-app2 # {description:test environment,type:string,x-kustomize:{setBy:dev,setter:[{name:name-prefix,value:test}]}}要点set命令只有在显式传入--description和--set-by时才更新这两个字段否则保持原样list-setters则始终如实展示当前状态因此是验证 set 操作结果的最直接手段。深入原理Setter 如何被创建与解析要真正理解list-setters的输出需要了解 setter 的两种来源1. 通过 create-setter 命令创建create-setter通过把 OpenAPI 内联为行尾注释来为字段创建自定义 setter例如为 Service 的端口字段创建整数类型 setter$ kustomize cfg create-setter DIR/ http-port 8080 --type integer --field port \ --description default port used by the app命令执行后字段值匹配--field与VALUE的字段行尾会被加上注释- name: http port: 8080 # {type:integer,x-kustomize:{partialFieldSetters:[{name:http-port,value:8080}]}}注意这里使用的是partialFieldSetters表示 setter 针对的是字段值的一部分或整体而非完整字段替换。2. 直接编辑 YAML 手写注释根据 create-setter.md 的说明setter 也可以直接通过编辑 YAML 添加注释来定义无需借助命令。list-setters对两种来源一视同仁只要是合法的x-kustomize扩展注释都会被识别和聚合。子串 Setter 与多重 Settersetter 既可以绑定整个字段值也可以只绑定字段值的子串。例如只为 image 的 tag 部分创建 setter$ kustomize cfg create-setter DIR/ image-tag v1.0.1 --type string \ --field image --description current stable releaseimage: gcr.io/example/app:v1.0.1 # {type:string,x-kustomize:{partialFieldSetters:[{name:image-tag,value:v1.0.1}]}}单个字段值还可以同时应用多个 setter各自负责字段值的不同部分——这解释了为什么set文档中强调 setter 机制非常适合构建可复用的配置包通过为不同字段定义语义化名称的 setter一批 YAML 配置对外暴露的就是一组清晰的、可程序化编辑的配置参数。适用场景与注意事项结合 set.md 中声明的设计目标list-setters的价值主要体现在程序化编辑配置在 CI/CD 或脚本中先list-setters盘点可调参数再调用set批量注入环境相关取值构建可复用配置包为配置包内的关键字段定义语义化 setter如name-prefix、http-port、image-tag使用者通过list-setters即可发现全部定制入口无需阅读完整 YAML审计与验证set 操作前后各执行一次list-setters可确认VALUE、SETBY、COUNT是否符合预期。注意事项list-setters属于Alpha功能接口与输出格式可能随版本演进调整使用时应以当前 kustomize 版本的kustomize help cfg list-setters输出为准set、create-setter、list-setters的相关说明分别见 set.md 与 create-setter.md命令实现与生成文档位于 cmd/config/internal/commands 与 cmd/config/internal/generateddocs/commands/docs.go若想深入理解 setter 注释背后的 OpenAPI 内联机制可继续查看 kyaml 中 YAML 节点与字段元数据处理的实现见 kyaml/yaml/rnode.go 与 kyaml/fieldmeta/fieldmeta.go。小结kustomize cfg list-setters是 kustomize 配置定制工作流中的查看器它以一张包含NAME、DESCRIPTION、VALUE、TYPE、COUNT、SETBY的表格把散落在 YAML 行尾 OpenAPI 注释中的 setter 聚合呈现出来配合create-setter定义参数、set批量修改取值即可实现对 Kubernetes YAML 配置的声明式、可复用、可程序化编辑。【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址: https://gitcode.com/gh_mirrors/ku/kustomize创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 kustomize cfg list-setters 命令指南：列出资源配置中的所有 Setter
kustomize cfg list-setters 命令指南列出资源配置中的所有 Setter【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址: https://gitcode.com/gh_mirrors/ku/kustomize本指南围绕 kustomize 的kustomize cfg list-setters命令展开讲解如何列出指定目录下所有 Kubernetes 资源配置中已定义的 setter可配置项并深入剖析 setter 在 YAML 中的 OpenAPI 注释格式、输出表格各列含义以及它与set、create-setter命令的协作关系。读完本文你将能够通过list-setters快速盘点一批配置中所有可调参数并据此进行声明式、可复用的配置定制。命令概览list-setters是kustomize cfg子命令体系中的一员属于Alpha阶段功能其职责是列出某个目录下所有 Resource 配置中定义的 setter。DIR包含 Resource 配置的目录必填。NAME可选参数指定要显示的 setter 名称不传时列出目录下全部 setter。从使用流程上看list-setters通常与set、create-setter配合形成创建 → 查看 → 修改的完整工作流create-setter为字段创建自定义 setterlist-setters查看当前目录下所有可用的 setter 及其取值set按 setter 名称批量修改字段值。基础用法与输出解读在包含 Resource 配置的目录上直接运行命令$ kustomize cfg list-setters DIR/ NAME DESCRIPTION VALUE TYPE COUNT SETBY name-prefix PREFIX string 2输出是一个对齐的文本表格每一行对应一个 setter各列含义如下列名含义NAMEsetter 的名称即 OpenAPI 注释中x-kustomize.setter[].name的值DESCRIPTIONsetter 的描述信息来自注释中的description字段未设置时显示为VALUE当前字段值即注释中 setter 的valueTYPE字段类型如string、integer等来自注释中的type字段COUNT该 setter 在目录所有 Resource 中匹配的字段数量SETBY最后设置该值的用户/工具标识来自x-kustomize.setBy未设置时为空COUNT列是最有价值的统计信息它告诉你一个 setter 实际生效于多少个字段。例如上例中name-prefix的COUNT为 2说明目录内有两个字段被该 setter 标记后续执行kustomize cfg set DIR/ name-prefix new-value会同时更新这 2 处取值set 命令会输出set 2 values确认。如果只想查看某一个 setter 的详细信息可以传入 NAME$ kustomize cfg list-setters DIR/ name-prefixSetter 在 YAML 中的存储形式list-setters之所以能看见 setter是因为 setter 以OpenAPI 扩展注释的形式内联在 YAML 字段行尾。set命令在解析时同时读取 Kubernetes 官方 OpenAPI 以及配置中以注释形式内联发布的 OpenAPI 扩展。以下面来自 set.md 的示例 Resource 为例# DIR/resources.yaml ... metadata: name: PREFIX-app1 # {type:string,x-kustomize:{setter:[{name:name-prefix,value:PREFIX}]}} ... --- ... metadata: name: PREFIX-app2 # {type:string,x-kustomize:{setter:[{name:name-prefix,value:PREFIX}]}} ...关键点行尾注释是一段 JSON即内联的 OpenAPI schema 片段type声明字段类型string、integer等x-kustomize.setter是 kustomize 的自定义扩展其中name是 setter 名value是当前值x-kustomize.setBy记录最后一次由谁设置该值如devdescription用于描述该 setter 的用途。由于两个metadata.name字段都携带相同名称的 setter 注释list-setters会聚合出COUNT 2的一行记录。与 set 命令的联动查看修改前与修改后的状态list-setters最常见的实战场景是在执行set修改前先盘点当前取值修改后再用list-setters验证结果。以下完整示例演示了创建 → 列出 → 修改 → 再列出的闭环1. 初始状态name-prefix值为PREFIX无描述、无 setBy$ kustomize cfg list-setters DIR/ NAME DESCRIPTION VALUE TYPE COUNT SETBY name-prefix PREFIX string 22. 执行 set同时修改值、描述和 setBy$ kustomize cfg set DIR/ name-prefix test --description test environment --set-by dev set 2 values3. 修改后再次列出$ kustomize cfg list-setters DIR/ NAME DESCRIPTION VALUE TYPE COUNT SETBY name-prefix test environment test string 2 dev4. 对应 YAML 的变化两处metadata.name的行尾注释被同步更新description与x-kustomize.setBy被写入metadata: name: test-app1 # {description:test environment,type:string,x-kustomize:{setBy:dev,setter:[{name:name-prefix,value:test}]}} --- metadata: name: test-app2 # {description:test environment,type:string,x-kustomize:{setBy:dev,setter:[{name:name-prefix,value:test}]}}要点set命令只有在显式传入--description和--set-by时才更新这两个字段否则保持原样list-setters则始终如实展示当前状态因此是验证 set 操作结果的最直接手段。深入原理Setter 如何被创建与解析要真正理解list-setters的输出需要了解 setter 的两种来源1. 通过 create-setter 命令创建create-setter通过把 OpenAPI 内联为行尾注释来为字段创建自定义 setter例如为 Service 的端口字段创建整数类型 setter$ kustomize cfg create-setter DIR/ http-port 8080 --type integer --field port \ --description default port used by the app命令执行后字段值匹配--field与VALUE的字段行尾会被加上注释- name: http port: 8080 # {type:integer,x-kustomize:{partialFieldSetters:[{name:http-port,value:8080}]}}注意这里使用的是partialFieldSetters表示 setter 针对的是字段值的一部分或整体而非完整字段替换。2. 直接编辑 YAML 手写注释根据 create-setter.md 的说明setter 也可以直接通过编辑 YAML 添加注释来定义无需借助命令。list-setters对两种来源一视同仁只要是合法的x-kustomize扩展注释都会被识别和聚合。子串 Setter 与多重 Settersetter 既可以绑定整个字段值也可以只绑定字段值的子串。例如只为 image 的 tag 部分创建 setter$ kustomize cfg create-setter DIR/ image-tag v1.0.1 --type string \ --field image --description current stable releaseimage: gcr.io/example/app:v1.0.1 # {type:string,x-kustomize:{partialFieldSetters:[{name:image-tag,value:v1.0.1}]}}单个字段值还可以同时应用多个 setter各自负责字段值的不同部分——这解释了为什么set文档中强调 setter 机制非常适合构建可复用的配置包通过为不同字段定义语义化名称的 setter一批 YAML 配置对外暴露的就是一组清晰的、可程序化编辑的配置参数。适用场景与注意事项结合 set.md 中声明的设计目标list-setters的价值主要体现在程序化编辑配置在 CI/CD 或脚本中先list-setters盘点可调参数再调用set批量注入环境相关取值构建可复用配置包为配置包内的关键字段定义语义化 setter如name-prefix、http-port、image-tag使用者通过list-setters即可发现全部定制入口无需阅读完整 YAML审计与验证set 操作前后各执行一次list-setters可确认VALUE、SETBY、COUNT是否符合预期。注意事项list-setters属于Alpha功能接口与输出格式可能随版本演进调整使用时应以当前 kustomize 版本的kustomize help cfg list-setters输出为准set、create-setter、list-setters的相关说明分别见 set.md 与 create-setter.md命令实现与生成文档位于 cmd/config/internal/commands 与 cmd/config/internal/generateddocs/commands/docs.go若想深入理解 setter 注释背后的 OpenAPI 内联机制可继续查看 kyaml 中 YAML 节点与字段元数据处理的实现见 kyaml/yaml/rnode.go 与 kyaml/fieldmeta/fieldmeta.go。小结kustomize cfg list-setters是 kustomize 配置定制工作流中的查看器它以一张包含NAME、DESCRIPTION、VALUE、TYPE、COUNT、SETBY的表格把散落在 YAML 行尾 OpenAPI 注释中的 setter 聚合呈现出来配合create-setter定义参数、set批量修改取值即可实现对 Kubernetes YAML 配置的声明式、可复用、可程序化编辑。【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址: https://gitcode.com/gh_mirrors/ku/kustomize创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考