ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

operator-sdk v1.0.0 迁移完全指南:CLI 命令重写、项目布局升级与破坏性变更对照

operator-sdk v1.0.0 迁移完全指南:CLI 命令重写、项目布局升级与破坏性变更对照 云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载operator-sdkv1.0.0 是该项目首个主版本发布它带来了项目结构整体重写与大量破坏性 CLI 变更与之前所有次要版本不兼容Go 项目除外Go 项目自 v0.19.0 起已切换到新布局。本文以官方升级文档 v1.0.0 迁移指南 为主线逐项拆解被移除/重命名的子命令、pkg/库的去向、PROJECT文件升级到 3-alpha 的具体操作并结合当前仓库源码给出可验证的实现细节帮助你完成从旧版 SDK 到 v1.0.0 的平滑迁移。迁移前必读按项目类型选择专属迁移指南v1.0.0 的破坏性变更因项目类型而异官方建议先阅读对应类型的迁移指南再回到本文处理通用变更Go 项目Go 项目迁移指南Ansible 项目Ansible 项目迁移指南Helm 项目Helm 项目迁移指南Go 项目布局在更早的 v0.19.0 已先行切换见 v0.19.0 迁移说明CLI 变更被移除的子命令与替代方案v1.0.0 对 CLI 进行了大刀阔斧的重写脚手架命令全面对齐 Kubebuilder 命名构建/打包类操作从 CLI 移到 Makefile target。官方给出了完整的命令对照表全部需要逐一替换被移除的命令替代用法变更原因operator-sdk newoperator-sdk init脚手架命名对齐 Kubebuilderoperator-sdk add apioperator-sdk create api同上operator-sdk add controlleroperator-sdk create apiAPI 与 Controller 合并创建operator-sdk add crdoperator-sdk create apiCRD 由 API 定义生成operator-sdk buildmake docker-build构建逻辑迁移到 Makefileoperator-sdk bundle createmake bundle打包逻辑迁移到 Makefileoperator-sdk generate k8smake generate代码生成迁移到 Makefileoperator-sdk generate crdsmake manifests清单生成迁移到 Makefileoperator-sdk generate csvoperator-sdk generate kustomize manifestsCSV 改由 kustomize 管道生成operator-sdk migrate无迁移路径混合型 operator 不再支持operator-sdk print-deps无替代直接移除operator-sdk run localmake run本地运行迁移到 Makefileoperator-sdk testcontroller-runtime 的 envtest 框架测试框架标准化这些变更在仓库的当前实现中得到印证internal/cmd/operator-sdk目录下已不存在new、add、build、migrate等子命令取而代之的是init/create由 Kubebuilder 侧插件提供、generate、bundle、run、cleanup、olm、scorecard等一组与上表一致的命令族。库变更pkg/ 包的去向与替换写法v1.0.0 将pkg/下的子包要么移除、要么迁移到了独立的operator-lib仓库。你需要更新 Go import 路径并改写部分调用。被移除的包包处理方式pkg/k8sutil移除迁移到 Kubebuilder 风格布局后不再需要pkg/kube-metrics移除改用InstrumentedEnqueueRequestForObjecthandlerpkg/metrics移除同上pkg/ready移除改用 controller-runtime 的 readyz serverpkg/tls移除改用 cert-manager 管理 TLS 证书迁移到 operator-lib 的包1. 注解触发的 watch handlerEnqueueRequestForAnnotation迁移到github.com/operator-framework/operator-lib/handler。2. 生成变更谓词GenerationChangedPredicate被重构迁移需改写成组合谓词import ( crpredicate sigs.k8s.io/controller-runtime/pkg/predicate libpredicate github.com/operator-framework/operator-lib/predicate ) ... crpredicate.Or( crpredicate.GenerationChangedPredicate{}, libpredicate.NoGenerationPredicate{}, )3. 领导选举leader-for-lifepkg/leader迁移到github.com/operator-framework/operator-lib/leader。4. 状态条件库pkg/status含状态条件 helper迁移到github.com/operator-framework/operator-lib/status。5. 指标相关移除addMetrics调用改在设置 controller-runtime watch 时使用InstrumentedEnqueueRequestForObject同样从github.com/operator-framework/operator-lib/handler导入。6. 就绪探针改用 controller-runtime 的 readyz server通过manager.AddReadyzCheck注册自定义 handler例如挂载healthz.Ping检查器。项目布局升级从 version 2 迁移到 3-alphav1.0.0 的默认 Go 插件不再为旧项目写入 OLM、scorecard 相关文件也不再写入plugins字段。要恢复这些能力需将PROJECT文件升级到 project version 3-alpha。对旧版version 2项目直接在PROJECT文件中补充以下内容version: 3-alpha # Updated from 2 projectName: output of $(basename $(pwd)) layout: go.kubebuilder.io/v2 plugins: go.sdk.operatorframework.io/v2-alpha: {}projectName取当前目录的 base name例如项目目录名为memcached-operator则值为memcached-operator。当前仓库中的PROJECT文件已演进到 version 3 格式可以作为对照参考例如 testdata/go/v4/memcached-operator/PROJECT 中同时存在layout: go.kubebuilder.io/v4、manifests.sdk.operatorframework.io/v2与scorecard.sdk.operatorframework.io/v2插件以及projectName: memcached-operator字段——这正是 3-alpha 迁移目标格式的后续演进形态。为 samples 目录添加脚手架标记升级到 3-alpha 后需在config/samples/kustomization.yaml中加入kubebuilder:scaffold:manifestskustomizesamples标记使后续脚手架能自动维护 samples 资源列表resources: - cache_v1alpha1_memcached.yaml #kubebuilder:scaffold:manifestskustomizesamples更新 Makefile 的 bundle 目标以注入镜像 tag为了支持make bundle IMGtag将镜像 tag 写入 CSV需要在 Makefile 的bundle目标中添加一行kustomize edit set imagebundle: ... operator-sdk generate kustomize manifests -q cd config/manager $(KUSTOMIZE) edit set image controller$(IMG) # Add this line ...这样执行make bundle IMGquay.io/example/operator:1.0.0时生成的 CSV 中 controller 镜像会被替换为指定 tag。operator-sdk cleanup简化为一层命令operator-sdk cleanup packagemanifests已移除统一为operator-sdk cleanup packageName。packageName可从 packagemanifests 目录根部的*.package.yaml文件中找到通常就是项目名。当前仓库源码证实了这一形态internal/cmd/operator-sdk/cleanup/cmd.go 中命令定义为Use: cleanup operatorPackageNameArgs: cobra.ExactArgs(1)且内部通过operator.NewUninstall(cfg)清理 OLM 部署的 operator包名直接作为参数传入。OLM 命令与 run packagemanifests 的系列变更移除olm install的--olm-namespace标志该标志已被移除因为 GitHub 上发布的 OLM manifests 将 namespace 值硬编码为olm因此该命令只能将 OLM 安装到olmnamespace。当前实现可见 internal/cmd/operator-sdk/olm/install.go命令仅保留--version标志用于指定 OLM 资源版本。run packagemanifests的四处改动默认安装模式从OwnNamespace改为AllNamespaces默认情况下所有 operator 都以集群范围运行并 watch 所有 namespace。若你依赖旧的默认OwnNamespace行为必须显式指定--install-modeOwnNamespace。--include-paths标志移除不再通过该标志创建额外资源改为在调用前先执行kubectl apply -f paths。--operator-version改名为--version--operator-namespace改名为--namespace--olm-namespace移除该命令不再需要 OLM namespace。参数packagemanifests-root-dir缺省为./packagemanifests可传项目下的 packagemanifests 根目录。从当前源码 internal/cmd/operator-sdk/run/packagemanifests/packagemanifests.go 可以看到该命令已标记为Deprecated提示 packagemanifests 格式将在 operator-sdk v2.0.0 移除建议使用operator-sdk pkgman-to-bundle迁移到 bundle 格式——说明 v1.0.0 的这批 CLI 改名是通往 bundle 时代的过渡步骤。日志与启动方式的变更Ansible / Helm operator 的日志标志两个 operator 已改用 controller-runtime 的 zap 包定义日志标志--zap-sample、--zap-time-encoding已移除controller-runtime flagset 中不存在。--zap-level更名为--zap-log-level需全局替换。核心逻辑迁移到ansible-operator|helm-operator run子命令若直接使用ansible-operator/helm-operator二进制需改为调用ansible-operator run和helm-operator run例如 Makefile 的make run目标。若使用基础镜像且未覆盖 entrypoint则无需改动——基础镜像已默认调用run子命令。当前仓库结构与此一致internal/cmd/helm-operator/run/cmd.go 即为 helm-operator 的 run 子命令实现。pkg/log/zap不再公开迁移到上游 controller-runtime 实现sigs.k8s.io/controller-runtime/pkg/log/zap其Options.BindFlags可绑定日志标志。默认指标端口变更Ansible / Helm operator 的默认指标端口不再是:8383。要继续使用 8383 端口需在启动时显式指定--metrics-bind-address:8383。当前 Helm operator 的 flags 实现internal/helm/flags/flag.go默认值为:8080并提供--metrics-bind-address标志--metrics-addr已标记废弃可供对照。注解域名的迁移.operator-sdk.io→.sdk.operatorframework.io插件键与注解中的旧域名后缀统一更换涉及PROJECT文件、示例 CR 文件以及线上集群中的 CRPROJECT文件中go.operator-sdk.io→go.sdk.operatorframework.io在 Kubebuilder 风格项目中。自定义资源注解ansible.operator-sdk/*→ansible.sdk.operatorframework.io/*helm.operator-sdk/*→helm.sdk.operatorframework.io/*。位置旧注解新注解PROJECT文件go.operator-sdk.iogo.sdk.operatorframework.io自定义资源ansible.operator-sdk/reconcile-periodansible.sdk.operatorframework.io/reconcile-period自定义资源ansible.operator-sdk/max-runner-artifactsansible.sdk.operatorframework.io/max-runner-artifacts自定义资源ansible.operator-sdk/verbosityansible.sdk.operatorframework.io/verbosity自定义资源helm.operator-sdk/upgrade-forcehelm.sdk.operatorframework.io/upgrade-force对线上集群中已存在的 Ansible / Helm CR按三步滚动迁移先给所有使用旧注解的 CR追加新等价注解新旧并存升级 operator升级完成后再移除CR 上的旧注解。当前仓库源码已全部采用新域名例如 internal/helm/controller/reconcile.go 中定义了helm.sdk.operatorframework.io/upgrade-force、helm.sdk.operatorframework.io/reconcile-period、helm.sdk.operatorframework.io/uninstall-release等注解常量internal/helm/controller/reconcile_test.go 中还有针对upgrade-force取值的测试用例True/False/1/0/invalid等可用于验证你的迁移是否正确。Ansible / Helm operator 的并发与元数据变更max-workers 改名标志--max-workers更名为--max-concurrent-reconciles功能完全一致只是对齐 controller-runtime 术语。当前实现见 internal/helm/flags/flag.go 第 66-70 行默认值为runtime.NumCPU()。环境变量WORKERS_Kind_Group废弃改用MAX_CONCURRENT_RECONCILES_Kind_Group。Ansiblemeta变量改名Ansible 内容中的meta变量不再可用需引用ansible_operator_meta。也可在watches.yaml中用vars关键字把新变量映射回meta- version: v1alpha1 group: test.example.com kind: Example role: test vars: meta: {{ ansible_operator_meta }}指标体系迁移到 Kubebuilder 风格端口:8686上的 kube-state-metrics 风格指标被替换为注册在 controller-runtime 指标注册表中的resource_created_at指标。运行时创建的 metricsService/ServiceMonitor改为部署期 kustomize manifests 生成。仓库的端到端测试证实了该指标的存在test/e2e/helm/cluster_test.go 第 271-272 行断言 operator 指标包含resource_created_at指标格式为resource_created_at_seconds{group..., ...}可作为该指标用法的实测参考。混合型 operator 不再支持v1.0.0 起基于 Ansible 或 Helm 的 operator Go 库不再提供继续使用的迁移路径Ansible / Helm 混合型 operator 用例不受支持。如果项目此前依赖这类混合架构需要按纯 Ansible 或纯 Helm 方向重构。scorecard 相关变更配置格式更新scorecard 配置文件需迁移到新格式详见 scorecard 配置文档。命令更名operator-sdk alpha scorecard改为operator-sdk scorecard若已在用operator-sdk scorecard则需迁移到新版 scorecard见 scorecard 文档。输出格式变更解析 scorecard 输出的脚本需适配v1alpha3.TestList格式详见 json 格式 与 text 格式 说明。API 导入路径变更scorecard v1alpha3 API 迁移到独立仓库import 路径更新为import github.com/operator-framework/api/pkg/apis/scorecard/v1alpha3其余零散破坏性变更清单version包不再公开无法再 importversion包请通过operator-sdk version命令获取版本。当前实现见 internal/cmd/operator-sdk/cli/version.go输出格式为operator-sdk version: %q, commit: %q, kubernetes version: %q, go version: %q, GOOS: %q, GOARCH: %q版本值由 internal/version/version.go 中的ldflags注入。移除--operator-name标志generate bundle/generate packagemanifests不再接受该标志需确保PROJECT文件中设置了projectName键若未设置则使用当前工作目录的 base name。s390x镜像不再自动构建若某版本需要s390x镜像需在 operator-sdk 项目中提 issue由维护者手动构建推送。run packagemanifests的--update-crds更名为--update-objects更名是为了涵盖所有可写入包目录的对象如 Roles。迁移检查清单完成 v1.0.0 迁移后建议按以下清单逐项核对所有operator-sdk new/add/build/bundle create等旧命令已替换为init/create api/make目标PROJECT文件已升级到 3-alpha 并写入plugins.go.sdk.operatorframework.io/v2-alpha与projectNameconfig/samples/kustomization.yaml已加入kubebuilder:scaffold:manifestskustomizesamples标记pkg/下的 import 已切换到operator-lib、controller-runtime或operator-framework/apicleanup packagemanifests已改为cleanup packageNamerun packagemanifests的标志--version、--namespace、--install-mode已按新命名调整额外资源改用kubectl apply -f注解域名已从.operator-sdk.io迁移到.sdk.operatorframework.io含线上 CR 的三步滚动流程--max-workers→--max-concurrent-reconcilesmeta→ansible_operator_metascorecard 命令、配置与输出解析已迁移到新格式日志标志--zap-log-level与指标端口--metrics-bind-address已按新规范配置。赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐Operator SDK v0.18.0 升级指南依赖版本、CRD v1 迁移与破坏性变更应对Operator SDK v0.18.0 升级指南依赖版本、CRD v1 迁移与破坏性变更应对 Operator SDK v0.18.0 是一次包含多项破坏性云原生后端开发工具微服务PHPWord 1.0.0 升级迁移指南破坏性变更全解析与替代 API 对照PHPWord 1.0.0 升级迁移指南破坏性变更全解析与替代 API 对照 PHPWord 1.0.02022 11 15 发布是 0.18.3 之后的后端Pydantic V2 迁移完全指南从 V1 升级的破坏性变更、API 对照与实战迁移方案Pydantic V2 迁移完全指南从 V1 升级的破坏性变更、API 对照与实战迁移方案 Pydantic V2 在保留“基于 Python 类型注解做数据后端序列化上一篇终极指南如何使用esbuild 20倍加速TypeScript 5.5.0项目构建下一篇OpCore Simplify终极指南一键智能配置黑苹果的完整解决方案创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表