ARTICLE DETAIL

资讯详情

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

operator-sdk Helm 项目从 pre-v1.0.0 迁移到 Kubebuilder 风格布局的完整指南

operator-sdk Helm 项目从 pre-v1.0.0 迁移到 Kubebuilder 风格布局的完整指南 云原生后端开发工具微服务【免费下载链接】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 官方 Helm 迁移文档系统讲解如何将v1.0.0之前构建的 Helm-based Operator 项目迁移为 Kubebuilder 风格的新布局config/Makefile/PROJECT体系。你将掌握新旧目录结构的对应关系、新项目初始化与 API 重建的完整命令流程、watches.yaml与 RBAC 的迁移要点、废弃环境变量的处理方式以及迁移后的集群部署验证方法并深入理解这些步骤背后的 SDK 源码实现。背景为什么要迁移新版布局的引入是为了给用户带来更大的灵活性同时也是 Operator SDK 与 Kubebuilder 深度整合Integrating Kubebuilder and Operator SDK进程的一部分。由于这一整合迁移过程中部分主题会涉及 Kubebuilder 官方文档本文档提及$ kubebuilder command处实际使用时请一律替换为$ operator-sdk command。重要提示官方建议在迁移到新布局之前先将项目升级到最新的 SDK v1.y 系列版本再从旧版本开始迁移。当然从更早的版本出发迁移也可能可行如果遇到本文未覆盖的问题请查阅仓库中 历史迁移指南 获取帮助。变化总览旧的deploy目录去哪了发生了哪些变化迁移的核心是把旧的deploy目录替换为全新的config目录Kubernetes 清单文件的组织方式随之重排旧布局pre-v1.0.0新布局v1.0.0deploy/crds/中的 CRD 清单config/crd/basesdeploy/crds/中的 CR 清单config/samplesdeploy/operator.yaml控制器清单config/manager/manager.yamldeploy中的 RBAC 清单config/rbac/build/Dockerfile项目根目录Dockerfile这一变化与 SDK 初始化脚手架的源码实现完全对应internal/plugins/helm/v1/scaffolds/init.go中的initScaffolder会依次生成Dockerfile、.gitignore、Makefile、watches.yaml和config/rbac下的角色清单并预先创建helm-charts目录存放将要管理 release 的 Helm chart。新增了什么新脚手架项目引入了以下机制internal/plugins/helm/v1/init.go中initSubcommand.UpdateMetadata的说明与之一致kustomize用于管理部署 Operator 所需的 Kubernetes 资源Makefile提供构建、测试、部署等实用 target并允许按项目需求定制更新后的指标metrics配置使用 kube-rbac-proxykube-auth-proxy、--metrics-bind-address标志以及基于 kustomize 部署的 KubernetesService与 prometheus operatorServiceMonitorCLI 插件的初步支持详见仓库中 plugins 设计文档plugins 源码PROJECT配置文件存储关于 GVK、插件的信息帮助 CLI 做出决策。从源码看Helm 插件注册为base.helm见 internal/plugins/helm/v1/plugin.go同时实现Init与CreateAPI两个子命令接口并在init阶段向config/manager/manager.yaml注入--leader-election-id参数、向config/default/manager_metrics_patch.yaml注入--metrics-bind-address:8443、--metrics-secure与--metrics-require-rbac等指标暴露参数。默认 API 版本的变化新生成文件默认使用以下 API 版本CRD 默认生成apiextensions/v1apiextensions/v1beta1自 Kubernetes 1.16 起被弃用并将在 1.22 中移除Webhook 默认生成admissionregistration.k8s.io/v1admissionregistration.k8s.io/v1beta1同样自 1.16 弃用、1.22 移除。SDK 源码同样体现了这一点internal/plugins/helm/v1/api.go中defaultCrdVersion v1且--crd-version标志已被标记为 deprecated仅保留对v1beta1的兼容告警。迁移步骤初始化新项目 → 重建 API → 搬运配置官方推荐的轻松迁移路径是初始化一个新项目 → 重新创建 API → 将 pre-v1.0.0 的配置文件拷贝进新项目。下面按步骤展开。前置条件先阅读 安装指南 完成operator-sdkCLI 安装确保你的用户拥有cluster-admin权限准备一个可访问的镜像仓库如 Docker Hub、Quay.io并在命令行环境完成登录。下文示例以example.com作为镜像仓库命名空间如使用其他仓库或命名空间请自行替换若仓库为私有或使用自定义 CA请参考 私有 Bundle 与 Catalog 镜像仓库配置 处理认证与证书。第 1 步确定 domain初始化新项目在 Kubebuilder 风格的项目中CRD group 由两个不同的标志--group与--domain共同定义。初始化新项目时必须指定项目中所有API 共享的 domain因此先要确定现有项目中 API 使用的 domain。如何确定 domain查看deploy/crds目录下 CRD 的spec.group字段。domain 是该值第一个 DNS 段之后的部分——例如demo.example.com对应的--domain为example.com。创建同 domainexample.com的新项目mkdir nginx-operator cd nginx-operator operator-sdk init --pluginshelm --domainexample.com--pluginshelm会激活上述base.helm插件internal/plugins/helm/v1/plugin.go。初始化生成的目录结构包括helm-charts/、watches.yaml、PROJECT、Makefile、config/manager、default、rbac、crd 等 kustomize 基础目录。第 2 步逐个重建 API新项目初始化完成后需要为旧项目中每一个API 重新创建。以demo.example.com为例--group取demo--version取 CRD 中spec.versions[0].name--kind取 CRD 中spec.names.kind。对每个 API 执行operator-sdk create api \ --groupdemo \ --versionversion \ --kindKind \ --helm-chartpath_to_existing_project/helm-charts/chartcreate api的子命令解析位于 internal/plugins/helm/v1/api.go--helm-chart指定 chart 来源支持本地 chart 目录、本地 chart 归档.tgz、远程仓库 chart配合--helm-chart-repo与--helm-chart-version以及 OCI 地址若不提供 chart则以--kind的小写形式作为 chart 名新建一个空 chart当提供 chart 但未提供--group/--version/--kind时会自动回退到默认值group 为charts、version 为v1alpha1、kind 取 chart 名的驼峰形式见defaultGroup/defaultVersion常量与InjectResource逻辑生成的 CRD 默认使用apiextensions/v1--crd-version标志已标记废弃同一个项目中只允许使用一种 CRD 版本且默认单 group 项目禁止混入其他 group如需多 group 需在PROJECT中设置multigroup: true。第 3 步迁移 Custom Resource 示例用旧项目deploy/crds/group_version_kind_cr.yaml中的 CR 值更新新项目config/samples下的 CR 清单。第 4 步迁移watches.yaml检查旧项目watches.yaml中是否有自定义选项若有则同步更新新项目的watches.yaml。以 nginx 示例为例新文件形如# Use the create api subcommand to add watches to this file. - group: example.com version: v1alpha1 kind: Nginx chart: helm-charts/nginx #kubebuilder:scaffold:watch注意切勿移除kubebuilder:scaffold:watch标记。从 internal/plugins/helm/v1/scaffolds/internal/templates/watches.go 可以看到WatchesUpdater正是依靠这一 marker 定位插入点从而在每次创建新 API 时自动更新 watches 文件移除它会破坏后续的自动注入能力。从 internal/helm/watches/watches.go 的Watch结构体可以看到除上述字段外每条 watch 还支持以下自定义选项如旧项目用到了可一并迁移字段说明默认行为watchDependentResources是否同时监控由 chart 创建的依赖资源默认trueoverrideValues覆盖 chart values 的键值映射支持环境变量展开与模板函数sprig无selector标签选择器仅监控匹配的 CR空全部reconcilePeriod该 watch 专属的调谐周期未设置时使用运行参数--reconcile-period默认 1 分钟dryRunOption渲染模式的 dry-run 行为无Load()对应运行时 internal/cmd/helm-operator/run/cmd.go 中的watches.Load会校验每条记录的 GVK、chart 目录有效性并拒绝重复 GVK 配置。第 5 步检查 RBAC 权限新项目中角色会自动生成在config/rbac/role.yaml脚手架由initScaffolder中的rbac.ManagerRole{}模板写入见 internal/plugins/helm/v1/scaffolds/init.go。如果你在旧项目deploy/role.yaml中手工修改过权限需要在新项目config/rbac/role.yaml中重新应用。新项目默认监控所有命名空间因此需要ClusterRole才能拥有相应权限。若想保留新项目约定的默认行为请确保config/rbac/role.yaml仍然是ClusterRole。早期版本 helm-operator 会自动创建并管理用于指标采集的 Service 与 ServiceMonitor曾使用如下规则如果你的 chart 并不需要这些规则可以安全地将其从新config/rbac/role.yaml中移除- apiGroups: - monitoring.coreos.com resources: - servicemonitors verbs: - get - create - apiGroups: - apps resourceNames: - nginx-operator resources: - deployments/finalizers verbs: - update更新 ServiceAccount新 Helm 项目在config/rbac/service_account.yaml中自带一个名为controller-manager的 ServiceAccount。项目的 RoleBinding、ClusterRoleBinding subjects 以及 Deployment 的spec.template.spec.serviceAccountName默认都已引用这个新名称。执行make deploy时项目名会作为前缀拼接到controller-manager之前使其在命名空间内唯一——这与旧deploy/service_account.yaml的做法类似。若仍想沿用旧的 ServiceAccount请务必同步更新所有 RBAC 绑定与 manager Deployment。第 6 步配置 Operatormanager 清单与废弃环境变量如果旧项目在deploy/operator.yaml中有自定义内容需要移植到config/manager/manager.yaml。如果 Deployment 中传入了自定义参数记得同步更新config/default/auth_proxy_patch.yaml。以下环境变量已不再使用OPERATOR_NAME已废弃。它曾用于定义 leader election 的 configmap 名称现在 Operator 作者应改用--leader-election-id。SDK 运行时源码 internal/cmd/helm-operator/run/cmd.go 中保留了兼容逻辑若检测到OPERATOR_NAME环境变量会打印废弃提示且仅在--leader-election-id未设置时才以它作为回退值。POD_NAME在 Helm operator 使用 leader for life 机制时它用于指定持有 leader election 锁的 Pod。如今 Helm operator 改用 controller-runtime 的leader with lease机制POD_NAME不再必要。从 internal/helm/flags/flag.go 可以看到--leader-elect与--leader-election-id已成为标准参数且LeaderElectionResourceLock默认使用LeasesResourceLock。第 7 步导出指标可选如果你在用指标功能并希望继续导出需要在config/default/kustomization.yaml中完成配置具体配置方法请参考 metrics 相关文档仓库 Helm 示例项目 testdata/helm/memcached-operator/config/prometheus 中有可直接参照的 kustomize 结构。端口变化指标端点默认绑定端口由:8383改为:8080。如需继续使用8383端口可在启动 Operator 时指定--metrics-bind-address:8383。该默认值在 internal/helm/flags/flag.go 中定义--metrics-bind-address默认:8080旧的--metrics-addr已被标记废弃同时新版本还提供了--metrics-secureHTTPS 安全暴露与--metrics-require-rbac基于 RBAC 的认证鉴权保护要求必须同时开启--metrics-secure等新能力。验证迁移结果迁移完成后即可部署到集群make deploy IMGexample.com/nginx-operator:v0.0.1部署出问题时可查看容器日志定位kubectl logs deployment.apps/nginx-operator-controller-manager -n nginx-operator-system -c manager关于 Operator 部署、Custom Resource 创建与资源清理的后续操作请参阅 Helm 教程中的运行章节。参考资料与仓库依据迁移文档原文website/content/en/docs/building-operators/helm/migration.md安装指南website/content/en/docs/building-operators/helm/installation.mdHelm 插件注册与子命令实现internal/plugins/helm/v1/plugin.go、internal/plugins/helm/v1/init.go、internal/plugins/helm/v1/api.go初始化脚手架生成 Dockerfile / Makefile / watches / RBACinternal/plugins/helm/v1/scaffolds/init.gowatches 文件解析与校验internal/helm/watches/watches.goHelm operator 运行参数metrics 端口、leader election 等internal/helm/flags/flag.go、internal/cmd/helm-operator/run/cmd.go新布局参考示例仓库 Helm 测试项目 testdata/helm/memcached-operator含config/、helm-charts/、watches.yaml、PROJECT的完整新结构赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐LinkSwift网盘直链下载助手深度指南九大网盘高效下载的终极解决方案LinkSwift网盘直链下载助手深度指南九大网盘高效下载的终极解决方案 在数字化办公与学习成为常态的今天网盘已成为我们存储和分享文件的核心工具。然而官方云原生后端开发工具微服务Jenkins Job DSL测试策略确保你的作业定义稳定可靠Jenkins Job DSL测试策略确保你的作业定义稳定可靠 Jenkins Job DSL是一种基于Groovy的领域特定语言用于以代码方式定义JenkPDF-Lib 从 v0.x.x 迁移到 v1.0.0 的完整指南PDF Lib 从 v0.x.x 迁移到 v1.0.0 的完整指南 前言 PDF Lib 是一个功能强大的 JavaScript PDF 操作库允许开发者在浏开发工具上一篇Handsontable 12.x 完整版本演进解析RTL 支持、快捷键 API 重构与公式引擎深度同步下一篇Prowlarr日志分析与调试终极指南快速定位系统问题的10个技巧创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表