通过手动更新文件进行从 go/v3 到 go/v4 的迁移。

在继续之前，请确保您了解 Kubebuilder go/v3 和 go/v4 之间的区别。

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

以下指南描述了升级您的 PROJECT 配置文件以开始使用 go/v4 所需的手动步骤。

这种方式更复杂，容易出错，成功也无法得到保证。此外，按照这些步骤操作，您将无法获得默认生成项目文件中的改进和bug修复。

通常建议如果您对项目进行了自定义并偏离了建议的框架，最好手动操作。在继续之前，请确保您理解关于 [项目自定义][project-customizations] 的说明。请注意，您可能需要花费比整理项目自定义更多的精力来手动完成此过程。建议的布局将使您的项目在未来更易于维护和升级，所需的努力也会更少。

推荐的升级方法是遵循 从 go/v3 到 go/v4 的迁移指南。

从项目配置版本迁移\

更新 PROJECT 文件布局，以存储有关用于使插件在搭建时做出有用决策的资源的信息。layout 字段指示所使用的搭建方式和主要插件版本。

迁移步骤

将布局版本迁移到 PROJECT 文件中。

以下步骤描述了手动更改项目配置文件（PROJECT）所需的步骤。这些更改将添加Kubebuilder在生成文件时会添加的信息。该文件可以在根目录中找到。

通过替换来更新 PROJECT 文件：

layout:
- go.kubebuilder.io/v3

With:

layout:
- go.kubebuilder.io/v4

布局更改

新布局：
  • 目录 apis 已重命名为 api 以遵循标准。
  • controller(s) 目录已被移至一个名为 internal 的新目录下，并且也改名为单数形式 controller。
  • 之前在根目录下搭建的 main.go 文件已经移动到一个名为 cmd 的新目录下。

因此，您可以检查布局结果的变化为：

...
├── cmd
│ └── main.go
├── internal
│ └── controller
└── api
迁移到新布局：
  • 创建一个新的目录 cmd 并将 main.go 移动到该目录下。
  • 如果您的项目支持多组，则 API 将在名为 apis 的目录下生成。将此目录重命名为 api。
  • 将 controllers 目录移动到 internal 下，并将其重命名为 controller。
  • 现在请确保导入将相应更新：
    • 将 main.go 的导入更新为查找 internal/controller 目录下的新路径。

那么，让我们更新脚手架的路径

  • 更新 Dockerfile，以确保您将拥有：
COPY cmd/main.go cmd/main.go
COPY api/ api/
COPY internal/controller/ internal/controller/

然后，替换：

RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o manager main.go

With:

RUN CGO_ENABLED=0 GOOS=${TARGETOS:-linux} GOARCH=${TARGETARCH} go build -a -o manager cmd/main.go
  • 更新 Makefile 的目标，以通过替换来构建和运行管理器：
.PHONY: build
build: manifests generate fmt vet ## Build manager binary.
	go build -o bin/manager main.go

.PHONY: run
run: manifests generate fmt vet ## Run a controller from your host.
	go run ./main.go

With:

.PHONY: build
build: manifests generate fmt vet ## Build manager binary.
	go build -o bin/manager cmd/main.go

.PHONY: run
run: manifests generate fmt vet ## Run a controller from your host.
	go run ./cmd/main.go
  • 更新 internal/controller/suite_test.go 以设置 CRDDirectoryPaths 的路径：

Replace:

``With:

`请注意，如果您的项目有多个组（multigroup:true），那么上述更新应该导致 “..”, “..”, “..”,而不是“..”,“..”`。

现在，让我们相应地更新项目文件中的路径。

该项目跟踪您项目中使用的所有 API 的路径。请确保它们现在指向 api/...，例如以下示例：

更新前：

  group: crew
  kind: Captain
  path: sigs.k8s.io/kubebuilder/testdata/project-v4/apis/crew/v1

更新后：


  group: crew
  kind: Captain
  path: sigs.k8s.io/kubebuilder/testdata/project-v4/api/crew/v1

使用迄今为止所做的更改更新 kustomize 清单。

  • 在 config/ 目录下更新清单，包含使用 go/v4 插件在默认脚手架上所做的所有更改（例如，请参阅 testdata/project-v4/config/），以便将所有默认脚手架的更改应用到您的项目中。
  • 创建 config/samples/kustomization.yaml，将所有指定在 config/samples 中的自定义资源示例包含在内。 (例如参见 testdata/project-v4/config/samples/kustomization.yaml)

如果您有 webhook：

在 Webhook 测试文件中，将导入 admissionv1beta1 "k8s.io/api/admission/v1beta1" 替换为 admissionv1 "k8s.io/api/admission/v1"。

Makefile 更新

请根据所用发布标签下的测试数据中的示例更新 Makefile 的更改。（例如，请参见 testdata/project-v4/Makefile）

更新依赖项

请根据所使用的发布标签在 testdata 中的示例中找到的更改更新 go.mod 文件（例如，参考 testdata/project-v4/go.mod）。然后，运行 go mod tidy 以确保获取最新的依赖项，并确保你的 Golang 代码没有出现破坏性更改。

验证

在以上步骤中，您手动更新了您的项目，以确保它遵循使用 go/v4 插件引入的更新模板的布局变化。

没有选项可以验证您是否正确更新了项目的 PROJECT 文件。确保所有内容正确更新的最佳方法是使用 go/v4 插件初始化一个项目，即使用 kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4，并生成相同的 API、控制器和 webhook，以便将生成的配置与手动更改的配置进行比较。

此外，在所有更新完成后，您需要运行以下命令：

  • make manifests（在更新 Makefile 后使用最新版本的 controller-gen 重新生成文件）
  • make all（以确保您能够构建并执行所有操作）