开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载本文以 Kubebuilder 官方文档 docs/book/src/plugins/kustomize-v2.md 为主体结合仓库内pkg/plugins/common/kustomize/v2的源码实现全面讲解kustomize.common.kubebuilder.io/v2插件的用途、适用场景、使用方式独立使用、与语言插件组合、Bundle 组合以及它在init、create api、create webhook三个子命令中分别生成的config/清单结构。读完本文你将掌握如何为自己的语言插件接入统一的 Kustomize 配置、如何在自定义插件中组合 kustomize/v2以及默认脚手架生成的每一份 kustomize 清单背后对应的模板与源码。插件定位为默认脚手架统一生成config/目录Kustomize v2 插件全名kustomize.common.kubebuilder.io/v2是 Kubebuilder 中负责生成并维护项目config/目录下全部 Kustomize 清单的公共插件。它配合语言基础插件使用——默认的go.kubebuilder.io/v4go/v4插件本身就是一个组合插件其默认脚手架中的config/目录全部由该插件产出。该插件这样设计的核心价值在于职责分离与配置复用像 Operator SDK 这类项目会把 Kubebuilder 作为库来消费并在此基础上支持 Ansible、Helm 等其他语言。Kustomize 配置与语言无关抽成独立插件后所有语言插件可以共享同一套维护良好的配置无需在每个语言插件中重复维护需要在此基础上做二次开发的辅助/增强插件可以直接叠加在 kustomize 清单之上做变更而无需关心具体语言这种组合模式让helper 插件可以跨项目、跨语言工作。从源码结构看该插件位于 pkg/plugins/common/kustomize/v2其中v2/plugin.go明确定义了插件名称、版本与支持的子命令插件名kustomize.common.kubebuilder.io/v2源码中由kustomize.common.plugins.DefaultNameQualifier拼出见 v2/plugin.go插件版本v2阶段为Stable稳定版支持的项目版本仅支持项目配置版本 v3cfgv3.Version底层依赖的 kustomize 版本常量KustomizeVersion v5.8.1见 v2/plugin.go它实现了plugin.Init、plugin.CreateAPI、plugin.CreateWebhook三个子命令接口源码中通过var _断言验证见 v2/plugin.go。注意仓库根目录的pkg/plugins/common/kustomize/下还有v1之外的历史实现以及v2的完整实现本文所有源码引用均以v2目录为准。何时使用适用的场景与边界官方文档给出了明确的适用清单可归纳为适合与不适合两类适合使用 kustomize/v2 的场景你在开发自己的语言插件希望脚手架一并生成 kustomize 配置清单你需要在 Apple Silicondarwin/arm64上获得支持——kustomize 4.x 之前未提供该平台二进制你想尝试 kustomize v4 与 v5 提供的新语法与新特性你不想在资源字段中依赖特殊 URL你想使用replacements替代已经被弃用、随时可能被移除的vars功能。不适合使用 kustomize/v2 的场景你的项目需要运行在 Kubernetes 集群版本低于1.22的环境中——kustomize v4 的新特性在kubectl 1.22上未获官方支持可能无法正常工作。这一点在源码中也有对应印证init子命令的元数据描述明确写着 This plugin requires kustomize version v5 and kubectl 1.22.见 v2/init.go。如何使用三种接入方式方式一在语言插件中以 Bundle 组合方式使用推荐给插件开发者如果你的语言插件希望由自己负责脚手架语言相关的文件如go.mod、API、控制器而把配置交给 kustomize/v2可以使用 pkg/plugin/bundle.go 提供的plugin.NewBundle进行组合。Bundle 机制通过WithName、WithVersion、WithPlugins等选项见 bundle.go把多个插件组合成一个插件NewBundleWithOptions还会自动对所有子插件做解包展平并校验它们至少有一个共同支持的项目版本见 bundle.go。官方文档给出的示例代码如下import ( ... kustomizecommonv2 sigs.k8s.io/kubebuilder/v4/pkg/plugins/common/kustomize/v2 golangv4 sigs.k8s.io/kubebuilder/v4/pkg/plugins/golang/v4 ... ) // Bundle plugin which built the golang projects scaffold by Kubebuilder go/v4 // The follow code is creating a new plugin with its name and version via composition // You can define that one plugin is composite by 1 or Many others plugins gov3Bundle, _ : plugin.NewBundle(plugin.WithName(golang.DefaultNameQualifier), plugin.WithVersion(plugin.Version{Number: 3}), plugin.WithPlugins(kustomizecommonv2.Plugin{}, golangv4.Plugin{}), // scaffold the config/ directory and all kustomize files // Scaffold the Golang files and all that specific for the language e.g. go.mod, apis, controllers )组合之后kustomize/v2 负责生成config/目录及全部 kustomize 文件语言插件负责生成语言相关文件二者互不干扰。这也正是默认脚手架 go/v4 插件的工作方式。方式二单独使用 kustomize/v2不依赖任何语言插件直接初始化一个只包含 kustomize 配置的通用项目kubebuilder init --pluginskustomize/v2 $ ls -la total 24 drwxr-xr-x 6 camilamacedo86 staff 192 31 Mar 09:56 . drwxr-xr-x 11 camilamacedo86 staff 352 29 Mar 21:23 .. -rw------- 1 camilamacedo86 staff 129 26 Mar 12:01 .dockerignore -rw------- 1 camilamacedo86 staff 367 26 Mar 12:01 .gitignore -rw------- 1 camilamacedo86 staff 94 31 Mar 09:56 PROJECT drwx------ 6 camilamacedo86 staff 192 31 Mar 09:56 config从输出可以看到单独使用时会生成PROJECT项目配置文件、.gitignore、.dockerignore以及config/目录。init子命令支持的参数见 v2/init.go参数默认值说明--domainmy.domain指定 API 的域名例如example.org会生成crew.example.org形式的 API 组--project-name空项目名称未指定时自动取当前目录名转为小写此外项目名称必须是一个合法的 Kubernetes DNS 1123 标签InjectConfig中会通过validation.IsDNS1123Label校验见 v2/init.go。方式三与基础语言插件组合使用单独运行kubebuilder init --pluginskustomize/v2只得到配置骨架与base.go.kubebuilder.io/v4组合后可以得到与 go/v4 默认脚手架相同的结果go/v4 本身就是这种组合# Provides the same scaffold of go/v4 plugin which is composition but with kustomize/v2 kubebuilder init --pluginskustomize/v2,base.go.kubebuilder.io/v4 --domain example.org --repo example.org/guestbook-operator三个子命令分别脚手架什么kustomize/v2 实现了三个子命令initkubebuilder init [OPTIONS]create apikubebuilder create api [OPTIONS]create webhookkubebuilder create webhook [OPTIONS]其中create api的实现会为每个 API生成对应的 kustomize 清单create webhook同理。三者分别对应源码中的 v2/scaffolds/init.go、v2/scaffolds/api.go 与 v2/scaffolds/webhook.go。init初始化基础配置init通过NewInitScaffolder一次性写入一批基础模板见 scaffolds/init.goconfig/rbac/kustomization.yaml、metrics_auth_role.yaml、metrics_auth_role_binding.yaml、metrics_reader_role.yaml、leader_election_role.yaml、leader_election_role_binding.yaml、service_account.yamlconfig/manager/kustomization.yaml、manager.yaml镜像默认controller:latest见源码常量imageNameconfig/default/kustomization.yaml、metrics_service.yaml、manager_metrics_patch.yaml、cert_metrics_manager_patch.yamlconfig/network-policy/kustomization.yaml、allow-metrics-traffic.yamlconfig/prometheus/kustomization.yaml、monitor.yaml、monitor_tls_patch.yaml值得注意的细节是init 还会根据项目的命名空间作用域选择不同的 RBAC 模板当项目是命名空间作用域IsNamespaced()为真时追加NamespacedRoleBinding与NamespacedRole否则追加ClusterRoleBinding与ClusterRole见 scaffolds/init.go。这是为了保证在项目尚无 CRD 时controller-gen 不会生成这些文件仍有一份可用的集群级 RBAC。createSubcommand还为create api/create webhook提供公共的--force参数见 v2/create.go用于覆盖已存在的文件。create api按 API 生成 CRD 相关清单create api通过NewAPIScaffolder完成见 scaffolds/api.go生成config/samples/下的 CRD 示例crd_sample.go模板与samples/kustomization.yaml为每个 CRD 生成config/rbac/下的{kind}_admin_role.yaml、{kind}_editor_role.yaml、{kind}_viewer_role.yaml三个辅助角色多组MultiGroup项目下CRD 名前缀会带上 Group如foo_bar_admin_role.yaml见 scaffolds/api.go生成config/crd/下的kustomization.yaml与kustomizeconfig.yaml自动把config/default/kustomization.yaml中#- ../crd取消注释UncommentCode把 CRD 纳入默认 overlay在config/rbac/kustomization.yaml末尾追加 Admin/Editor/Viewer 角色引用及说明注释。create webhook生成 webhook 与证书相关清单create webhook通过NewWebhookScaffolder完成见 scaffolds/webhook.go基础产物包括config/default/manager_webhook_patch.yaml给 Deployment 打补丁config/webhook/kustomization.yaml、service.yamlconfig/certmanager/certificate.yaml、issuer.yaml、certificate-metrics.yaml、kustomization.yaml、kustomizeconfig.yamlconfig/network-policy/allow-webhook-traffic.yaml针对不同类型 webhook插件还会做差异化处理见 scaffolds/webhook.go转换 webhook--conversion额外生成config/crd/patches/enablewebhook_patch.yaml并在config/default/kustomization.yaml的replacements中启用 cert-manager CA 注入目标crdkustomizecainjectionns/crdkustomizecainjectionname标记同时取消config/crd/kustomization.yaml中configurations: kustomizeconfig.yaml的注释校验 webhook--programmatic-validation取消ValidatingWebhookConfiguration相关的 CA 注入 replacements 注释默认值 webhook--defaulting取消MutatingWebhookConfiguration相关的 CA 注入 replacements 注释任何 webhook 都会触发enableWebhookDefaults()在config/default/kustomization.yaml中依次取消#- ../webhook、#patches:、#- path: manager_webhook_patch.yaml、#- ../certmanager、#replacements:等注释并在config/network-policy/kustomization.yaml追加- allow-webhook-traffic.yaml。另外仓库还为edit子命令提供了NewEditScaffolder见 scaffolds/edit.go用于在项目初始化后通过kubebuilder edit切换命名空间/集群作用域时重新生成对应的 RBAC 与 manager 配置并遍历所有已有资源重建 CRD 的 Admin/Editor/Viewer 角色。受影响文件config/*该插件脚手架或更新的文件只有一处config/*——即整个config/目录树。你可以直接查看仓库中的真实样例来对照每份文件的最终形态例如testdata/project-v4/config默认单组 go/v4 项目样例testdata/project-v4-multigroup/config多组项目样例testdata/project-v4-with-plugins/config带插件项目样例以config/default/kustomization.yaml为例见 testdata/project-v4/config/default/kustomization.yaml它的结构体现了 kustomize 默认 overlay 的核心组织方式namespace所有资源统一放入{项目名}-system命名空间namePrefix为所有资源名加前缀{项目名}-且要求与 namespace 前缀保持一致resources按需引用../crd、../rbac、../manager、../webhook、../certmanager、../prometheus、../network-policy未启用的功能以注释形式保留如[WEBHOOK]、[CERTMANAGER]、[PROMETHEUS]等标记区块patches以path target.kind形式给 Deployment 打补丁如manager_metrics_patch.yaml开启 HTTPS 8443 metrics 端点、cert_metrics_manager_patch.yamlmetrics 加证书、manager_webhook_patch.yamlwebhook 注入replacements基于 kustomize v4/v5 的新语法实现 cert-manager CA 注入替换掉已弃用的vars为 metrics Service、webhook Service 的 DNS 名与ValidatingWebhookConfiguration/MutatingWebhookConfiguration/CustomResourceDefinition注入cert-manager.io/inject-ca-from注解。模板源码中这些注释区块和kubebuilder:scaffold:crdkustomizecainjectionns等脚手架标记都有完整保留见 kdefault/kustomization.go该文件即config/default/kustomization.yaml的生成模板。深入阅读与对比建议如果你希望继续深入阅读插件完整实现pkg/plugins/common/kustomize/v2阅读所有 kustomize 模板pkg/plugins/common/kustomize/v2/scaffolds/internal/templates/config/目录下的certmanager/、crd/、kdefault/、manager/、network-policy/、prometheus/、rbac/、samples/、webhook/九个子目录对比 kustomize 旧语法与 v4/v5 新语法对比样例项目project-v4与旧版project-v3的config/目录差异即可直观看到vars被replacements取代后的清单形态结合 Bundle 组合机制理解默认脚手架参见 pkg/plugin/bundle.go 与插件文档 docs/book/src/plugins/plugins.md、docs/book/src/plugins/available-plugins.md。综上kustomize.common.kubebuilder.io/v2是 Kubebuilder 插件体系中负责统一配置层的关键公共插件它让语言插件与配置生成解耦使得 Operator SDK 等下游项目能够跨 Ansible、Helm 等多种语言保持一致的config/布局也为后续叠加helper类增强插件提供了稳定的工作基础。赞分享开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载相关推荐Kubebuilder 项目脚手架插件指南go/v4 与 kustomize/v2 的默认组合与自定义用法Kubebuilder 项目脚手架插件指南go/v4 与 kustomize/v2 的默认组合与自定义用法 Kubebuilder 是一款基于 CRD 构建开发者工具代码生成CLI云原生后端Kubebuilder Kustomize v2 插件深度解析config/ 目录脚手架原理与实战Kubebuilder Kustomize v2 插件深度解析config/ 目录脚手架原理与实战 Kubebuilder 的 Kustomize v2 插件开发者工具代码生成CLI云原生后端Kubebuilder go/v4 插件全解析默认脚手架的原理、用法与源码实现Kubebuilder go/v4 插件全解析默认脚手架的原理、用法与源码实现 导读 go/v4 完整标识 go.kubebuilder.io/v4 是开发者工具代码生成CLI云原生后端上一篇终极教程如何让旧款Mac免费升级到最新macOS系统下一篇hotel前端错误处理全局异常捕获与用户友好提示创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考