理解和设定监控程序（操作员）及 CRD 的范围

本节涵盖了在 Kubebuilder 项目中操作范围和资源范围的配置。Kubernetes 中的管理器（“操作员”）可以被限定在特定的名称空间或整个集群，从而影响资源的监视和管理方式。

此外，自定义资源定义（CRDs）可以被定义为命名空间范围的或集群范围的，这会影响它们在集群中的可用性。

配置管理器范围

管理者可以根据他们需要处理的资源，在不同的范围内运作：

（默认）监视所有命名空间

默认情况下，如果未指定命名空间，管理器将观察所有命名空间。配置方式如下：

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
...
})

监视单一命名空间

要限制管理者在特定命名空间内监控资源，请设置命名空间选项：

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
...
   Cache: cache.Options{
      DefaultNamespaces: map[string]cache.Config{"operator-namespace": cache.Config{}},
   },
})

监视多个命名空间

管理员还可以通过缓存配置来配置以监视指定的命名空间集：

mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
...
Cache: cache.Options{
    DefaultNamespaces: map[string]cache.Config{
        "operator-namespace1": cache.Config{},
        "operator-namespace2": cache.Config{},
        },
    },
})

命名空间范围的 CRD（自定义资源定义）适用于当资源需要隔离到特定命名空间时。这种设置有助于管理与特定团队或应用程序相关的资源。然而，需要注意的是，由于 Kubernetes 中 CRD 的独特定义，测试 CRD 的新版本并非简单。需要实施适当的版本控制和转换策略（可参考我们的 kubebuilder 教程），并且需要调整管理哪个管理实例处理转换（有关此内容，请参阅官方 kubernetes 文档）。此外，必须考虑命名空间范围，以便在变更和验证 webhook 配置时确保它们在预期范围内正确应用。这将有助于实现更可控和分阶段的推出策略。

集群范围的 CRD（自定义资源定义）

对于需要在整个集群中可访问和可管理的资源，例如共享配置或全局资源，使用集群范围的 CRD（自定义资源定义）。

配置 CRD 作用域

当API被创建时

在生成 CRD 的清单时定义其范围。Kubebuilder 通过其 API 创建命令来简化这一过程。

默认情况下，API 的 CRD 范围是命名空间级别的。然而，对于集群范围的 API，你可以使用 --namespaced=false，即：

kubebuilder create api --group cache --version v1alpha1 --kind Memcached --resource=true --controller=true --namespaced=false

该命令生成具有集群范围的 CRD，这意味着它在集群中所有命名空间均可访问和管理。

通过更新现有的 API

在您创建API之后，仍然可以更改其范围。例如，要将CRD配置为集群范围，请在您的Go文件中API类型定义上方添加+kubebuilder:resource:scope=Cluster标记。以下是一个示例：

//+kubebuilder:object:root=true
//+kubebuilder:subresource:status
//+kubebuilder:resource:scope=Cluster,shortName=mc

...

在设置好所需的范围和标记后，运行 make manifests 以生成文件。此命令会调用 controller-gen 根据您 Go 文件中指定的标记生成 CRD 清单。

生成的清单将正确反映范围为集群或命名空间，而无需在 YAML 文件中手动调整。