开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载Kubebuilder 1.0 引入了一个全新的--project-version标志它接受v0与v1两个取值由此在同一个 CLI 中并存了两种架构截然不同的项目生成方式。本文以 Kubebuilder 官方文档 docs/kubebuilder_v0_v1_difference.md 为主线系统梳理 v0 与 v1 项目在命令工作流、脚手架目录布局、底层库依赖与依赖注入Wiring机制四个维度的差异并对照当前仓库的源码与测试数据给出实现佐证帮助你在新旧项目之间准确识别结构、评估迁移成本。背景--project-version 标志的由来Kubebuilder 1.0 为init命令新增了--project-version标志取值只有两种v0使用该值时Kubebuilder 的行为与工作流完全等同于 Kubebuilder 0.x 系列生成的是旧版 v0 项目v1使用该值时生成的 v1 项目在架构上architecturally与 v0 项目截然不同。v1 项目在控制器实现上使用 controller-runtime 系列库在脚手架与代码生成上使用 controller-tools 系列工具。也就是说v1 不是对 v0 的简单修补而是把控制器运行时与脚手架/生成器这两层完全切换到了新的库与工具链上。从当前仓库源码看--project-version标志在 CLI 层仍被保留用于选择插件链。在 pkg/cli/cli.go 中projectVersionFlag project-version被定义为常量其描述为用于选择兼容插件并写入 PROJECT 的项目配置版本例如 3在 pkg/cli/init.go 中init命令通过cmd.Flags().String(projectVersionFlag, c.defaultProjectVersion.String(), projectVersionFlagDescription)将标志注册到动态创建的命令上以便在帮助信息中展示且不引发解析错误。可以推断v1 时代之后该标志的语义演化为项目配置版本如 2、3、4用于与go.kubebuilder.io/v2、go.kubebuilder.io/v3、go.kubebuilder.io/v4等插件键见 pkg/cli/cli.go匹配这恰恰印证了项目布局由所选插件链驱动这一 v1 设计思想的后继形态。命令差异从手工生成到 make 驱动v0 的命令集与工作流v0 提供五个子命令init、create controller、create resource、create config、generate。其典型工作流如下kubebuilder init --domain example.com kubebuilder create resource --group group --version version --kind Kind GOBIN${PWD}/bin go install ${PWD#$GOPATH/src/}/cmd/controller-manager bin/controller-manager --kubeconfig ~/.kube/config kubectl apply -f hack/sample/resource.yaml docker build -f Dockerfile.controller . -t image:tag docker push image:tag kubebuilder create config --controller-image image:tag --name project-name kubectl apply -f hack/install.yaml这个工作流的几个关键特征API 创建用create resource而非create apiv0 中以资源resource为最小脚手架单元命令参数为--group、--version、--kind三元组需要手工安装 controller-manager 二进制GOBIN${PWD}/bin go install ...把主程序装进项目本地bin/目录再以bin/controller-manager --kubeconfig ~/.kube/config启动镜像构建与安装清单生成是分离的先docker build/docker push再用kubebuilder create config --controller-image image:tag --name project-name生成安装清单hack/install.yaml最后kubectl apply -f hack/install.yaml部署每次改动都要重新生成文档明确强调Every time the resource or controller is updated, users need to runkubebuilder generateto regenerate the project. 这是 v0 工作流最大的心智负担——资源类型或控制器代码一变就必须手动触发一次全量生成deepcopy、clientset、informer、lister 等。v1 的命令集与工作流v1 精简为两个子命令init与create api。典型工作流kubebuilder init --domain example.com --license apache2 --owner The Kubernetes authors kubebuilder create api --group ship --version v1beta1 --kind Frigate make install make run与 v0 相比的核心变化create resource更名为create api且职责合并——一次调用同时生成 API 类型与控制器交互提示询问是否创建 Resource / Controllerinit增加了--license与--owner选项用于向新文件头部写入许可证与版权声明make install与make run取代了手工的 go install / 二进制启动 / docker build / create config 流水线make install安装 CRD 到集群make run在本地运行 controller-managerv1 项目没有generate命令In a v1 project, there is no generate command. When the resource or controller is updated, users dont need to regenerate the project. 生成动作被并入make generate、make manifests等 Makefile 目标由 controller-gen 按需执行不再需要全量手工触发。这一从手工到 make 驱动的演进在当前仓库的 v4 测试数据中可见一斑例如 testdata/project-v4/Makefile 提供make install、make run、make generate、make manifests、make build等目标而 testdata/project-v4/cmd/main.go 中主程序通过ctrl sigs.k8s.io/controller-runtime构建 Manager——这正是一条从 v1 延续下来的库驱动 make 驱动工作流。脚手架差异目录布局的分水岭v0 与 v1 项目在脚手架目录上的差异是判断项目归属最直观的依据对比项v0 项目v1 项目pkg/client目录存在不存在inject目录存在不存在API/控制器目录固定为pkg/apis、pkg/controller接受用户指定路径每个 api 与 controller 的初始化无统一约定每个 api 与 controller 都有一个init()函数要点解读pkg/client是 v0 的客户端代码仓由kubebuilder generate生成的 clientset、informers、listers 都落在这里详见下文客户端库小节。v1 没有这个目录因为客户端能力由 controller-runtime 的 client 提供inject目录是 v0 的依赖注入中枢负责把控制器接进 controller-manager 并注册 CRD详见Wiring 差异小节。v1 删除了它改用init()函数完成同样的职责目录自由化v0 强制pkg/apispkg/controller的固定布局v1 允许用户指定路径例如把 API 放在api/控制器放在internal/controller/这也是后续版本支持多组multigroup布局的基础init()约定v1 中每个 API 和每个控制器都有一个包级init()函数注册 Scheme 或把控制器注册进 Manager详见下节。以当前仓库的 v4 单组项目 testdata/project-v4 为例可以看到该布局的当代形态API 类型在api/v1/如 admiral_types.go控制器在internal/controller/如 admiral_controller.go主程序在cmd/main.go与 v0 的pkg/apis、pkg/controller、根目录main.go形成鲜明对照。库差异从自研到 controller-runtime控制器库v0 项目从 Kubebuilder 自带的kubebuilder/pkg/controller导入控制器库核心抽象是GenericController类型它对外暴露一组可调用的方法如Watch、WatchControllerOf等。v0 的控制器是围绕这个通用控制器骨架编写的其Reconcile函数签名形如func (bc *kindController) Reconcile(k types.ReconcileKey) errorv1 项目从 controller-runtime 导入控制器库典型导入路径为controller-runtime/pkg/controller与controller-runtime/pkg/reconcileReconcile签名变为func (r *Reconcilekind) Reconcile(request reconcile.Request) (reconcile.Result, error)。签名的两处关键变化入参从types.ReconcileKey一个封装了 namespace/name 的结构变为reconcile.Request本质上也是 namespaced name 的载体返回值从单一的error变为(reconcile.Result, error)reconcile.Result用于告诉调度器是否 requeue、以及 requeue 间隔。当前仓库 v4 测试数据中的控制器正是这套 v1 签名的延续例如 admiral_controller.go 中func (r *AdmiralReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error)与func (r *AdmiralReconciler) SetupWithManager(mgr ctrl.Manager) errorv1 的add 函数在后继版本演化为SetupWithManager。客户端库v0 项目的客户端库由kubebuilder generate生成放在pkg/client目录下项目中任何需要访问 Kubernetes API 或缓存的地方都直接导入这些生成的包。也就是说客户端代码是生成物会随资源定义变化而重新生成v1 项目导入 controller-runtime 的动态客户端库controller-runtime/pkg/client通过client.Client接口提供Get/List/Create/Update/Delete等方法无需为每个资源生成专属 clientset。迁移时客户端调用方式的对应关系在 docs/migration_guide.md 中有完整对照大致如下操作v0 写法v1 写法Get 自定义资源bc.memcachedLister.Memcacheds(k.Namespace).Get(k.Name)mc : myappsv1alpha1.Memcached{}; err : r.Client.Get(context.TODO(), request.NamespacedName, mc)Get 内置资源bc.KubernetesInformers.Apps().V1().Deployments().Lister()...dp : appsv1.Deployment{}; err : r.Client.Get(context.TODO(), request.NamespacedName, dp)Createbc.KubernetesClientSet.AppsV1().Deployments(...).Create(dep)err : r.Client.Create(context.TODO(), dep)Updatebc.KubernetesClientSet.AppsV1().Deployments(...).Update(...)err : r.Client.Update(context.TODO(), dep)Listbc.KubernetesInformers.Core().V1().Pods().Lister().Pods(...).List(labelSelector)pods : v1.PodList{}; err r.Client.List(context.TODO(), client.ListOptions{LabelSelector: labelSelector}, pods)Wiring 差异init() 取代 inject 包文档对 Wiring 的定义是Wiring refers to the mechanics of integrating controllers into controller-managers and injecting the dependencies in them.——即把控制器集成进 controller-manager、并把依赖注入其中的机制。v0 项目有一个inject包它提供两类函数一类把控制器加入 controller-manager另一类注册 CRD。整个项目的装配逻辑集中在这个包里v1 项目没有inject包控制器通过 controller 目录下add_type.go文件内的init()函数加入 controller-manager例如把Reconciler注册到 Manager并设置 Watches类型scheme 注册通过 apis 目录下type_types.go文件内的init()函数完成。也就是说v1 把装配从集中式inject包分散到了每个资源文件自身的init()中。这一点在 docs/migration_guide.md 中有直接体现迁移 v0 控制器到 v1 时需要保留type_types.go中由typeList与init组成的注册段// k8s:deepcopy-gen:interfacesk8s.io/apimachinery/pkg/runtime.Object // genclient:nonNamespaced // HelloList contains a list of Hello type HelloList struct { metav1.TypeMeta json:,inline metav1.ListMeta json:metadata,omitempty Items []Hello json:items } func init() { SchemeBuilder.Register(Hello{}, HelloList{}) }同时v0 控制器文件中的ProvideController函数负责创建 GenericController 并添加 watches在 v1 中对应为add函数后继版本为SetupWithManager。迁移时不需要照搬 v0 代码而是依据 v0ProvideController中调用的Watch系列方法在 v1 的add函数里补上等价的 watcher。例如 v0 的gc : controller.GenericController{...} gc.Watch(myappsv1alpha1.Memcached{}) gc.WatchControllerOf(v1.Pod{}, eventhandlers.Path{bc.LookupRS, bc.LookupDeployment, bc.LookupMemcached})需要改写成 v1 的c, err : controller.New{...} c.Watch(source.Kind{Type: myappsv1alpha1.Memcached{}}, handler.EnqueueRequestForObject{}) c.Watch(source.Kind{Type: appsv1.Deployment{}}, handler.EnqueueRequestForOwner{ IsController: true, OwnerType: myappsv1alpha1.Memcached{}, })注意其中的语义差异gc.Watch(...)这种直接监听某类型在 v1 中是source.Kind handler.EnqueueRequestForObject把变更事件转成对对象本身的 Reconcile 请求gc.WatchControllerOf(...)这种监听子资源但回队到父对象的写法在 v1 中对应source.Kind handler.EnqueueRequestForOwner按 OwnerReference 回队到 Owner。迁移要点速查官方推荐的迁移路径详见 docs/migration_guide.md是新建 v1 项目再把 v0 代码复制/改写进去而非原地改造。关键步骤包括init从旧项目pkg/apis/doc.go中找出 domain执行kubebuilder init --project-version v1 --domain domaincreate api从旧项目pkg/apis目录名读出 group/version、从*_types.go读出 kind注意首字母大写对每个资源重复kubebuilder create api --group group --version version --kind kind复制 types.go保留typeList与init()注册段改写 Reconcile改为 v1 签名(reconcile.Result, error)每个return增加reconcile.Result{}作为首值把bc.kindLister/bc.KubernetesClientSet/bc.KubernetesInformers系列调用替换为r.Client的Get/Create/Update/List不要引入 kubebuilder 或旧项目 client 包中的库改写 add 函数按 v0ProvideController中的 watch 列表在 v1add函数中补 watcher复制依赖把旧Gopkg.toml中# Users add deps lines here块的自定义依赖复制到新项目 Gopkg.toml 的生成区# STANZAS BELOW ARE GENERATED ...行之前验证make确认可构建、make installmake run确认集群上 api 与 controller 正常工作。小结v0 与 v1 的分水岭可以概括为三条主线命令集从五命令 手工生成精简为两命令 make 驱动脚手架从固定pkg/apis/pkg/controller布局 pkg/clientinject包转向用户指定路径 init()自注册库依赖从Kubebuilder 自研GenericController与生成式 clientset切换到controller-runtime 的controller/reconcile/client。对于维护 v0 遗留项目的团队这份差异清单既是定位问题的诊断工具也是制定 v1 迁移计划的依据对于新项目则可以直接选择 v1及其后继版本获得更简洁、由 make 与 controller-runtime 驱动的开发体验。延伸阅读docs/migration_guide.mdv0→v1 完整迁移手册、docs/book/src/migration/manual-process.md当代布局下的手工迁移流程、docs/book/src/migration/discovery-commands.mdAI 辅助发现脚手架命令。赞分享开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载相关推荐Kubebuilder v0 项目到 v1 项目迁移完整指南重建脚手架与代码移植实战Kubebuilder v0 项目到 v1 项目迁移完整指南重建脚手架与代码移植实战 本文档 docs/migration_guide.md https:/开发者工具代码生成CLI云原生后端CANN/ge模型加载APIaclmdlBundleLoadModela nameZH CN_TOPIC_0000002528647267 /a 产品支持情况a names人工智能深度学习模型编译模型优化编译器AscendKubebuilder项目从v0到v1版本的迁移指南Kubebuilder项目从v0到v1版本的迁移指南 前言 Kubebuilder作为Kubernetes官方推荐的Operator开发框架经历了从v0到v1开发者工具代码生成CLI云原生后端上一篇如何使用React Native Navigation打造高效物联网设备监控和控制页面导航下一篇终极GitHub Pages主题Minimal5分钟快速搭建个人博客创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
