配置控制器

Karmada 维护了一系列包含控制循环的控制器,它们监视系统状态,然后在需要时进行更改或请求更改。 每个控制器都尝试将当前状态转换为更接近期望状态。有关更多详细信息,请参考 Kubernetes 控制器概念

Karmada 控制器

这些控制器嵌入在 karmada-controller-managerkarmada-agent 的组件中,并且将随这些组件一起启动。 一些控制器可能由 karmada-controller-managerkarmada-agent 共享。

控制器在 karmada-controller-manager 中在 karmada-agent 中
cluster
clusterStatus
binding
bindingStatus
execution
workStatus
namespace
serviceExport
endpointSlice
serviceImport
unifiedAuth
federatedResourceQuotaSync
federatedResourceQuotaStatus
gracefulEviction
certRotation是(默认禁用)
applicationFailover
federatedHorizontalPodAutoscaler
cronFederatedHorizontalPodAutoscaler
hpaScaleTargetMarker是(默认禁用)
deploymentReplicasSyncer是(默认禁用)
multiclusterservice
endpointsliceCollect
endpointsliceDispatch
remedy
workloadRebalancer
agentcsrapproving

配置 Karmada 控制器

您可以使用 --controllers 标志为 karmada-controller-managerkarmada-agent 指定启用的控制器列表,或者在默认列表中禁用其中一些。

例如: 指定控制器列表:

  1. --controllers=cluster,clusterStatus,binding,xxx

例如:禁用某些控制器(如果要保留默认列表中的其余控制器,请记得保留 *):

  1. --controllers=-hpa,-unifiedAuth,*

使用 -foo 禁用名为 foo 的控制器。

注意:默认的控制器列表可能会在将来的版本中更改。 上一个版本中启用的控制器可能会被禁用或弃用,同时也可能会引入新的控制器。 使用此标志的用户应该在系统升级之前查看发布说明。

Kubernetes 控制器

除了由 Karmada 社区维护的控制器之外,Karmada 还需要来自 Kubernetes 的一些控制器。 这些控制器作为 kube-controller-manager 的一部分运行,并由 Kubernetes 社区维护。

建议用户将 kube-controller-manager 与 Karmada 组件一起部署。 installation guide 中的安装方法将帮助您部署它以及 Karmada 组件。

必需的控制器

并非 kube-controller-manager 中的所有控制器都对 Karmada 是必需的。如果您使用其他工具部署 Karmada,则可能需要像我们在 example of kube-controller-manager deployment中所做的那样通过 --controllers 标志来配置控制器。

以下控制器已由 Karmada 进行测试并推荐使用。

namespace

namespace 控制器作为 kube-controller-manager 的一部分运行。它监视 Namespace 删除并删除给定命名空间中的所有资源。

对于 Karmada 控制平面,我们继承了此行为以保持一致的用户体验。 除此之外,我们还依赖此功能来实现 Karmada 控制器,例如,在取消注册集群时,Karmada 将删除存储在 execution namespace 中(命名为 karmada-es-<cluster name>)的所有资源, 以确保所有资源都可以从 Karmada 控制平面和目标集群中清除。

有关 namespace 控制器的更多详细信息,请参考 namespace controller sync logic.

garbagecollector

garbagecollector 控制器作为 kube-controller-manager 的一部分运行。 它用于清理无用资源。 它管理 owner reference 并删除资源,直到全部所有者都不存在。

对于 Karmada 控制平面,我们也使用 owner reference 将对象彼此关联起来。 例如,每个 ResourceBinding 都有一个所有者引用,链接到 resource template。 一旦删除了 resource templategarbagecollector 控制器将自动删除 ResourceBinding

有关垃圾回收机制的更多详细信息,请参考 Garbage Collection.

serviceaccount-token

serviceaccount-token 控制器作为 kube-controller-manager 的一部分运行。 它监听 ServiceAccount 的创建,并创建相应的 ServiceAccount Token Secret,以允许 API 访问。

对于 Karmada 控制平面,在管理员创建 ServiceAccount 对象之后, 我们还需要 serviceaccount-token 控制器来生成 ServiceAccount token Secret,这将减轻管理员的负担,因为他/她不需要手动创建令牌。

有关详细信息,请参考:

clusterrole-aggregation

clusterrole-aggregation 控制器作为 kube-controller-manager 的一部分运行。它会 watch 具有聚合规则设置的 ClusterRole 对象, 并将多个 ClusterRoles 聚合成一个组合的 ClusterRole。

对于 Karmada 控制平面,它将命名空间下的读写权限聚合到了 admin ClusterRole下,此外,它还将 Karmada namespace scope 级别的资源的读 写权限聚合到了 admin 下。

有关详细信息,请参考:

可选控制器

ttl-after-finished

ttl-after-finished 控制器作为 kube-controller-manager 的一部分运行。 它监听 Job 更新并限制已完成 Job 的生存期。 TTL 计时器在 Job 完成时启动,并且在 TTL 到期后将清理已完成的 Job。

对于 Karmada 控制平面,我们还提供了通过指定 Job.spec.ttlSecondsAfterFinished 字段自动清除已完成 Jobs 的功能,这将为控制平面带来便利。

有关详细信息,请参考:

bootstrapsigner

bootstrapsigner 控制器作为 kube-controller-manager 的一部分运行。

这些令牌还用于为“发现”过程中使用的特定 ConfigMap 创建签名,该过程通过 bootstrapsigner 控制器完成。

对于 Karmada 控制平面,我们还在 kube-public 命名空间中提供了 cluster-info ConfigMap。 这是在客户端信任 API 服务器之前,在集群引导过程的早期阶段使用的。 可以通过共享令牌对签名后的 ConfigMap 进行身份验证。

注意:此控制器目前用于由 karmadactl register 注册成员集群的 PULL 模式。

有关详细信息,请参考:

tokencleaner

tokencleaner 控制器作为 kube-controller-manager 的一部分运行。

通过在 Controller Manager 上启用 tokencleaner 控制器可以自动删除过期的令牌。

注意:此控制器目前用于由 karmadactl register 注册成员集群的 PULL 模式。

有关详细信息,请参考:

csrapproving, csrcleaner, csrsigning

这些控制器作为 kube-controller-manager 的一部分运行。

csrcleaner 控制器定期清除过期的 csr。

csrsigning 控制器使用 Karmada 根证书签署证书。

注意:csrcleanercsrsigning 控制器与在 karmada-controller-manager 中运行的 agentcsrapproving 控制器协作,协助 karmadactl register 来完成 PULL 模式集群的注册。

有关详细信息,请参考: