从 v2 迁移到 v3

在继续之前，请确保您了解 Kubebuilder v2 和 v3 之间的差异。

请确保您已按照安装指南安装所需的组件。

迁移 v2 项目的推荐方式是创建一个新的 v3 项目，并将 API 和调整代码复制过去。转换后的项目将类似于原生 v3 项目。然而，在某些情况下，可以进行就地升级（即重用 v2 项目的布局，升级 controller-runtime 和 controller-tools）。

初始化一个 v3 项目

创建一个新目录，使用你的项目名称。请注意，这个名称在脚手架中用于创建你的管理器 Pod 的名称以及管理器默认部署的命名空间。

$ mkdir migration-project-name
$ cd migration-project-name

现在，我们需要初始化一个 v3 项目。不过，在此之前，如果我们不在 GOPATH 目录下，就需要初始化一个新的 Go 模块。虽然在 GOPATH 内部技术上并不需要这样做，但仍然推荐这样做。

go mod init tutorial.kubebuilder.io/migration-project

然后，我们可以使用 kubebuilder 完成项目的初始化。

kubebuilder init --domain tutorial.kubebuilder.io

迁移 API 和控制器

接下来，我们将重新搭建 API 类型和控制器。

kubebuilder create api --group batch --version v1 --kind CronJob

迁移API

现在，让我们将旧项目中的 api/v1/<kind>_types.go 文件中的 API 定义复制到新项目中。

这些文件没有被新的插件修改，所以您应该可以用旧的文件替换新生成的文件。可能会有一些外观上的变化。因此，您可以选择仅复制类型本身。

迁移控制器

现在，让我们将旧项目中的 controllers/cronjob_controller.go 控制器代码迁移到新项目中。这里有一个重大更改，并且可能会有一些外观上的变化。

新的 Reconcile 方法现在将上下文作为参数接收，而不再需要使用 context.Background() 来创建它。您可以将旧控制器中的其余代码复制到生成的方法中，替换：

func (r *CronJobReconciler) Reconcile(req ctrl.Request) (ctrl.Result, error) {
    ctx := context.Background()
    log := r.Log.WithValues("cronjob", req.NamespacedName)

With:

func (r *CronJobReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	log := r.Log.WithValues("cronjob", req.NamespacedName)

迁移 Webhooks

现在让我们为我们的 CRD（CronJob）搭建 Webhook。我们需要使用 --defaulting 和 --programmatic-validation 标志运行以下命令（因为我们的测试项目使用了默认值和验证 Webhook）：

kubebuilder create webhook --group batch --version v1 --kind CronJob --defaulting --programmatic-validation

现在，让我们将旧项目中的 api/v1/<kind>_webhook.go 的 webhook 定义复制到新项目中。

其他人

如果在v2中的main.go有任何手动更新，我们需要将这些更改移植到新的main.go中。同时，我们还需要确保所有需要的方案已被注册。

如果在配置目录下添加了其他清单，请一并移植。

如果需要，请在Makefile中更改图像名称。

验证

最后，我们可以运行 make 和 make docker-build 来确保一切正常。