开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载Kubebuilder 在 3.15.0 版本起不再在新脚手架的默认配置中引入 kube-rbac-proxy转而采用 Kubernetes 原生 NetworkPolicy、可选的 cert-manager 以及 controller-runtime 的指标安全特性来保护 /metrics 端点。本文基于仓库中的设计文档 designs/discontinue_usage_of_kube_rbac_proxy.md梳理该决策的动机、四阶段落地计划、风险与替代方案并结合仓库内脚手架 testdatatestdata/project-v4展示升级后的真实清单配置帮助读者理解如何迁移既有项目、如何按需启用 HTTPS 指标服务。背景为什么要弃用 kube-rbac-proxykube-rbac-proxy 是业界常用的边车sidecar代理曾长期作为 Kubebuilder 默认脚手架中保护/metrics端点的手段。然而随着 Kubernetes 基础设施生态的演进Kubebuilder 维护者重新评估了这一默认依赖核心考量如下共享基础设施迁移Kubernetes SIG 项目要求所有镜像发布到registry.k8s.io而该发布流程只对 Kubernetes umbrella 内的项目生效Google Container RegistryGCR停服Google Cloud Platform 官方宣布弃用 Container Registry意味着 Kubebuilder 此前发布在gcr.io/kubebuilder/kube-rbac-proxy的镜像在2025 年 4 月 22 日起将不可再被获取未纳入 Kubernetes umbrellakube-rbac-proxy 尚未正式进入 Kubernetes Auth SIG 的官方支持范围Kubernetes Auth SIG 的评审显示其仍需大量改动才能获得官方背书维护权不在自身Kubebuilder 维护者无法持续、可靠地为第三方项目构建和推送镜像这违背了项目可被维护者持续支撑的目标。其中最关键的一点是依赖一个可能随时被停用的 Google 基础设施且这种停用不在我们控制范围内这对项目可靠性和镜像可用性构成了直接风险。社区对此也有明确诉求见 issue #3482社区成员希望将其从默认脚手架移除与 #3230镜像可用性风险。目标与非目标界定改造边界目标最大化指标端点保护不新增第三方依赖在不需要构建、推送第三方镜像的前提下提供尽可能高的保护等级避免破坏性变更用旧版本生成项目的用户仍可使用新版本脚手架并可按自己的节奏迁移可持续维护所有由 Kubebuilder 脚手架生成的项目都应由其维护者可持续地支撑摆脱 Google Cloud Platform 依赖考虑到 GCP 可能单方面关停服务主动迁移符合 Kubernetes umbrella 规范不再推广或背书尚未被 Kubernetes umbrella 组织认可、且随工作负载一起交付的方案推广外部插件 API遵循 Kubebuilder 通过外部插件external plugins支持第三方集成的指导方针让第三方项目维护者自己维护与脚手架集成的实现网络策略使用可灵活开关允许用户选择不使用 NetworkPolicy例如打算使用不支持的 CNI 或供应商方案时。非目标需要明确的是本提案不以复刻 kube-rbac-proxy 的功能或同等保护级别为目标。NetworkPolicy 与 kube-rbac-proxy 的工作方式不同——前者是基于 IP 地址/端口层级的简单防火墙不直接提供 authn/authz 与加密能力。因此仅靠 NetworkPolicy 无法达到与 kube-rbac-proxy 完全一致的保护水平。不过通过组合 NetworkPolicy、cert-manager 以及 controller-runtime 引入的新特性PR #2407可以从整体上回应 kube-rbac-proxy 所处理的主要安全关切。四阶段落地计划提案将整个迁移拆解为四个阶段每阶段都必须伴随对应的文档更新文档更新要求确保最终用户理解如何启用、配置和使用这些选项。阶段一过渡到 NetworkPolicy默认行为这是本提案的立即行动用 Kubernetes 原生 NetworkPolicy 替换 kube-rbac-proxy。从release 3.15.0开始Kubebuilder 不再为新项目脚手架 kube-rbac-proxy默认启用 NetworkPolicy 保护。仓库 testdata 中已经固化了这一脚手架形态见 testdata/project-v4/config/network-policyallow-metrics-traffic.yaml仅允许来自带有metrics: enabled标签的命名空间中的 Pod 访问 8443 端口即指标端口把抓取指标的行为显式限定在已打标签的命名空间内apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: project-v4 app.kubernetes.io/managed-by: kustomize name: allow-metrics-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager app.kubernetes.io/name: project-v4 policyTypes: - Ingress ingress: # Allow pods in namespaces labeled metrics: enabled to scrape metrics. - from: - namespaceSelector: matchLabels: metrics: enabled # Only from namespaces with this label ports: - port: 8443 protocol: TCPallow-webhook-traffic.yaml允许所有来源访问 Webhook 的 9443 Pod 端口Kubernetes API server 需要通过 Service 访问准入与 CRD 转换 WebhookapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: project-v4 app.kubernetes.io/managed-by: kustomize name: allow-webhook-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager app.kubernetes.io/name: project-v4 policyTypes: - Ingress ingress: - ports: - port: 9443 protocol: TCPkustomization.yaml将以上两个资源聚合为一个可被 kustomize 引用的组件。在项目根配置 testdata/project-v4/config/default/kustomization.yaml 中network-policy 默认处于注释状态用户按需取消注释即可启用# [NETWORK POLICY] Control ingress to metrics and webhook ports.下的#- ../network-policy由于它是默认脚手架的一部分新项目可通过取消注释直接开启。这一设计同时满足了默认启用体现在脚手架上与用户可自由 opt-out通过注释两个要求——例如当用户使用不支持 NetworkPolicy 的 CNI 时可以整体跳过该组件。开放问题 1 的回应NetworkPolicy 虽然属于 Kubernetes 核心 API但其强制执行依赖集群安装的 CNI 插件。主流 CNICalico、Cilium、WeaveNet、Canal均支持 NetworkPolicyAWS 此前不支持但 Amazon VPC CNI 已宣布支持 Kubernetes Network Policies。此外在该提案下用户仍可按需启用/禁用该选项。阶段二将 cert-manager 作为指标的可选选项在第一阶段落地对应开源 PR #3853之后提案设想引入 cert-manager 做 TLS 证书管理并与 controller-runtime 的新特性PR #2407形成协同为指标端点带来加密通信乃至基于 mTLS 的认证能力显著提升脚手架项目的安全模型。cert-manager自动化 TLS 证书的签发与管理配置 mTLS 时还能增加一层认证。目前 Kubebuilder 在脚手架 Webhook 时已使用 cert-manager提案的思路是让用户能像 Webhook 一样为指标启用 cert-manager必须保持可选Kubebuilder 的目标之一是降低新用户门槛因此默认脚手架与快速开始流程不应强制用户安装 cert-manager只有在启用 Webhook、启用指标 HTTPS 等特定功能时才建议使用。实现方式是在config/default/kustomization.yaml中引入一个可配置的 Kustomize patch用于同时 patchconfig/prometheus/monitor.yaml中的 ServiceMonitor 与证书类似现有 Webhook 的做法现有 Webhook 场景下config/default/kustomization.yaml已通过 replacements 注入 cert-manager CA 注入注解覆盖 ValidatingWebhookConfiguration、MutatingWebhookConfiguration 与 CRD。提案设计了一个名为metrics_https_patch.yaml的 patch 文件启用方式为# [METRICS WITH HTTPS] To enable the ServiceMonitor using HTTPS, uncomment the following line # Note that for this to work, you also need to ensure that cert-manager is enabled in your project - path: metrics_https_patch.yaml启用 cert-manager 后的 ServiceMonitor 示例如下这是提案给出的目标形态强调生产环境不应跳过 TLS 校验# Prometheus Monitor Service (Metrics) with cert-manager apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: control-plane: controller-manager app.kubernetes.io/name: project-v4 app.kubernetes.io/managed-by: kustomize name: controller-manager-metrics-monitor namespace: system annotations: cert-manager.io/inject-ca-from: $(NAMESPACE)/controller-manager-certificate spec: endpoints: - path: /metrics port: https scheme: https bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token tlsConfig: # We should recommend ensure that TLS verification is not skipped in production insecureSkipVerify: false caFile: /etc/prometheus/secrets/ca.crt # CA certificate injected by cert-manager certFile: /etc/prometheus/secrets/tls.crt # TLS certificate injected by cert-manager keyFile: /etc/prometheus/secrets/tls.key # TLS private key injected by cert-manager selector: matchLabels: control-plane: controller-manager仓库中已固化的可对照实现虽然metrics_https_patch.yaml本身是提案中的规划产物但仓库 testdata 已经实现了与之同构的cert-manager 保护指标配置可作为落地参考cert_metrics_manager_patch.yaml通过 Kustomize 为 manager Deployment 添加volumeMounts、--metrics-cert-path/tmp/k8s-metrics-server/metrics-certs参数并挂载来自metrics-server-certSecret 的ca.crt、tls.crt、tls.keycertificate-metrics.yaml定义一个由selfsigned-issuer签发的metrics-certsCertificatednsNames由config/default/kustomization.yaml中的 replacements 注入SERVICE_NAME.SERVICE_NAMESPACE.svc(.cluster.local)monitor_tls_patch.yaml将 ServiceMonitor 的tlsConfig替换为从metrics-server-certSecret 读取ca、cert与keySecret并把insecureSkipVerify置为false未使用 cert-manager 时脚手架默认的 monitor.yaml 使用insecureSkipVerify: true并注释明确提示生产环境不推荐该配置、建议启用 cert-manager。启用上述 HTTPS 指标链路的入口同样是 config/default/kustomization.yaml 中注释掉的cert_metrics_manager_patch.yaml与[METRICS-WITH-CERTS]段以及默认启用的manager_metrics_patch.yaml通过--metrics-bind-address:8443让 manager 以 HTTPS 暴露指标。指标 Service 定义见 metrics_service.yaml其https端口为 8443。开放问题 2 与 6 的回应NetworkPolicy 确实不提供 authn/authz 与加密但结合 cert-manager 与 controller-runtime 新特性可以达到同等甚至更高的保护水平且无第三方依赖同时 cert-manager 不能被默认强制启用——Kubebuilder 的目标是让新用户快速上手但可以对 Webhook、指标 HTTPS 等特定高级功能做强制要求。阶段三利用增强后的 controller-runtime 特性controller-runtime 的 issue #2781 跟踪了指标端点安全配置对齐最佳实践的诉求。在该问题得到解决后提案计划直接用 controller-runtime 的能力保护指标端点同时处理authn认证与 authz授权。实现示例参考了 cluster-api 项目的util/flags/diagnostics.go。将来启用该能力时main.go中 manager 的构造将形如ctrlOptions : ctrl.Options{ MetricsFilterProvider: filters.WithAuthenticationAndAuthorization, MetricsSecureServing: true, }开放问题 5 的回应是的可以在修复若干问题后使用 controller-runtime 的 HTTPS 安全指标服务特性——但该配置需要与最佳实践对齐这正是 issue #2781 的跟踪目标。开放问题 3 与 4 的回应Kubebuilder 曾尝试借助共享基础设施继续构建并推送镜像test-infra 中有对应 recipe但 kube-rbac-proxy 不在 Kubernetes umbrella 下而无法生效也实验过用 GitHub 仓库作为替代PR #3854但似乎不被允许。而 EnvTest 使用的二进制同样面临此问题controller-runtime 维护者已计划在自己项目内构建这些二进制该变更对社区用户大概率是透明的——这进一步印证了Kubebuilder 不应负责维护和推广第三方制品的立场。阶段四kube-rbac-proxy 进入 umbrella 后以外部插件回归一旦 kube-rbac-proxy 被纳入 Kubernetes umbrella可跟踪 brancz/kube-rbac-proxy#238 与 创建插件将其集成用户即可按需选择kubebuilder init|edit --pluginskube-rbac-proxy/v1该插件可复用 pkg/plugin/util 提供的代码操作工具——例如 util.go 中的UncommentCode搜索目标内容并移除注释前缀用于打开config/default/kustomization中被注释的 patch、启用 NetworkPolicy 的默认禁用以及 util.go 中的ReplaceInFile替换文件中全部匹配内容用于把main.go中的指标安全配置替换为 controller-runtime 原生特性。这一方案让 kube-rbac-proxy 以用户自行 opt-in的方式融入脚手架符合 Kubebuilder 通过插件 API 支持第三方集成的方针——第三方项目维护者最熟悉自己的方案由其维护集成实现最有利于用户体验。开放问题与官方回应#问题官方回应要点1NetworkPolicy 由集群 CNI 实现主流 CNI 是否支持虽然依赖 CNI 插件但 Calico、Cilium、WeaveNet、Canal 均支持AWS 的 Amazon VPC CNI 现已支持 NetworkPolicy用户仍可自行启用/禁用2NetworkPolicy 只是简单防火墙不提供 authn/authz 与加密正确但结合 cert-manager 与 controller-runtime 新特性可获得同等或更优保护且不引入额外第三方依赖3能否用共享基础设施继续构建/推广这些镜像试过 test-infra recipe但因 kube-rbac-proxy 不在 umbrella 下不生效GitHub 仓库方案PR #3854也未被允许4EnvTest 二进制不也是构建/推广第三方制品吗是但它同样需要改变controller-runtime 维护者将改为在自己项目内构建对社区透明5能否直接用 controller-runtime 的 HTTPS 安全指标服务特性可以但需先对齐最佳实践见 issue #2781 的跟踪6能否强制要求 cert-manager不能作为默认强制项违背新手友好目标但对 Webhook、kube-rbac-proxy 等特定高级功能可做要求风险与缓解已推广镜像的丢失风险迁移到 Kubernetes SIG 共享基础设施后Kubebuilder 无法再像以前一样自动构建和推广镜像——该流程仅对 umbrella 内项目生效。缓解措施包括k8s-infra 维护者可作为应急方案手动将镜像迁移到新的registry.k8s.io仍想使用 kube-rbac-proxy 的用户最佳路径是切换到由项目自身维护在quay.ioquay.io/repository/brancz/kube-rbac-proxy的镜像继续使用 kube-rbac-proxy 需要用户更新项目、发布新版本并确保config/default/manager_auth_proxy_patch.yaml中的镜像引用指向新位置。必须明确保证这些镜像在任何基础设施下持续被推广对 Kubebuilder 维护者而言绝对超出我们的控制范围并不可靠。Google Cloud Platform 项目的影响截至目前 Kubebuilder 尚未收到其 GCP 项目被关停的官方通知但由于 GCR 弃用用户从2025 年初起将无法从原位置消费这些镜像。项目将通过与社区开放沟通、通过邮件列表等渠道广泛通知推动尽早脱离对相关镜像的依赖。备选方案评估方案 A仅把镜像从gcr.io换成registry.k8s.io由 k8s-infra 维护者手动将镜像加入gcr.io/k8s-staging-kubebuilder/kube-rbac-proxy并推广到registry.k8s.io/kubebuilder/kube-rbac-proxy同时a) 引导用户把镜像仓库从gcr.io/k8s-staging-kubebuilder/kube-rbac-proxy改为registry.k8s.io/kubebuilder/kube-rbac-proxyb) 在文档、脚手架与所有渠道含邮件中明确声明kube-rbac-proxy 正在成为 Kubernetes/auth-sig 的一部分但尚未完成因此是不受支持/不安全的方案。缺点Kubebuilder 仍不符合自身目标脚手架第三方集成而非推广外部插件 API仍在推广 auth-sig 评审认为不够安全/可靠的方案仍需手动请求 k8s-infra 维护者构建与推广镜像用户需要改动所有已支持的项目并保证旧版本不被继续使用且将来 kube-rbac-proxy 被 umbrella 接受后路径还会再次变更Kubebuilder 无法确保镜像长期可用。方案 B保留 kube-rbac-proxy 为 opt-in并下沉为 alpha 插件该方案将 kube-rbac-proxy 移出默认脚手架作为可选插件供用户集成同时清晰沟通其使用影响。缺点基本继承方案 A 的全部缺点区别在于明确声明 Kubebuilder 无法管理这些镜像并把当前实现移入 alpha 插件可能让后续从 Kubebuilder 仓库迁往 kube-rbac-proxy 仓库的过程更顺畅。但这对用户和 Kubebuilder 维护者而言都是双倍的工作量——需要为达成最终目标处理两轮破坏性变更。因此更合理的做法是一次到位直接鼓励使用外部插件 API让 kube-rbac-proxy 在自己仓库中集成一次而不要设置这些中间步骤。总结与迁移建议决策结论从 Kubebuilder3.15.0起默认脚手架不再包含 kube-rbac-proxy。具体建议如下已有用户切换至项目托管于 quay.io 的镜像或按照更新的脚手架指南改用 NetworkPolicy项目更新可人工审查脚手架变更或使用项目提供的升级辅助工具rescaffold 相关说明见 docs/book/src/reference版本发布相关沟通与使用指南将随 release 一同发布。对正在维护 Kubebuilder 项目的开发者本设计文档给出了清晰的迁移路径默认接受 NetworkPolicy 方案在config/default/kustomization.yaml取消#- ../network-policy注释需要 HTTPS 指标时按 阶段二 启用 cert-manager 与对应 patch期望更高安全级别时跟踪 controller-runtime 的指标安全特性演进而 kube-rbac-proxy 的回归将以外部插件形态出现等待其进入 Kubernetes umbrella。该提案的价值在于既回应了社区对减少第三方依赖、增强可维护性的长期诉求又通过分阶段设计保证了向后兼容与用户自由度——这正是 设计文档 中开放问题 四阶段 备选方案结构所呈现的完整决策逻辑。赞分享开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载相关推荐XTTS-v2自定义训练如何用自有数据集微调语音克隆模型XTTS v2自定义训练如何用自有数据集微调语音克隆模型 XTTS v2是一款强大的语音生成模型支持仅用6秒音频片段就能将声音克隆到不同语言无需大量训练数Kubebuilder 安全实践完整指南Webhook TLS证书、Metrics端点认证与NetworkPolicy防护Kubebuilder 安全实践完整指南Webhook TLS证书、Metrics端点认证与NetworkPolicy防护 Kubebuilder 是构建 K开发者工具代码生成CLI云原生后端Vector kubernetes_logs 迁移至 kube-rsKubernetes API 集成重构与 RBAC 变更Vector kubernetes_logs 迁移至 kube rsKubernetes API 集成重构与 RBAC 变更 本篇技术文章解析 VectorDevOpsCI/CD基础设施上一篇基于 Freedom E RISC-V SDK 的 HiFive1 开发环境搭建与基准测试指南RT-Thread 集成实践下一篇如何用Arnis将现实城市一键转化为Minecraft世界完整开源指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubebuilder 移除 kube-rbac-proxy：以 NetworkPolicy 与 cert-manager 重构指标端点安全架构
开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载Kubebuilder 在 3.15.0 版本起不再在新脚手架的默认配置中引入 kube-rbac-proxy转而采用 Kubernetes 原生 NetworkPolicy、可选的 cert-manager 以及 controller-runtime 的指标安全特性来保护 /metrics 端点。本文基于仓库中的设计文档 designs/discontinue_usage_of_kube_rbac_proxy.md梳理该决策的动机、四阶段落地计划、风险与替代方案并结合仓库内脚手架 testdatatestdata/project-v4展示升级后的真实清单配置帮助读者理解如何迁移既有项目、如何按需启用 HTTPS 指标服务。背景为什么要弃用 kube-rbac-proxykube-rbac-proxy 是业界常用的边车sidecar代理曾长期作为 Kubebuilder 默认脚手架中保护/metrics端点的手段。然而随着 Kubernetes 基础设施生态的演进Kubebuilder 维护者重新评估了这一默认依赖核心考量如下共享基础设施迁移Kubernetes SIG 项目要求所有镜像发布到registry.k8s.io而该发布流程只对 Kubernetes umbrella 内的项目生效Google Container RegistryGCR停服Google Cloud Platform 官方宣布弃用 Container Registry意味着 Kubebuilder 此前发布在gcr.io/kubebuilder/kube-rbac-proxy的镜像在2025 年 4 月 22 日起将不可再被获取未纳入 Kubernetes umbrellakube-rbac-proxy 尚未正式进入 Kubernetes Auth SIG 的官方支持范围Kubernetes Auth SIG 的评审显示其仍需大量改动才能获得官方背书维护权不在自身Kubebuilder 维护者无法持续、可靠地为第三方项目构建和推送镜像这违背了项目可被维护者持续支撑的目标。其中最关键的一点是依赖一个可能随时被停用的 Google 基础设施且这种停用不在我们控制范围内这对项目可靠性和镜像可用性构成了直接风险。社区对此也有明确诉求见 issue #3482社区成员希望将其从默认脚手架移除与 #3230镜像可用性风险。目标与非目标界定改造边界目标最大化指标端点保护不新增第三方依赖在不需要构建、推送第三方镜像的前提下提供尽可能高的保护等级避免破坏性变更用旧版本生成项目的用户仍可使用新版本脚手架并可按自己的节奏迁移可持续维护所有由 Kubebuilder 脚手架生成的项目都应由其维护者可持续地支撑摆脱 Google Cloud Platform 依赖考虑到 GCP 可能单方面关停服务主动迁移符合 Kubernetes umbrella 规范不再推广或背书尚未被 Kubernetes umbrella 组织认可、且随工作负载一起交付的方案推广外部插件 API遵循 Kubebuilder 通过外部插件external plugins支持第三方集成的指导方针让第三方项目维护者自己维护与脚手架集成的实现网络策略使用可灵活开关允许用户选择不使用 NetworkPolicy例如打算使用不支持的 CNI 或供应商方案时。非目标需要明确的是本提案不以复刻 kube-rbac-proxy 的功能或同等保护级别为目标。NetworkPolicy 与 kube-rbac-proxy 的工作方式不同——前者是基于 IP 地址/端口层级的简单防火墙不直接提供 authn/authz 与加密能力。因此仅靠 NetworkPolicy 无法达到与 kube-rbac-proxy 完全一致的保护水平。不过通过组合 NetworkPolicy、cert-manager 以及 controller-runtime 引入的新特性PR #2407可以从整体上回应 kube-rbac-proxy 所处理的主要安全关切。四阶段落地计划提案将整个迁移拆解为四个阶段每阶段都必须伴随对应的文档更新文档更新要求确保最终用户理解如何启用、配置和使用这些选项。阶段一过渡到 NetworkPolicy默认行为这是本提案的立即行动用 Kubernetes 原生 NetworkPolicy 替换 kube-rbac-proxy。从release 3.15.0开始Kubebuilder 不再为新项目脚手架 kube-rbac-proxy默认启用 NetworkPolicy 保护。仓库 testdata 中已经固化了这一脚手架形态见 testdata/project-v4/config/network-policyallow-metrics-traffic.yaml仅允许来自带有metrics: enabled标签的命名空间中的 Pod 访问 8443 端口即指标端口把抓取指标的行为显式限定在已打标签的命名空间内apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: project-v4 app.kubernetes.io/managed-by: kustomize name: allow-metrics-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager app.kubernetes.io/name: project-v4 policyTypes: - Ingress ingress: # Allow pods in namespaces labeled metrics: enabled to scrape metrics. - from: - namespaceSelector: matchLabels: metrics: enabled # Only from namespaces with this label ports: - port: 8443 protocol: TCPallow-webhook-traffic.yaml允许所有来源访问 Webhook 的 9443 Pod 端口Kubernetes API server 需要通过 Service 访问准入与 CRD 转换 WebhookapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: project-v4 app.kubernetes.io/managed-by: kustomize name: allow-webhook-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager app.kubernetes.io/name: project-v4 policyTypes: - Ingress ingress: - ports: - port: 9443 protocol: TCPkustomization.yaml将以上两个资源聚合为一个可被 kustomize 引用的组件。在项目根配置 testdata/project-v4/config/default/kustomization.yaml 中network-policy 默认处于注释状态用户按需取消注释即可启用# [NETWORK POLICY] Control ingress to metrics and webhook ports.下的#- ../network-policy由于它是默认脚手架的一部分新项目可通过取消注释直接开启。这一设计同时满足了默认启用体现在脚手架上与用户可自由 opt-out通过注释两个要求——例如当用户使用不支持 NetworkPolicy 的 CNI 时可以整体跳过该组件。开放问题 1 的回应NetworkPolicy 虽然属于 Kubernetes 核心 API但其强制执行依赖集群安装的 CNI 插件。主流 CNICalico、Cilium、WeaveNet、Canal均支持 NetworkPolicyAWS 此前不支持但 Amazon VPC CNI 已宣布支持 Kubernetes Network Policies。此外在该提案下用户仍可按需启用/禁用该选项。阶段二将 cert-manager 作为指标的可选选项在第一阶段落地对应开源 PR #3853之后提案设想引入 cert-manager 做 TLS 证书管理并与 controller-runtime 的新特性PR #2407形成协同为指标端点带来加密通信乃至基于 mTLS 的认证能力显著提升脚手架项目的安全模型。cert-manager自动化 TLS 证书的签发与管理配置 mTLS 时还能增加一层认证。目前 Kubebuilder 在脚手架 Webhook 时已使用 cert-manager提案的思路是让用户能像 Webhook 一样为指标启用 cert-manager必须保持可选Kubebuilder 的目标之一是降低新用户门槛因此默认脚手架与快速开始流程不应强制用户安装 cert-manager只有在启用 Webhook、启用指标 HTTPS 等特定功能时才建议使用。实现方式是在config/default/kustomization.yaml中引入一个可配置的 Kustomize patch用于同时 patchconfig/prometheus/monitor.yaml中的 ServiceMonitor 与证书类似现有 Webhook 的做法现有 Webhook 场景下config/default/kustomization.yaml已通过 replacements 注入 cert-manager CA 注入注解覆盖 ValidatingWebhookConfiguration、MutatingWebhookConfiguration 与 CRD。提案设计了一个名为metrics_https_patch.yaml的 patch 文件启用方式为# [METRICS WITH HTTPS] To enable the ServiceMonitor using HTTPS, uncomment the following line # Note that for this to work, you also need to ensure that cert-manager is enabled in your project - path: metrics_https_patch.yaml启用 cert-manager 后的 ServiceMonitor 示例如下这是提案给出的目标形态强调生产环境不应跳过 TLS 校验# Prometheus Monitor Service (Metrics) with cert-manager apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: control-plane: controller-manager app.kubernetes.io/name: project-v4 app.kubernetes.io/managed-by: kustomize name: controller-manager-metrics-monitor namespace: system annotations: cert-manager.io/inject-ca-from: $(NAMESPACE)/controller-manager-certificate spec: endpoints: - path: /metrics port: https scheme: https bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token tlsConfig: # We should recommend ensure that TLS verification is not skipped in production insecureSkipVerify: false caFile: /etc/prometheus/secrets/ca.crt # CA certificate injected by cert-manager certFile: /etc/prometheus/secrets/tls.crt # TLS certificate injected by cert-manager keyFile: /etc/prometheus/secrets/tls.key # TLS private key injected by cert-manager selector: matchLabels: control-plane: controller-manager仓库中已固化的可对照实现虽然metrics_https_patch.yaml本身是提案中的规划产物但仓库 testdata 已经实现了与之同构的cert-manager 保护指标配置可作为落地参考cert_metrics_manager_patch.yaml通过 Kustomize 为 manager Deployment 添加volumeMounts、--metrics-cert-path/tmp/k8s-metrics-server/metrics-certs参数并挂载来自metrics-server-certSecret 的ca.crt、tls.crt、tls.keycertificate-metrics.yaml定义一个由selfsigned-issuer签发的metrics-certsCertificatednsNames由config/default/kustomization.yaml中的 replacements 注入SERVICE_NAME.SERVICE_NAMESPACE.svc(.cluster.local)monitor_tls_patch.yaml将 ServiceMonitor 的tlsConfig替换为从metrics-server-certSecret 读取ca、cert与keySecret并把insecureSkipVerify置为false未使用 cert-manager 时脚手架默认的 monitor.yaml 使用insecureSkipVerify: true并注释明确提示生产环境不推荐该配置、建议启用 cert-manager。启用上述 HTTPS 指标链路的入口同样是 config/default/kustomization.yaml 中注释掉的cert_metrics_manager_patch.yaml与[METRICS-WITH-CERTS]段以及默认启用的manager_metrics_patch.yaml通过--metrics-bind-address:8443让 manager 以 HTTPS 暴露指标。指标 Service 定义见 metrics_service.yaml其https端口为 8443。开放问题 2 与 6 的回应NetworkPolicy 确实不提供 authn/authz 与加密但结合 cert-manager 与 controller-runtime 新特性可以达到同等甚至更高的保护水平且无第三方依赖同时 cert-manager 不能被默认强制启用——Kubebuilder 的目标是让新用户快速上手但可以对 Webhook、指标 HTTPS 等特定高级功能做强制要求。阶段三利用增强后的 controller-runtime 特性controller-runtime 的 issue #2781 跟踪了指标端点安全配置对齐最佳实践的诉求。在该问题得到解决后提案计划直接用 controller-runtime 的能力保护指标端点同时处理authn认证与 authz授权。实现示例参考了 cluster-api 项目的util/flags/diagnostics.go。将来启用该能力时main.go中 manager 的构造将形如ctrlOptions : ctrl.Options{ MetricsFilterProvider: filters.WithAuthenticationAndAuthorization, MetricsSecureServing: true, }开放问题 5 的回应是的可以在修复若干问题后使用 controller-runtime 的 HTTPS 安全指标服务特性——但该配置需要与最佳实践对齐这正是 issue #2781 的跟踪目标。开放问题 3 与 4 的回应Kubebuilder 曾尝试借助共享基础设施继续构建并推送镜像test-infra 中有对应 recipe但 kube-rbac-proxy 不在 Kubernetes umbrella 下而无法生效也实验过用 GitHub 仓库作为替代PR #3854但似乎不被允许。而 EnvTest 使用的二进制同样面临此问题controller-runtime 维护者已计划在自己项目内构建这些二进制该变更对社区用户大概率是透明的——这进一步印证了Kubebuilder 不应负责维护和推广第三方制品的立场。阶段四kube-rbac-proxy 进入 umbrella 后以外部插件回归一旦 kube-rbac-proxy 被纳入 Kubernetes umbrella可跟踪 brancz/kube-rbac-proxy#238 与 创建插件将其集成用户即可按需选择kubebuilder init|edit --pluginskube-rbac-proxy/v1该插件可复用 pkg/plugin/util 提供的代码操作工具——例如 util.go 中的UncommentCode搜索目标内容并移除注释前缀用于打开config/default/kustomization中被注释的 patch、启用 NetworkPolicy 的默认禁用以及 util.go 中的ReplaceInFile替换文件中全部匹配内容用于把main.go中的指标安全配置替换为 controller-runtime 原生特性。这一方案让 kube-rbac-proxy 以用户自行 opt-in的方式融入脚手架符合 Kubebuilder 通过插件 API 支持第三方集成的方针——第三方项目维护者最熟悉自己的方案由其维护集成实现最有利于用户体验。开放问题与官方回应#问题官方回应要点1NetworkPolicy 由集群 CNI 实现主流 CNI 是否支持虽然依赖 CNI 插件但 Calico、Cilium、WeaveNet、Canal 均支持AWS 的 Amazon VPC CNI 现已支持 NetworkPolicy用户仍可自行启用/禁用2NetworkPolicy 只是简单防火墙不提供 authn/authz 与加密正确但结合 cert-manager 与 controller-runtime 新特性可获得同等或更优保护且不引入额外第三方依赖3能否用共享基础设施继续构建/推广这些镜像试过 test-infra recipe但因 kube-rbac-proxy 不在 umbrella 下不生效GitHub 仓库方案PR #3854也未被允许4EnvTest 二进制不也是构建/推广第三方制品吗是但它同样需要改变controller-runtime 维护者将改为在自己项目内构建对社区透明5能否直接用 controller-runtime 的 HTTPS 安全指标服务特性可以但需先对齐最佳实践见 issue #2781 的跟踪6能否强制要求 cert-manager不能作为默认强制项违背新手友好目标但对 Webhook、kube-rbac-proxy 等特定高级功能可做要求风险与缓解已推广镜像的丢失风险迁移到 Kubernetes SIG 共享基础设施后Kubebuilder 无法再像以前一样自动构建和推广镜像——该流程仅对 umbrella 内项目生效。缓解措施包括k8s-infra 维护者可作为应急方案手动将镜像迁移到新的registry.k8s.io仍想使用 kube-rbac-proxy 的用户最佳路径是切换到由项目自身维护在quay.ioquay.io/repository/brancz/kube-rbac-proxy的镜像继续使用 kube-rbac-proxy 需要用户更新项目、发布新版本并确保config/default/manager_auth_proxy_patch.yaml中的镜像引用指向新位置。必须明确保证这些镜像在任何基础设施下持续被推广对 Kubebuilder 维护者而言绝对超出我们的控制范围并不可靠。Google Cloud Platform 项目的影响截至目前 Kubebuilder 尚未收到其 GCP 项目被关停的官方通知但由于 GCR 弃用用户从2025 年初起将无法从原位置消费这些镜像。项目将通过与社区开放沟通、通过邮件列表等渠道广泛通知推动尽早脱离对相关镜像的依赖。备选方案评估方案 A仅把镜像从gcr.io换成registry.k8s.io由 k8s-infra 维护者手动将镜像加入gcr.io/k8s-staging-kubebuilder/kube-rbac-proxy并推广到registry.k8s.io/kubebuilder/kube-rbac-proxy同时a) 引导用户把镜像仓库从gcr.io/k8s-staging-kubebuilder/kube-rbac-proxy改为registry.k8s.io/kubebuilder/kube-rbac-proxyb) 在文档、脚手架与所有渠道含邮件中明确声明kube-rbac-proxy 正在成为 Kubernetes/auth-sig 的一部分但尚未完成因此是不受支持/不安全的方案。缺点Kubebuilder 仍不符合自身目标脚手架第三方集成而非推广外部插件 API仍在推广 auth-sig 评审认为不够安全/可靠的方案仍需手动请求 k8s-infra 维护者构建与推广镜像用户需要改动所有已支持的项目并保证旧版本不被继续使用且将来 kube-rbac-proxy 被 umbrella 接受后路径还会再次变更Kubebuilder 无法确保镜像长期可用。方案 B保留 kube-rbac-proxy 为 opt-in并下沉为 alpha 插件该方案将 kube-rbac-proxy 移出默认脚手架作为可选插件供用户集成同时清晰沟通其使用影响。缺点基本继承方案 A 的全部缺点区别在于明确声明 Kubebuilder 无法管理这些镜像并把当前实现移入 alpha 插件可能让后续从 Kubebuilder 仓库迁往 kube-rbac-proxy 仓库的过程更顺畅。但这对用户和 Kubebuilder 维护者而言都是双倍的工作量——需要为达成最终目标处理两轮破坏性变更。因此更合理的做法是一次到位直接鼓励使用外部插件 API让 kube-rbac-proxy 在自己仓库中集成一次而不要设置这些中间步骤。总结与迁移建议决策结论从 Kubebuilder3.15.0起默认脚手架不再包含 kube-rbac-proxy。具体建议如下已有用户切换至项目托管于 quay.io 的镜像或按照更新的脚手架指南改用 NetworkPolicy项目更新可人工审查脚手架变更或使用项目提供的升级辅助工具rescaffold 相关说明见 docs/book/src/reference版本发布相关沟通与使用指南将随 release 一同发布。对正在维护 Kubebuilder 项目的开发者本设计文档给出了清晰的迁移路径默认接受 NetworkPolicy 方案在config/default/kustomization.yaml取消#- ../network-policy注释需要 HTTPS 指标时按 阶段二 启用 cert-manager 与对应 patch期望更高安全级别时跟踪 controller-runtime 的指标安全特性演进而 kube-rbac-proxy 的回归将以外部插件形态出现等待其进入 Kubernetes umbrella。该提案的价值在于既回应了社区对减少第三方依赖、增强可维护性的长期诉求又通过分阶段设计保证了向后兼容与用户自由度——这正是 设计文档 中开放问题 四阶段 备选方案结构所呈现的完整决策逻辑。赞分享开发者工具代码生成CLI云原生后端【免费下载链接】kubebuilderKubebuilder - SDK for building Kubernetes APIs using CRDs项目地址https://gitcode.com/gh_mirrors/ku/kubebuilder点击查看免费下载相关推荐XTTS-v2自定义训练如何用自有数据集微调语音克隆模型XTTS v2自定义训练如何用自有数据集微调语音克隆模型 XTTS v2是一款强大的语音生成模型支持仅用6秒音频片段就能将声音克隆到不同语言无需大量训练数Kubebuilder 安全实践完整指南Webhook TLS证书、Metrics端点认证与NetworkPolicy防护Kubebuilder 安全实践完整指南Webhook TLS证书、Metrics端点认证与NetworkPolicy防护 Kubebuilder 是构建 K开发者工具代码生成CLI云原生后端Vector kubernetes_logs 迁移至 kube-rsKubernetes API 集成重构与 RBAC 变更Vector kubernetes_logs 迁移至 kube rsKubernetes API 集成重构与 RBAC 变更 本篇技术文章解析 VectorDevOpsCI/CD基础设施上一篇基于 Freedom E RISC-V SDK 的 HiFive1 开发环境搭建与基准测试指南RT-Thread 集成实践下一篇如何用Arnis将现实城市一键转化为Minecraft世界完整开源指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考