CLI开发工具云原生【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址https://gitcode.com/gh_mirrors/ku/kustomize点击查看免费下载Kustomize 是一套面向 Kubernetes 的模板无关、结构化定制工具围绕它形成了kustomization、base、overlay、variant、patch等一整套专属术语。本文以仓库中的官方术语表site/content/en/docs/Reference/glossary.md为主体骨架逐条讲解这些术语的定义、使用场景与彼此关系并结合当前仓库的源码与示例如 api/types/kustomization.go、api/filters/patchjson6902/patchjson6902.go、examples/multibases给出实现级佐证。读完本文你将能准确使用 Kustomize 的术语体系正确组织 base/overlay 目录结构、理解kustomize build的 target 语义、区分两种 patch 语法并看懂kustomization.yaml中四类字段的职责划分。核心对象与背景概念kubernetesk8sKubernetes 是一套用于自动化部署、扩缩与运维容器化应用的开源系统常缩写为k8s。Kustomize 的所有定制行为都围绕 k8s 对象展开因此必须先理解对象的含义。kubernetes-style objectKubernetes 风格对象一个以 YAML 或 JSON 文件表达的、具备 Kubernetes 所要求字段的对象。本质上只需要三个字段即可构成一个可被识别的对象kind标识对象类型metadata/name标识具体实例apiVersion标识 API 版本存在多个版本时用于区分。这也是后续resource资源定义的判定基础任何带有kind与metadata/name字段的正确 YAML 文件都可以作为 Kustomize 的处理对象。仓库中 api/ifc/ifc.go 等接口层即围绕读取、持有、变换这类对象来设计。application应用application指一组因共同目的而关联的 k8s 资源例如数据库后端 Web 服务器 负载均衡器。历史上人们通过资源标签、命名与元数据方案将资源聚合在一起以支持list、remove等集体操作。Kubernetes 社区曾提出过一种名为application的新资源类型用于更正式地描述这一概念并为应用级操作与仪表盘提供支持而在 Kustomize 视角下这个提议中的 application 资源只是另一个资源与 ConfigMap、Deployment 一样可被定制。apply应用在 k8s 语境中动词apply指kubectl apply命令以及一个演进中的 API 端点用于变更集群状态。工作方式是以完整资源列表的形式向集群提交一份期望状态声明集群将这份声明与之前已 apply 的状态、实际状态三方合并得出新的期望状态再由集群的调谐循环reconciliation loop去落实。这正是 k8s 基于水位level-based状态管理的基石。Kustomize 的价值在于为apply准备好这份完整资源列表。declarative application management声明式应用管理DAMKustomize 自视为 [Declarative Application Management] 这套管理 k8s 集群最佳实践的实现其核心主张在术语表中被凝练为 kustomize 应当做到的几点能处理任意配置自研bespoke、现成off-the-shelf、无状态、有状态等支持常见定制与变体的创建如 development vs. staging vs. production暴露并教授原生 k8s API而不是把用户与底层 API 隔离开与版本控制集成零摩擦支持评审与审计追踪以 Unix 风格与其他工具组合不越界去做模板化、领域专用语言DSL等会妨碍上述目标的事情。gitopsDevOps 或 CI/CD 工作流的一种形态以 git 仓库作为唯一事实来源当该事实发生变化时触发构建、测试或部署等动作。术语表中特别指出在简单的 gitops 管理下一个 base 配置可以是专为该用途而设的 git 仓库的唯一内容overlays 同理仓库中的变更即可触发一次构建 → 测试 → 部署循环。这与仓库示例 examples/multibases/README.md 中一个 base 多个 overlay 变体的目录组织方式天然契合。kustomization 体系kustomizationkustomization指kustomization.yaml文件或更一般地指一个目录——即根目录及其内所有被该文件立即引用的相对路径文件所有无需 URL 规范的本地数据。因此别人给你一份kustomization时其交付形态可以是一个名为kustomization.yaml的文件一个 tarball内含该 YAML 及其引用内容一个 git archive同上一个指向 git 仓库的 URL同上等等。kustomization.yaml中的字段可划分为四类这一分类在源码 api/types/kustomization.go 的Kustomization结构体中有着一一对应的体现类别含义示例字段含源码中的对应字段resources要定制哪些已有资源resources、crds对应源码Resources []string、Crds []stringgenerators要新建哪些资源configMapGeneratorlegacy、secretGeneratorlegacy、generatorsv2.1对应源码Generators []string指自定义生成器文件transformers对上述资源做什么namePrefix、nameSuffix、images、commonLabels、patchesJson6902等以及更通用的transformersv2.1对应源码Transformers []stringmeta影响上述全部或部分行为的元信息vars、namespace、apiVersion、kind对应源码Namespace string、内嵌TypeMeta值得注意的是源码中同时标注了大量弃用字段bases改用resources、imageTags改用images、patchesJson6902/patchesStrategicMerge改用统一的patches、vars改用replacements、commonLabels改用labels。Kustomization.FixKustomization()与FixKustomizationPreMarshalling()会自动完成这些迁移例如把Bases并入Resources、把PatchesJson6902并入PatchesCheckDeprecatedFields()则会对仍使用弃用字段的配置输出 Run kustomize edit fix to update your Kustomization automatically. 的提示可用kustomize edit fix自动修复。kustomization rootkustomization 根目录指直接包含kustomization.yaml文件的目录。处理一份 kustomization 时其能否访问根目录之外的文件受安全限制约束资源 YAML、用于 ConfigMap/Secret 的namevalue文本、patch 文件等数据文件必须位于根目录内或之下因此只能以相对路径引用其他 kustomization其他含kustomization.yaml的目录则可以通过 URL、绝对路径或相对路径引用。这一限制的源码实现在 api/internal/loader/loadrestrictions.goRestrictionRootOnly会检查目标文件d.HasPrefix(root)不满足即报错security; file %s is not in or below %s而 v2.1 引入的--load_restrictions none标志对应同文件中的RestrictionNone直接放行任意路径例如允许一个 patch 文件被多个 kustomization 共享flag 定义见 kustomize/commands/build/build.go 的AddFlagLoadRestrictor。此外若 kustomizationA依赖 kustomizationB则B 不能包含 AB 不能依赖 A即使传递依赖也不行。A 可以包含 B但此时更简单的做法往往是让 A 直接依赖 B 的资源、去掉 B 的kustomization.yaml即把 B 吸收进 A。惯例上 B 位于 A 的兄弟目录或位于完全独立的、可被任意 kustomization 引用的 git 仓库中。术语表给出的典型目录布局如下├── base │ ├── deployment.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays ├── dev │ ├── kustomization.yaml │ └── patch.yaml ├── prod │ ├── kustomization.yaml │ └── patch.yaml └── staging ├── kustomization.yaml └── patch.yaml其中dev、prod、staging三个根目录大概率都引用了base根——具体需查看各自的kustomization.yaml才能确认。仓库中的 examples/multibases 正是这一布局的活样例base/kustomization.yaml 只声明resources: [pod.yaml]而 dev/kustomization.yaml 以resources: [- ../base]引用 base 并叠加namePrefix: dev-。术语表中 root 条目即指向本概念。base基础base是被其他 kustomization 引用的 kustomization。任何 kustomization——包括 overlay——都可以作为另一 kustomization 的 base。base不知道有哪些 overlay 引用它单向依赖无反向感知。在 examples/multibases/README.md 中可看到完整的 base 多变体演示一个只含单个 Pod 的 base被dev、staging、production三个 overlay 分别引用并加上不同的namePrefix甚至还可以再做一层组合 overlay把三个变体作为 base 引入并统一加namePrefix: cluster-a-从而对不在你控制之下的 base应用公共标签或最左前缀。overlay叠加层overlay是依赖另一个 kustomization的 kustomization。overlay 所引用的 kustomization通过文件路径、URI 或其他方式称为其 bases。要点overlay 离开 base 便不可用overlay 本身也可作为另一个 overlay 的 base可多层叠加overlay 在有多个时最有意义因为它们基于公共 base 制造出不同变体——例如 development、QA、staging、production 环境变体。这些变体复用同一套资源仅以相对简单的方式变化Deployment 的副本数、某 Pod 的 CPU、ConfigMap 中的数据源等。配置集群的典型方式是把 overlay 作为 target 构建并交给 applykustomize build someapp/overlays/staging |\ kubectl apply -f - kustomize build someapp/overlays/production |\ kubectl apply -f -base 的使用是隐式的——由 overlay 的 kustomization 指向 base 即可。参见 kustomization root。variant变体variant是将 overlay 应用到 base 之后、在集群中呈现的结果。例如 staging 与 production 两个 overlay 都修改某个公共 base从而产生不同的变体staging 变体暴露给质量保证测试、或希望预览下一版 production 的外部用户的那组资源production 变体暴露给生产流量的那组资源因此可能使用大副本数的 Deployment 与更高的 CPU、内存请求。target构建目标target是kustomize build的参数kustomize build $target$target必须是某个 kustomization 的路径或 URL包含或引用生成可发送给 apply 操作的定制资源所需的全部信息。target 可以是 base 或 overlay。在 kustomize/commands/build/build.go 中Validate限制只接受一个路径参数省略时默认.并支持 git 仓库 URL 加路径后缀的形式如https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?refv1.0.6RunE通过krusty.MakeKustomizer(...).Run(fSys, path)完成构建。bespoke configuration自研配置bespoke配置是某组织内部为自己目的创建和维护的 kustomization 与资源。其工作流比 off-the-shelf 配置简单因为没有周期性吸收他人对现成配置的升级这一概念。off-the-shelf configuration现成配置off-the-shelf配置是有意公开发布供他人使用的 kustomization 与资源。例如创建一个这样的 git 仓库github.com/username/someapp/ kustomization.yaml deployment.yaml configmap.yaml README.md他人可以 fork 该仓库并 clone 到本地进行定制这个 clone 可作为用户自己 overlays 的 base。仓库中的 examples/helloWorld含kustomization.yaml、deployment.yaml、service.yaml、configMap.yaml就是可被当作 base 引用的典型结构。package包package一词在 Kustomize 中没有含义——Kustomize 不是 apt、rpm 那样的包管理工具请勿混淆。资源生成与变换resource资源在 RESTful API 语境下resource是 HTTP 操作GET、PUT、POST 等的目标对象k8s 提供 RESTful API 面与客户端交互。在 kustomization 语境下resource是一个描述 k8s API 对象如 Deployment、ConfigMap的 YAML 或 JSON 文件的、相对根目录的路径或一个指向 kustomization 的路径或一个解析到 kustomization 的 URL。更一般地任何带kind与metadata/name字段、定义对象的正确 YAML 文件都可视为资源。对应源码见 api/types/kustomization.go 的Resources []string字段注释relative paths to files holding YAML representations of kubernetes API objects, or specifications of other kustomizations via relative paths, absolute paths, or URLs。generator生成器generator生成可直接使用的资源或生成后交给 transformer 进一步处理。内置生成器的实现示例ConfigMapGenerator.go / configmap.go由本地数据生成 ConfigMapSecretGenerator.go / secret.go由本地数据生成 SecretHelmChartInflationGenerator.go由 Helm Chart 展开资源。按 api/types/kustomization.go 的注释生成的 ConfigMap/Secret 是普通操作数operand同样受 namePrefix、patch 等处理且默认名称会带内容哈希后缀。transformer转换器transformer可以修改资源也可以在kustomize build过程中仅访问资源并收集其信息。它是对资源做什么的一类操作。内置转换器以Transformer结尾的 builtin 插件形式存在于 api/internal/builtins例如 PrefixTransformer.go、ImageTagTransformer.go、NamespaceTransformer.go其过滤器实现位于 api/filters如 labels、namespace、imagetag 等子目录。术语表把namePrefix、nameSuffix、images、commonLabels、patchesJson6902等字段归入 transformers 类别源码中它们对应的正是这批 transformer 的实现。plugin插件plugin是 Kustomize 使用的代码块不一定要编译进 Kustomize 二进制其职责是在一次 kustomization 中生成和/或变换某个 Kubernetes 资源。仓库的 plugin 目录展示了两种形态plugin/builtin内置插件annotationstransformer、configmapgenerator、imagetagtransformer 等每个目录含 go.mod 与实现源码plugin/someteam.example.com/v1按域名/版本组织的外部插件样例。内置插件的注册与加载逻辑见 api/internal/pluginsbuiltinconfig、builtinhelpers、execplugin、fnplugin、loader 等子包。源码 api/types/kustomization.go 中的Generators、Transformers、Validators三个字段v2.1即用于挂载这类自定义插件文件。补丁patch机制patch补丁patch是修改资源的通用指令存在两种能力相近但记法不同的技术strategic merge patch 与 JSON patch。在kustomization.yaml中现代推荐写法是统一的patches字段源码 api/types/kustomization.go 的Patches []Patcheach one can be either a Strategic Merge Patch or a JSON patch, and each patch can be applied to multiple target objects旧的patchesStrategicMerge、patchesJson6902字段已被标记弃用并会在构建时自动迁移。patchStrategicMerge策略合并补丁SMPpatchStrategicMerge即 strategic-merge 风格补丁。SMP 看起来像一个不完整的 k8s 资源 YAML 描述包含用于定位目标资源 group/version/kind/name 的TypeMeta字段再加上恰好足够进入嵌套结构、指定新字段值如镜像 tag的其余字段。默认行为是替换值——当目标值是简单字符串时通常正是所需但当目标值是列表时可能不符合预期。要改变默认行为可添加指令directiveYAML 补丁中识别的指令有replace默认与delete。需要注意对自定义资源CR而言SMP 会被当作 [JSON merge patch] 处理。一个有趣的特性任何资源文件都可以当作 SMP 使用——它会覆盖另一个同 group/version/kind/name 资源中的匹配字段其余字段保持不变。源码实现见 api/filters/patchstrategicmerge/patchstrategicmerge.go通过merge2.Merge将补丁节点与目标节点合并列表方向为 prepend从而支持节点删除等语义。patchJson6902JSON 补丁patchJson6902指一个 Kubernetes resource 加一份描述如何修改该资源的 [JSONPatch]RFC 6902。它能完成 patchStrategicMerge 几乎所有能做的事但语法更简练。仓库中有完整可运行示例 examples/jsonpatch.md以Ingress为例补丁文件是一组op/path/value操作replace、add并通过patches字段配合targetgroup/version/kind/name定位对象patches: - path: ingress_patch.json target: group: networking.k8s.io version: v1beta1 kind: Ingress name: my-ingress补丁内容示例JSON 格式也可用 YAML 书写规则不变[ {op: replace, path: /spec/rules/0/host, value: foo.bar.io}, {op: replace, path: /spec/rules/0/http/paths/0/backend/servicePort, value: 80}, {op: add, path: /spec/rules/0/http/paths/1, value: { path: /healthz, backend: {servicePort:7700} }} ]运行验证kustomize build $DEMO_HOME out_actual.yaml diff out_actual.yaml out_expected.yaml源码实现见 api/filters/patchjson6902/patchjson6902.go补丁若不以[开头则先经YAMLToJSON转成 JSON再交给gopkg.in/evanphx/json-patch.v4的DecodePatch/Apply执行该实现会先序列化为 JSON 再应用因此不保证字段顺序。其他术语custom resource definition自定义资源定义CRD通过创建 Custom Resource DefinitionCRD可以扩展 k8s API定义一种全新的自定义资源术语表中写作 CD可与 ConfigMap、Deployment 等原生资源并列使用。Kustomize 可以定制自定义资源但前提是必须同时提供对应的 CRD以便正确解释其结构。对应源码为 api/types/kustomization.go 的Crds []string字段relative paths to Custom Resource Definition files. This allows custom resources to be recognized as operands, making it possible to add them to the Resources list. CRDs themselves are not modified.实际加载逻辑见 api/internal/accumulator/loadconfigfromcrds.go它会把 CRD 中的 OpenAPI 结构并入 kustomize 的 schema 解释能力。sub-target / sub-application / sub-packagesub-什么都不是一个正式概念——在 Kustomize 的术语体系中只有 bases 和 overlays。任何子依赖关系都应表达为这两个概念之一。快速对照速查术语一句话定义仓库佐证kustomizationkustomization.yaml及其所在根目录的本地数据api/types/kustomization.gobase被其他 kustomization 引用的 kustomizationexamples/multibases/baseoverlay依赖其他 kustomization 的 kustomizationexamples/multibases/dev/kustomization.yamlvariantoverlay 应用到 base 后在集群中的结果examples/multibases/README.mdtargetkustomize build的参数kustomization 路径或 URLkustomize/commands/build/build.gopatchStrategicMerge不完整资源 YAML 式补丁默认替换可加 directiveapi/filters/patchstrategicmerge/patchstrategicmerge.gopatchJson6902RFC 6902 式 JSON 补丁op/path/value 记法examples/jsonpatch.md、api/filters/patchjson6902/patchjson6902.gogenerator生成可直接使用或交给 transformer 的资源api/internal/builtins/ConfigMapGenerator.gotransformer修改资源或在 build 过程中收集资源信息api/internal/builtins/PrefixTransformer.goplugin可独立于 kustomize 二进制编译的生成/变换代码plugin/builtin掌握这套术语是正确阅读 Kustomize 文档、设计 base/overlay 目录、理解kustomize build行为与 patch 语法的基础本文所述的每个概念都能在仓库的源码与示例中找到对应实现可作为后续深入学习的索引。赞分享CLI开发工具云原生【免费下载链接】kustomizeCustomization of kubernetes YAML configurations项目地址https://gitcode.com/gh_mirrors/ku/kustomize点击查看免费下载相关推荐kustomize 使用指南声明式定制 Kubernetes YAML 配置kustomize 使用指南声明式定制 Kubernetes YAML 配置 导读 本文围绕 kustomize 的核心使用模型展开如何在不动原始 YAMLCLI开发工具云原生tus-js-client并行上传深度解析如何提升3倍上传速度tus js client并行上传深度解析如何提升3倍上传速度 在当今数据驱动的时代文件上传速度直接影响用户体验和工作效率。tus js client作为一CLI开发工具云原生Kustomize定制你的 Kubernetes YAML 配置Kustomize定制你的 Kubernetes YAML 配置 Kustomize 是由 Kubernetes SIG CLI团队维护的一个开源项目主要用CLI开发工具云原生上一篇终极Prisma市场分析2026年商业数据和竞争情报系统完整指南下一篇5分钟掌握OpenAI Python工具Pydantic参数智能转换创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考