开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载2024 年是 Kubebuilder 从功能加法转向精简与合规的关键一年。本指南以仓库 roadmap/roadmap_2024.md 为核心骨架系统梳理该年度五大战略目标——脚手架对齐 controller-runtime 最新演进、新增 Helm Chart 打包插件、基础设施从 GCP 迁往 Kubernetes 共享体系、kube-rbac-proxy 退出默认脚手架、以及 4.x 大版本移除废弃插件并结合作者仓库中的设计文档与真实脚手架产物testdata给出可验证的落地细节。读完本文你将理解 Kubebuilder 2024 年各项决策背后的动机、影响范围与迁移路径并掌握build-installer分发、NetworkPolicy 保护 metrics 端点等实操手段。路线图总览2024 年的五大核心目标Kubebuilder 的路线图由 roadmap/README.md 统一组织按年度拆分为 roadmap_2024.md、roadmap_2025.md、roadmap_2026.md每个目标条目遵循统一的模板Status / Objective / Context / Motivations / References。2024 年路线图列出的目标及其最终状态如下目标状态影响版本/产物脚手架对齐 controller-runtime 最新变更✅ 完成自 release4.3.0起生效新增可选插件Helm Chart 打包✅ 完成初版已合并欢迎后续改进PR #4227构建与发布从 GCP 迁往共享基础设施✅ 完成CLI、kube-rbac-proxy 镜像、EnvTest 二进制GoReleaser、registry.k8s.iokube-rbac-proxy 退出默认脚手架✅ 完成自 release3.15.0起不再默认生成移除废弃插件4.x 大版本✅ 完成已发布模块 bump PR #3924这些目标并非彼此孤立例如去 kube-rbac-proxy 化同时牵动基础设施迁移与 metrics 端点安全方案的重构而移除废弃插件则是 4.x 大版本整理的一部分。下文逐一展开。一、脚手架对齐 controller-runtime 的最新变化背景稳定的插件系统 vs 快速演进的 controller-runtimeKubebuilder 的插件系统设计上追求稳定但它所依赖的 controller-runtime 仍在快速演进当时版本仍低于 1.0.0。controller-runtime 中围绕 webhook 的若干变更与弃用deprecation直接影响 Kubebuilder 生成的脚手架、示例与文档。为此2024 年路线图将该目标列为第一优先级更新 Kubebuilder 的 controller 脚手架、samples 与文档使其与 controller-runtime 的最新实践保持一致。落地与验收release 4.3.0该目标于 release4.3.0完成主要工作集中在 webhook 相关接口的适配。仓库中的对应实现可参考 pkg/plugins/golang/v4 下的 webhook 脚手架webhook.go以及 testdata/project-v4/internal/webhook 中真实生成的 webhook 代码后者是验证脚手架输出是否符合新接口的直接样本。用户在升级到 4.3.0 后重新生成的 webhook 代码将遵循 controller-runtime 最新的 handler 接口约定。关于 webhook 的基础概念与手工接入方式可进一步参考 docs/book/src/reference/webhook-overview.md 与 docs/book/src/reference/admission-webhook.md。二、新增可选插件Helm Chart 打包helm/v2alpha动机让解决方案可分发、可集成Kubernetes 生态的快速增长使得解决方案的分发方式需要更灵活、更易获取。Kubebuilder 社区由此提出为项目提供 Helm Chart 打包能力简化解决方案在集群中的分发与集成方便管理员与常见应用结合使用。现状初版已合并社区协作持续推进该目标状态为✅ 完成初版已合并欢迎进一步改进与贡献。实现位于 pkg/plugins/optional/helm/v2alpha是 Kubebuilder 的可选插件之一——它不进入默认脚手架而是由用户按需启用。这与 roadmap/README.md 中聚焦项目范围、最小化第三方依赖的总方针一致Kubebuilder 作为库提供插件 API具体集成交由最了解自身项目的维护者完成。可选插件家族中与 helm 并列的还有 pkg/plugins/optional/grafana/v1alphaGrafana 面板与 pkg/plugins/optional/autoupdate/v1alpha自动更新它们共同体现了按需扩展、默认精简的设计哲学。三、基础设施迁移从 GCP 走向 Kubernetes 共享体系目标与动机Kubernetes 项目整体倡导从 GCP 迁移到共享基础设施并将镜像仓库从k8s.gcr.io迁往registry.k8s.io。Kubebuilder 2024 路线图明确跟进这一倡议动机包括确保构建产物的长期可用性、与 kubernetes-sigs 组织下其他项目保持一致、降低对可能被单方面关停的 GCP 项目的依赖可参考 designs/discontinue_usage_of_kube_rbac_proxy.md 中对 GCP 依赖风险的论述。迁移范围与状态产物状态说明Kubebuilder CLI 发布✅ 完成改用 GoReleaser 构建与发布kube-rbac-proxy 镜像✅ 完成见社区讨论 #3907EnvTest 二进制✅ 完成controller-runtime 维护者接手在其项目内构建预计自 v0.19 起对用户透明PR Check 镜像 寻求贡献涉及 kubebuilder-release-tools 项目计划使用 e2e 共享基础设施值得强调的是GCP 当时仅用于三类工作重建并托管 kube-rbac-proxy 镜像该镜像的构建配置记录在 RELEASE.md 的 To build the kube-rbac-proxy images 小节、构建与发布 EnvTest 二进制对应 RELEASE.md 的 To build the kubebuilder-tools artifacts 小节以及 PR 标题检查镜像。路线图明确邀请社区参与讨论、提供反馈以共同塑造更安全高效的脚手架方案。四、kube-rbac-proxy 退出默认脚手架3.15.0 起这是 2024 年路线图中影响面最大的一项变更其完整设计记录在 designs/discontinue_usage_of_kube_rbac_proxy.md状态为 Implementable作者 camilamacedo86。该设计文档既是路线图条目的依据也是理解迁移细节的第一手资料。为什么要移除多重压力叠加基础设施可靠性kube-rbac-proxy 不属于 Kubernetes 伞形组织其镜像依赖 Google 基础设施重建与托管GCR 宣布弃用后此前由 Kubebuilder 提供的全部 kube-rbac-proxy 镜像在 2025 年 4 月 22 日后将不可用。安全与背书kube-rbac-proxy 长期处于加入 Kubernetes auth-sig 的流程中但尚未获得官方背书auth-sig 审查要求其进行重大更新。社区反馈部分社区成员认为 kube-rbac-proxy 过于教条issue #3482倾向默认集成 cert-manager 以配合 Prometheus 与 metrics 的安全诉求issue #3657。维护负担为第三方项目重建镜像、持续打标签给 Kubebuilder 维护者带来沉重负担。结论自 3.15.0 起不再默认生成并给出两条出路设计文档明确了分阶段迁移路径Phase 1即刻执行以 Kubernetes NetworkPolicy 取代 kube-rbac-proxy对应 PR #3853 与发布说明中的迁移指引。Phase 2可选增强将 cert-manager 作为可选选项与 metrics 结合实现 metrics 端点的加密通信对应 config/default/kustomization.yaml 中[METRICS-WITH-CERTS]一节的cert_metrics_manager_patch.yaml挂载逻辑。Phase 3待 controller-runtime 增强利用 controller-runtime 新增的 metrics 安全服务特性MetricsFilterProvider/MetricsSecureServing见 main.go 中对应的配置模式。Phase 4未来一旦 kube-rbac-proxy 进入 Kubernetes 伞形组织则通过 Kubebuilder 外部插件 API 提供集成用户可显式执行kubebuilder init|edit --pluginskube-rbac-proxy/v1按需启用。对于现有用户设计文档给出的两条出路是改用 kube-rbac-proxy 项目自身在 quay.io 托管的镜像或按照更新后的脚手架指引改用 NetworkPolicy。当前脚手架中的落地形态NetworkPolicy 保护 metrics 端点在仓库的 v4 测试项目中可以找到 NetworkPolicy 的实际落地产物testdata/project-v4/config/network-policy/allow-metrics-traffic.yaml仅允许来自带有metrics: enabled标签命名空间中的 Pod访问 controller-manager 的 8443 端口TCP。testdata/project-v4/config/network-policy/kustomization.yaml同时注册allow-webhook-traffic.yaml与allow-metrics-traffic.yaml。在 config/default/kustomization.yaml 中../network-policy默认以注释形式存在#- ../network-policy用户取消注释即可启用——这正体现了设计文档中允许用户按需开关的灵活性。NetworkPolicy 的本质是集群 CNI 层面的简单防火墙它只控制 IP/端口层面的流量不提供 authn/authz 与加密设计文档对此坦诚回应通过叠加 cert-manager 证书与 controller-runtime 的 metrics 安全特性可以在不引入额外第三方依赖的前提下达到相同或更优的保护水平。需要提醒的是NetworkPolicy 的执行依赖集群 CNI 的支持——Calico、Cilium、WeaveNet、Canal 以及更新后的 Amazon VPC CNI 均支持但用户在采用前仍需确认自身 CNI 能力。metrics 端点的新式安全配置样例设计文档给出了配合 cert-manager 的 ServiceMonitor 示例。在当前的 v4 脚手架中metrics 相关配置分布在metrics_service.yamlmetrics Service暴露 8443 端口。manager_metrics_patch.yaml为 manager 容器追加--metrics-bind-address:8443参数启用 HTTPS metrics 端点。cert_metrics_manager_patch.yaml挂载 metrics-server 证书ca.crt/tls.crt/tls.key并追加--metrics-cert-path参数。上述配置的完整讲解可参考 docs/book/src/reference/metrics.md其中对 HTTPS metrics 端点、ServiceMonitor 与证书注入有更细致的说明。五、项目分发辅助build-installerMakefile 目标v3.14.0 起为了让 Kubebuilder 项目更容易部署到集群2024 路线图将Kustomize 分发列为已完成目标自 releasev3.14.0起脚手架新增了build-installerMakefile 目标。实操一键生成可分发的 install.yaml在任一 v4 项目中执行make build-installer IMGregistry/project:tag即可在项目dist/目录下生成一个聚合了 CRD 与 Deployment 的dist/install.yaml。其实现位于 testdata/project-v4/Makefile.PHONY: build-installer build-installer: manifests generate kustomize ## Generate a consolidated YAML with CRDs and deployment. mkdir -p dist cd config/manager $(KUSTOMIZE) edit set image controller${IMG} $(KUSTOMIZE) build config/default dist/install.yaml注意该目标先依赖manifests generate kustomize确保 CRD 与生成的代码是最新的然后用kustomize edit set image注入镜像最后将config/default的全部资源含 CRD、RBAC、manager、可选的 webhook/certmanager/network-policy折叠为单个 YAML。生成后即可直接通过 URL 部署kubectl apply -f https://raw.githubusercontent.com/org/my-project/tag or branch/dist/install.yaml这一能力极大降低了 Kubebuilder 项目上集群的门槛将dist/install.yaml托管到任意静态站点或 Git 仓库即可让用户一条命令完成部署。六、4.x 大版本移除废弃插件提升可维护性与用户体验目标与动机随着 Kubebuilder 演进到 CLI 4.x维护已无法继续支持的旧插件版本/种类代价高昂。2024 路线图将移除全部废弃插件列为大版本目标动机在于精简开发流程、消除用户困惑并以清晰更新的文档提升整体用户体验。落地废弃移除 模块 bump该目标已完成并发布移除弃用对应 issue #3603 的清理工作将不再支持的插件版本/种类从代码库中删除。模块 bump对应 PR #3924将 Kubebuilder 主模块版本提升至 4.x使插件版本语义与 CLI 版本体系对齐避免旧插件与新 CLI 的兼容歧义。对用户而言升级到 4.x 意味着不再能使用被移除的旧版插件需要检查自身项目的 PROJECT 文件 中所声明的插件版本确保其属于 4.x 支持的集合必要时使用kubebuilder的迁移/重新生成能力更新脚手架。如何跟进与参与后续路线图Kubebuilder 的路线图迭代机制保持开放社区可以对照 roadmap/README.md 中的条目模板提出新目标通过 CONTRIBUTING.md 提交 issue 或 PR。2024 年之后的方向可查看 roadmap_2025.md 与 roadmap_2026.md。作者仓库中的设计文档目录 designs 还沉淀了 crd 版本转换、extensible CLI 插件阶段设计、简化脚手架等提案与年度路线图互为补充是理解 Kubebuilder 演进脉络的高价值资料。结语2024 年路线图的启示回顾 2024 年 Kubebuilder 的五项目标可以清晰看到一条主线在保证脚手架稳定的前提下持续降低对第三方依赖与外部基础设施的耦合。无论是 webhook 接口对齐 controller-runtime、以 Helm 插件扩展分发能力、将构建发布迁往共享基础设施还是以 NetworkPolicy cert-manager 组合取代 kube-rbac-proxy、在大版本中清理废弃插件最终都指向同一个目标——让 Kubebuilder 生成的 Go 项目更安全、更易维护、更可持续地长期运行在 Kubernetes 生态中。对于正在使用或计划采用 Kubebuilder 的开发者理解这些变化及其迁移路径是顺利升级到 3.15/4.x 并保障项目长期健康的关键前提。赞分享开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载相关推荐Kubernetes 项目基础设施迁移实录SIG K8s Infra 2020 年度报告解读与 CNCF 迁移路线图Kubernetes 项目基础设施迁移实录SIG K8s Infra 2020 年度报告解读与 CNCF 迁移路线图 本文基于 SIG K8s Infra 2开源治理文档研发协作Kubernetes SIG Testing 2024 年度报告解读Prow 控制平面迁移与测试基础设施社区化演进Kubernetes SIG Testing 2024 年度报告解读Prow 控制平面迁移与测试基础设施社区化演进 导读 本文基于 sig testing/a开源治理文档研发协作Kubernetes SIG K8s Infra 2024 年度报告解读Azure 集成、Prow 迁移与镜像仓库去 Google 化之路Kubernetes SIG K8s Infra 2024 年度报告解读Azure 集成、Prow 迁移与镜像仓库去 Google 化之路 SIG K8s I开源治理文档研发协作上一篇3行代码解决90%的栈问题LeetCode87双端队列黑科技下一篇一键保存网页所有资源Resources Saver扩展让你的工作效率翻倍创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考