云原生后端开发工具微服务【免费下载链接】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 官方升级文档 v1.39.0.md系统梳理从 v1.38.0 升级到 v1.39.0 的全部迁移步骤。该版本的核心变化是将项目依赖推进到 Kubernetes 1.31 API并引入 Kubebuilder v4.2.0 脚手架中的 NetworkPolicy网络策略安全加固能力。读完本文后你将能够独立完成 Gogo/v4、Helmhelm/v1、Ansibleansible/v1三类 Operator 工程的依赖升级、Makefile 与工具链更新以及/metrics端点与 Webhook Server 的 NetworkPolicy 安全防护配置。一、版本升级总览改了什么动了哪些文件与 v1.38.0 相比v1.39.0 的迁移量明显更小主要围绕以下文件展开受影响文件涉及的插件类型变更内容Makefilehelm/v1、ansible/v1kustomize 下载版本 v5.3.2 → v5.4.3go.modgo/v4ginkgo、gomega、k8s.io/*、controller-runtime 全面升级到 K8s 1.31 / controller-runtime v0.19.0Makefilego/v4ENVTEST_K8S_VERSION1.31.0、KUSTOMIZE_VERSIONv5.4.3、CONTROLLER_TOOLS_VERSIONv0.16.1、ENVTEST_VERSIONrelease-0.19cmd/main.gogo/v4更新 metrics server 相关注释中的 controller-runtime 版本链接config/default/kustomization.yamlgo/v4、helm/v1、ansible/v1新增[NETWORK POLICY]注释块默认注释按需启用config/network-policy/allow-metrics-traffic.yamlgo/v4、helm/v1、ansible/v1新增保护 /metrics 端点config/network-policy/allow-webhook-traffic.yamlgo/v4新增保护 Webhook Serverconfig/network-policy/kustomization.yamlgo/v4、helm/v1、ansible/v1新增聚合上述策略资源仓库 changelog 对本次发布的官方描述为Go、Helm、Ansible 三类 Operator 均迁移到 Kubernetes 1.31 API 与 Kubebuilder v4 脚手架v4.2.0并新增网络策略保护能力见 changelog/generated/v1.39.0.md。二、第一步helm/v1、ansible/v1更新 Makefile 中的 kustomize 版本Helm 与 Ansible 类 Operator 的脚手架通过 curl 直接下载 kustomize 二进制升级时需要同步替换下载地址中的版本号- curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.2/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \ curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.4.3/kustomize_v5.4.2_$(OS)_$(ARCH).tar.gz | \注意这里的两处细节URL 路径中的目录名是kustomize/v5.4.3而压缩包文件名是kustomize_v5.4.2_$(OS)_$(ARCH).tar.gz两者版本号不一致是正常的请按原文档 diff 精确替换不要顺手统一。升级后建议执行make kustomize重新拉取本地二进制确认bin/kustomize已指向新版本。作为对照仓库当前示例工程 testdata/helm/memcached-operator/Makefile 中 kustomize 的下载逻辑已经进一步演进下载kustomize/v5.6.0/kustomize_v5.6.0_$(OS)_$(ARCH).tar.gz说明该逻辑自 v1.39.0 之后持续由脚手架版本驱动升级时以你实际工程中的脚手架子版本为准。三、第二步go/v4升级 go.mod 依赖并执行 go mod tidyGo 类 Operator 需要将核心依赖整体升级到 Kubernetes 1.31 对应的版本线- github.com/onsi/ginkgo/v2 v2.17.1 - github.com/onsi/gomega v1.32.0 - k8s.io/api v0.30.1 - k8s.io/apimachinery v0.30.1 - k8s.io/client-go v0.30.1 - sigs.k8s.io/controller-runtime v0.18.4 github.com/onsi/ginkgo/v2 v2.19.0 github.com/onsi/gomega v1.33.1 k8s.io/api v0.31.0 k8s.io/apimachinery v0.31.0 k8s.io/client-go v0.31.0 sigs.k8s.io/controller-runtime v0.19.0修改完成后必须运行go mod tidygo mod tidy会根据升级后的依赖图重新解析并补全go.sum同时清理不再需要的间接依赖。如果项目后续还要生成 bundle建议一并重新生成相关清单文件避免旧版本依赖残留在产物中。四、第三步go/v4同步 Makefile 中的工具链版本Go 类工程的 Makefile 中有四处版本变量需要同步更新- ENVTEST_K8S_VERSION 1.30.0 ENVTEST_K8S_VERSION 1.31.0- KUSTOMIZE_VERSION ? v5.4.2 - CONTROLLER_TOOLS_VERSION ? v0.15.0 - ENVTEST_VERSION ? release-0.18 KUSTOMIZE_VERSION ? v5.4.3 CONTROLLER_TOOLS_VERSION ? v0.16.1 ENVTEST_VERSION ? release-0.19各变量的作用与配套关系如下ENVTEST_K8S_VERSIONsetup-envtest拉取的 etcd / kube-apiserver 二进制对应 Kubernetes 版本必须与k8s.io/api升级后的版本一致1.31否则make test时KUBEBUILDER_ASSETS指向的二进制版本可能与 API 版本不匹配。KUSTOMIZE_VERSIONkustomize 工具版本需与config/default/kustomization.yaml中的网络策略等新语法兼容。CONTROLLER_TOOLS_VERSIONcontroller-gen 版本升级到 v0.16.1 以正确解析 controller-runtime v0.19.0 新增的 API。ENVTEST_VERSIONsetup-envtest自身的 release 分支版本release-0.18→release-0.19与 controller-runtime 主版本线对齐。从仓库 testdata/go/v4/memcached-operator/Makefile 可以看到较新的脚手架子版本已把ENVTEST_VERSION与ENVTEST_K8S_VERSION改为从go.mod中 controller-runtime / k8s.io/api 版本自动推导未来升级时这类手工同步的成本会进一步降低。五、第四步go/v4更新 main.go 中的 controller-runtime 文档链接注释脚手架生成的cmd/main.go中metrics server 配置处有两条指向 controller-runtime 文档的注释需要把版本号从 v0.18.4 更新到 v0.19.0- // - https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.18.4/pkg/metrics/server // - https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.19.0/pkg/metrics/server - // https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.18.4/pkg/metrics/filters#WithAuthenticationAndAuthorization // https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.19.0/pkg/metrics/filters#WithAuthenticationAndAuthorization这两条注释分别指向 metrics server 的配置选项文档与filters.WithAuthenticationAndAuthorization指标端点的认证/授权过滤器文档。仓库中的 testdata/go/v4/memcached-operator/cmd/main.go 展示了这条调用链的实际形态metricsserver.Options的SecureServing开启时FilterProvider被设置为filters.WithAuthenticationAndAuthorization从而确保只有通过 RBAC 授权的用户与服务账户能访问指标端点。六、第五步所有插件类型在 config/default/kustomization.yaml 中登记 NetworkPolicy对 go/v4、helm/v1、ansible/v1 三类工程都需要在config/default/kustomization.yaml的resources区新增如下注释块默认保持注释状态按需启用 # [NETWORK POLICY] Protect the /metrics endpoint and Webhook Server with NetworkPolicy. # Only Pod(s) running a namespace labeled with metrics: enabled will be able to gather the metrics. # Only CR(s) which requires webhooks and are applied on namespaces labeled with webhooks: enabled will # be able to communicate with the Webhook Server. #- ../network-policy仓库中的实际示例 testdata/go/v4/memcached-operator/config/default/kustomization.yaml 与该 diff 完全一致且该文件同时保留了[WEBHOOK]、[CERTMANAGER]、[PROMETHEUS]、[METRICS]等既有注释块体现了 Kubebuilder 脚手架注释即开关的约定需要启用某项能力时取消对应行的注释即可。七、第六步所有插件类型添加 allow-metrics-traffic.yaml 保护 /metrics 端点在config/network-policy/目录下新建allow-metrics-traffic.yaml # This NetworkPolicy allows ingress traffic # with Pods running on namespaces labeled with metrics: enabled. Only Pods on those # namespaces are able to gathering data from the metrics endpoint. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: operator-name app.kubernetes.io/managed-by: kustomize name: allow-metrics-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager policyTypes: - Ingress ingress: # This allows ingress traffic from any namespace with the label metrics: enabled - from: - namespaceSelector: matchLabels: metrics: enabled # Only from namespaces with this label ports: - port: 8443 protocol: TCP要点解读namespace: system策略部署在 operator 自身所在的system命名空间与config/manager中的 Namespace 命名约定一致。podSelector.matchLabels.control-plane: controller-manager选中运行中的 controller-manager Pod。从仓库 testdata/go/v4/memcached-operator/config/manager/manager.yaml 可见脚手架生成的 Namespace 与 Deployment 模板均带control-plane: controller-manager与app.kubernetes.io/name: memcached-operator标签实际工程中app.kubernetes.io/name会替换为你的 operator 名。policyTypes: [Ingress] 端口 8443metrics 端点默认通过 HTTPS 暴露在 8443 端口对应 Makefile 中manager_metrics_patch.yaml的约定。只有位于带metrics: enabled标签命名空间中的 Pod 才被允许抓取指标。仓库示例 testdata/go/v4/memcached-operator/config/network-policy/allow-metrics-traffic.yaml 与 testdata/helm/memcached-operator/config/network-policy/allow-metrics-traffic.yaml 中的实际内容与此一致差别仅在于app.kubernetes.io/name的具体取值。八、第七步helm/v1、ansible/v1添加 network-policy 的 kustomization.yamlHelm 与 Ansible 工程只需要一条 metrics 策略因此config/network-policy/kustomization.yaml内容为 resources: - allow-metrics-traffic.yaml仓库中的真实文件 testdata/helm/memcached-operator/config/network-policy/kustomization.yaml 与之完全一致。九、第八步go/v4添加 allow-webhook-traffic.yaml 保护 Webhook ServerGo 工程额外需要一条 Webhook 流量策略新建config/network-policy/allow-webhook-traffic.yaml # This NetworkPolicy allows ingress traffic to your webhook server running # as part of the controller-manager from specific namespaces and pods. CR(s) which uses webhooks # will only work when applied in namespaces labeled with webhook: enabled apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: operator-name app.kubernetes.io/managed-by: kustomize name: allow-webhook-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager policyTypes: - Ingress ingress: # This allows ingress traffic from any namespace with the label webhook: enabled - from: - namespaceSelector: matchLabels: webhook: enabled # Only from namespaces with this label ports: - port: 443 protocol: TCP要点解读端口 443Webhook Server 通过 443 端口提供 HTTPS 服务对应manager_webhook_patch.yaml与 webhook service 的端口约定。命名空间标签webhook: enabled使用了 Webhook 的 CR 只有在带此标签的命名空间中应用才会生效这从网络层限制了哪些命名空间能与 Webhook Server 通信。仓库真实示例见 testdata/go/v4/memcached-operator/config/network-policy/allow-webhook-traffic.yaml。十、第九步go/v4聚合两条策略的 kustomization.yamlGo 工程的config/network-policy/kustomization.yaml需要同时包含两条策略 resources: - allow-webhook-traffic.yaml - allow-metrics-traffic.yaml仓库中的实际文件 testdata/go/v4/memcached-operator/config/network-policy/kustomization.yaml 与此完全一致。十一、启用与验证 NetworkPolicy完成上述文件添加后若希望真正启用网络策略保护还需两步取消config/default/kustomization.yaml中#- ../network-policy的注释让 kustomize 把config/network-policy下的策略合并进config/default的渲染结果。为相关命名空间打标签给需要抓取指标或使用 Webhook 的命名空间分别打上metrics: enabled与webhook: enabled标签否则流量会被策略默认拒绝。验证方式# 渲染完整清单确认 NetworkPolicy 资源已包含在内 kustomize build config/default | grep -A 20 kind: NetworkPolicy # 部署后确认策略生效 kubectl get networkpolicies -n operator-system由于 Go 工程实际部署时会先执行cd config/manager $(KUSTOMIZE) edit set image controller${IMG}再kustomize build config/default见 testdata/go/v4/memcached-operator/Makefilemake deploy或make build-installer后策略即随整体清单一起下发。十二、常见问题与注意事项URL 与文件名版本不一致kustomize 下载 URL 的目录版本v5.4.3与压缩包文件名版本v5.4.2不同是官方发布命名的正常现象严格照 diff 执行即可。ENVTEST_K8S_VERSION 与 API 版本必须对齐1.31.0 是make test能否通过的关键升级k8s.io/api后务必同步该变量。NetworkPolicy 默认关闭脚手架将其作为可选加固项未启用../network-policy前不影响原有功能启用后必须保证监控组件所在命名空间带metrics: enabled标签否则指标抓取会失败。app.kubernetes.io/name占位符策略清单中的operator-name需要替换为你的实际 operator 名与config/manager/manager.yaml中的 Deployment 标签保持一致否则podSelector无法命中 Pod。后续版本参考本升级与 Kubebuilder 上游 PRprotect project with network policies一脉相承更多演进细节可对照仓库更新至 v1.39.1、v1.39.2 及 v1.40.0 的升级文档见 website/content/en/docs/upgrading-sdk-version 目录下的对应文件。结语v1.39.0 的升级核心是依赖版本线整体跃迁到 Kubernetes 1.31 controller-runtime v0.19.0以及引入 NetworkPolicy 脚手架为 /metrics 与 Webhook 端点提供命名空间级的网络隔离。按照本文九个步骤依次执行即可完成 go/v4、helm/v1、ansible/v1 三类工程的安全平滑升级。赞分享云原生后端开发工具微服务【免费下载链接】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 v1.39.0 升级指南Kubernetes 1.31 API 迁移与 Kubebuilder v4 NetworkPolicy 脚手架operator sdk v1.39.0 升级指南Kubernetes 1.31 API 迁移与 Kubebuilder v4 NetworkPolicy 脚云原生后端开发工具微服务Operator SDK v1.38.0 升级指南迁移 Kubernetes 1.30 与 Kubebuilder v4重构 Metrics 端点安全Operator SDK v1.38.0 升级指南迁移 Kubernetes 1.30 与 Kubebuilder v4重构 Metrics 端点安全 Op云原生后端开发工具微服务operator-sdk alpha generate 详解使用 Kubebuilder 重新脚手架已有 Operator 项目operator sdk alpha generate 详解使用 Kubebuilder 重新脚手架已有 Operator 项目 本文是 operator s云原生后端开发工具微服务上一篇Pixelorama终极指南从零开始掌握开源像素艺术创作神器下一篇3分钟免费激活Windows和OfficeKMS智能激活脚本终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
云原生后端开发工具微服务【免费下载链接】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 官方升级文档 v1.39.0.md系统梳理从 v1.38.0 升级到 v1.39.0 的全部迁移步骤。该版本的核心变化是将项目依赖推进到 Kubernetes 1.31 API并引入 Kubebuilder v4.2.0 脚手架中的 NetworkPolicy网络策略安全加固能力。读完本文后你将能够独立完成 Gogo/v4、Helmhelm/v1、Ansibleansible/v1三类 Operator 工程的依赖升级、Makefile 与工具链更新以及/metrics端点与 Webhook Server 的 NetworkPolicy 安全防护配置。一、版本升级总览改了什么动了哪些文件与 v1.38.0 相比v1.39.0 的迁移量明显更小主要围绕以下文件展开受影响文件涉及的插件类型变更内容Makefilehelm/v1、ansible/v1kustomize 下载版本 v5.3.2 → v5.4.3go.modgo/v4ginkgo、gomega、k8s.io/*、controller-runtime 全面升级到 K8s 1.31 / controller-runtime v0.19.0Makefilego/v4ENVTEST_K8S_VERSION1.31.0、KUSTOMIZE_VERSIONv5.4.3、CONTROLLER_TOOLS_VERSIONv0.16.1、ENVTEST_VERSIONrelease-0.19cmd/main.gogo/v4更新 metrics server 相关注释中的 controller-runtime 版本链接config/default/kustomization.yamlgo/v4、helm/v1、ansible/v1新增[NETWORK POLICY]注释块默认注释按需启用config/network-policy/allow-metrics-traffic.yamlgo/v4、helm/v1、ansible/v1新增保护 /metrics 端点config/network-policy/allow-webhook-traffic.yamlgo/v4新增保护 Webhook Serverconfig/network-policy/kustomization.yamlgo/v4、helm/v1、ansible/v1新增聚合上述策略资源仓库 changelog 对本次发布的官方描述为Go、Helm、Ansible 三类 Operator 均迁移到 Kubernetes 1.31 API 与 Kubebuilder v4 脚手架v4.2.0并新增网络策略保护能力见 changelog/generated/v1.39.0.md。二、第一步helm/v1、ansible/v1更新 Makefile 中的 kustomize 版本Helm 与 Ansible 类 Operator 的脚手架通过 curl 直接下载 kustomize 二进制升级时需要同步替换下载地址中的版本号- curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.2/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \ curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.4.3/kustomize_v5.4.2_$(OS)_$(ARCH).tar.gz | \注意这里的两处细节URL 路径中的目录名是kustomize/v5.4.3而压缩包文件名是kustomize_v5.4.2_$(OS)_$(ARCH).tar.gz两者版本号不一致是正常的请按原文档 diff 精确替换不要顺手统一。升级后建议执行make kustomize重新拉取本地二进制确认bin/kustomize已指向新版本。作为对照仓库当前示例工程 testdata/helm/memcached-operator/Makefile 中 kustomize 的下载逻辑已经进一步演进下载kustomize/v5.6.0/kustomize_v5.6.0_$(OS)_$(ARCH).tar.gz说明该逻辑自 v1.39.0 之后持续由脚手架版本驱动升级时以你实际工程中的脚手架子版本为准。三、第二步go/v4升级 go.mod 依赖并执行 go mod tidyGo 类 Operator 需要将核心依赖整体升级到 Kubernetes 1.31 对应的版本线- github.com/onsi/ginkgo/v2 v2.17.1 - github.com/onsi/gomega v1.32.0 - k8s.io/api v0.30.1 - k8s.io/apimachinery v0.30.1 - k8s.io/client-go v0.30.1 - sigs.k8s.io/controller-runtime v0.18.4 github.com/onsi/ginkgo/v2 v2.19.0 github.com/onsi/gomega v1.33.1 k8s.io/api v0.31.0 k8s.io/apimachinery v0.31.0 k8s.io/client-go v0.31.0 sigs.k8s.io/controller-runtime v0.19.0修改完成后必须运行go mod tidygo mod tidy会根据升级后的依赖图重新解析并补全go.sum同时清理不再需要的间接依赖。如果项目后续还要生成 bundle建议一并重新生成相关清单文件避免旧版本依赖残留在产物中。四、第三步go/v4同步 Makefile 中的工具链版本Go 类工程的 Makefile 中有四处版本变量需要同步更新- ENVTEST_K8S_VERSION 1.30.0 ENVTEST_K8S_VERSION 1.31.0- KUSTOMIZE_VERSION ? v5.4.2 - CONTROLLER_TOOLS_VERSION ? v0.15.0 - ENVTEST_VERSION ? release-0.18 KUSTOMIZE_VERSION ? v5.4.3 CONTROLLER_TOOLS_VERSION ? v0.16.1 ENVTEST_VERSION ? release-0.19各变量的作用与配套关系如下ENVTEST_K8S_VERSIONsetup-envtest拉取的 etcd / kube-apiserver 二进制对应 Kubernetes 版本必须与k8s.io/api升级后的版本一致1.31否则make test时KUBEBUILDER_ASSETS指向的二进制版本可能与 API 版本不匹配。KUSTOMIZE_VERSIONkustomize 工具版本需与config/default/kustomization.yaml中的网络策略等新语法兼容。CONTROLLER_TOOLS_VERSIONcontroller-gen 版本升级到 v0.16.1 以正确解析 controller-runtime v0.19.0 新增的 API。ENVTEST_VERSIONsetup-envtest自身的 release 分支版本release-0.18→release-0.19与 controller-runtime 主版本线对齐。从仓库 testdata/go/v4/memcached-operator/Makefile 可以看到较新的脚手架子版本已把ENVTEST_VERSION与ENVTEST_K8S_VERSION改为从go.mod中 controller-runtime / k8s.io/api 版本自动推导未来升级时这类手工同步的成本会进一步降低。五、第四步go/v4更新 main.go 中的 controller-runtime 文档链接注释脚手架生成的cmd/main.go中metrics server 配置处有两条指向 controller-runtime 文档的注释需要把版本号从 v0.18.4 更新到 v0.19.0- // - https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.18.4/pkg/metrics/server // - https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.19.0/pkg/metrics/server - // https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.18.4/pkg/metrics/filters#WithAuthenticationAndAuthorization // https://pkg.go.dev/sigs.k8s.io/controller-runtimev0.19.0/pkg/metrics/filters#WithAuthenticationAndAuthorization这两条注释分别指向 metrics server 的配置选项文档与filters.WithAuthenticationAndAuthorization指标端点的认证/授权过滤器文档。仓库中的 testdata/go/v4/memcached-operator/cmd/main.go 展示了这条调用链的实际形态metricsserver.Options的SecureServing开启时FilterProvider被设置为filters.WithAuthenticationAndAuthorization从而确保只有通过 RBAC 授权的用户与服务账户能访问指标端点。六、第五步所有插件类型在 config/default/kustomization.yaml 中登记 NetworkPolicy对 go/v4、helm/v1、ansible/v1 三类工程都需要在config/default/kustomization.yaml的resources区新增如下注释块默认保持注释状态按需启用 # [NETWORK POLICY] Protect the /metrics endpoint and Webhook Server with NetworkPolicy. # Only Pod(s) running a namespace labeled with metrics: enabled will be able to gather the metrics. # Only CR(s) which requires webhooks and are applied on namespaces labeled with webhooks: enabled will # be able to communicate with the Webhook Server. #- ../network-policy仓库中的实际示例 testdata/go/v4/memcached-operator/config/default/kustomization.yaml 与该 diff 完全一致且该文件同时保留了[WEBHOOK]、[CERTMANAGER]、[PROMETHEUS]、[METRICS]等既有注释块体现了 Kubebuilder 脚手架注释即开关的约定需要启用某项能力时取消对应行的注释即可。七、第六步所有插件类型添加 allow-metrics-traffic.yaml 保护 /metrics 端点在config/network-policy/目录下新建allow-metrics-traffic.yaml # This NetworkPolicy allows ingress traffic # with Pods running on namespaces labeled with metrics: enabled. Only Pods on those # namespaces are able to gathering data from the metrics endpoint. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: operator-name app.kubernetes.io/managed-by: kustomize name: allow-metrics-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager policyTypes: - Ingress ingress: # This allows ingress traffic from any namespace with the label metrics: enabled - from: - namespaceSelector: matchLabels: metrics: enabled # Only from namespaces with this label ports: - port: 8443 protocol: TCP要点解读namespace: system策略部署在 operator 自身所在的system命名空间与config/manager中的 Namespace 命名约定一致。podSelector.matchLabels.control-plane: controller-manager选中运行中的 controller-manager Pod。从仓库 testdata/go/v4/memcached-operator/config/manager/manager.yaml 可见脚手架生成的 Namespace 与 Deployment 模板均带control-plane: controller-manager与app.kubernetes.io/name: memcached-operator标签实际工程中app.kubernetes.io/name会替换为你的 operator 名。policyTypes: [Ingress] 端口 8443metrics 端点默认通过 HTTPS 暴露在 8443 端口对应 Makefile 中manager_metrics_patch.yaml的约定。只有位于带metrics: enabled标签命名空间中的 Pod 才被允许抓取指标。仓库示例 testdata/go/v4/memcached-operator/config/network-policy/allow-metrics-traffic.yaml 与 testdata/helm/memcached-operator/config/network-policy/allow-metrics-traffic.yaml 中的实际内容与此一致差别仅在于app.kubernetes.io/name的具体取值。八、第七步helm/v1、ansible/v1添加 network-policy 的 kustomization.yamlHelm 与 Ansible 工程只需要一条 metrics 策略因此config/network-policy/kustomization.yaml内容为 resources: - allow-metrics-traffic.yaml仓库中的真实文件 testdata/helm/memcached-operator/config/network-policy/kustomization.yaml 与之完全一致。九、第八步go/v4添加 allow-webhook-traffic.yaml 保护 Webhook ServerGo 工程额外需要一条 Webhook 流量策略新建config/network-policy/allow-webhook-traffic.yaml # This NetworkPolicy allows ingress traffic to your webhook server running # as part of the controller-manager from specific namespaces and pods. CR(s) which uses webhooks # will only work when applied in namespaces labeled with webhook: enabled apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/name: operator-name app.kubernetes.io/managed-by: kustomize name: allow-webhook-traffic namespace: system spec: podSelector: matchLabels: control-plane: controller-manager policyTypes: - Ingress ingress: # This allows ingress traffic from any namespace with the label webhook: enabled - from: - namespaceSelector: matchLabels: webhook: enabled # Only from namespaces with this label ports: - port: 443 protocol: TCP要点解读端口 443Webhook Server 通过 443 端口提供 HTTPS 服务对应manager_webhook_patch.yaml与 webhook service 的端口约定。命名空间标签webhook: enabled使用了 Webhook 的 CR 只有在带此标签的命名空间中应用才会生效这从网络层限制了哪些命名空间能与 Webhook Server 通信。仓库真实示例见 testdata/go/v4/memcached-operator/config/network-policy/allow-webhook-traffic.yaml。十、第九步go/v4聚合两条策略的 kustomization.yamlGo 工程的config/network-policy/kustomization.yaml需要同时包含两条策略 resources: - allow-webhook-traffic.yaml - allow-metrics-traffic.yaml仓库中的实际文件 testdata/go/v4/memcached-operator/config/network-policy/kustomization.yaml 与此完全一致。十一、启用与验证 NetworkPolicy完成上述文件添加后若希望真正启用网络策略保护还需两步取消config/default/kustomization.yaml中#- ../network-policy的注释让 kustomize 把config/network-policy下的策略合并进config/default的渲染结果。为相关命名空间打标签给需要抓取指标或使用 Webhook 的命名空间分别打上metrics: enabled与webhook: enabled标签否则流量会被策略默认拒绝。验证方式# 渲染完整清单确认 NetworkPolicy 资源已包含在内 kustomize build config/default | grep -A 20 kind: NetworkPolicy # 部署后确认策略生效 kubectl get networkpolicies -n operator-system由于 Go 工程实际部署时会先执行cd config/manager $(KUSTOMIZE) edit set image controller${IMG}再kustomize build config/default见 testdata/go/v4/memcached-operator/Makefilemake deploy或make build-installer后策略即随整体清单一起下发。十二、常见问题与注意事项URL 与文件名版本不一致kustomize 下载 URL 的目录版本v5.4.3与压缩包文件名版本v5.4.2不同是官方发布命名的正常现象严格照 diff 执行即可。ENVTEST_K8S_VERSION 与 API 版本必须对齐1.31.0 是make test能否通过的关键升级k8s.io/api后务必同步该变量。NetworkPolicy 默认关闭脚手架将其作为可选加固项未启用../network-policy前不影响原有功能启用后必须保证监控组件所在命名空间带metrics: enabled标签否则指标抓取会失败。app.kubernetes.io/name占位符策略清单中的operator-name需要替换为你的实际 operator 名与config/manager/manager.yaml中的 Deployment 标签保持一致否则podSelector无法命中 Pod。后续版本参考本升级与 Kubebuilder 上游 PRprotect project with network policies一脉相承更多演进细节可对照仓库更新至 v1.39.1、v1.39.2 及 v1.40.0 的升级文档见 website/content/en/docs/upgrading-sdk-version 目录下的对应文件。结语v1.39.0 的升级核心是依赖版本线整体跃迁到 Kubernetes 1.31 controller-runtime v0.19.0以及引入 NetworkPolicy 脚手架为 /metrics 与 Webhook 端点提供命名空间级的网络隔离。按照本文九个步骤依次执行即可完成 go/v4、helm/v1、ansible/v1 三类工程的安全平滑升级。赞分享云原生后端开发工具微服务【免费下载链接】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 v1.39.0 升级指南Kubernetes 1.31 API 迁移与 Kubebuilder v4 NetworkPolicy 脚手架operator sdk v1.39.0 升级指南Kubernetes 1.31 API 迁移与 Kubebuilder v4 NetworkPolicy 脚云原生后端开发工具微服务Operator SDK v1.38.0 升级指南迁移 Kubernetes 1.30 与 Kubebuilder v4重构 Metrics 端点安全Operator SDK v1.38.0 升级指南迁移 Kubernetes 1.30 与 Kubebuilder v4重构 Metrics 端点安全 Op云原生后端开发工具微服务operator-sdk alpha generate 详解使用 Kubebuilder 重新脚手架已有 Operator 项目operator sdk alpha generate 详解使用 Kubebuilder 重新脚手架已有 Operator 项目 本文是 operator s云原生后端开发工具微服务上一篇Pixelorama终极指南从零开始掌握开源像素艺术创作神器下一篇3分钟免费激活Windows和OfficeKMS智能激活脚本终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
