Configure Controllers
Karmada maintains a bunch of controllers which are control loops that watch the state of your system, then make or request changes where needed. Each controller tries to move the current state closer to the desired state. See Kubernetes Controller Concepts for more details.
Karmada Controllers
The controllers are embedded into components of karmada-controller-manager or karmada-agent and will be launched
along with components startup. Some controllers may be shared by karmada-controller-manager and karmada-agent.
| Controller | In karmada-controller-manager | In karmada-agent |
|---|---|---|
| cluster | Y | N |
| clusterStatus | Y | Y |
| binding | Y | N |
| execution | Y | Y |
| workStatus | Y | Y |
| namespace | Y | N |
| serviceExport | Y | Y |
| endpointSlice | Y | N |
| serviceImport | Y | N |
| unifiedAuth | Y | N |
| hpa | Y(disabled by default) | N |
| federatedResourceQuotaSync | Y | N |
| federatedResourceQuotaStatus | Y | N |
| gracefulEviction | Y | N |
| certRotation | N | Y(disabled by default) |
| applicationFailover | Y | N |
| federatedHPA | Y | N |
Configure Karmada Controllers
You can use --controllers flag to specify the enabled controller list for karmada-controller-manager and
karmada-agent, or disable some of them in addition to the default list.
E.g. Specify a controller list:
--controllers=cluster,clusterStatus,binding,xxx
E.g. Disable some controllers(remember to keep * if you want to keep the rest controllers in the default list):
--controllers=-hpa,-unifiedAuth,*
Use -foo to disable the controller named foo.
Note: The default controller list might be changed in the future releases. The controllers enabled in the last release might be disabled or deprecated and new controllers might be introduced too. Users who are using this flag should check the release notes before system upgrade.
Kubernetes Controllers
In addition to the controllers that are maintained by the Karmada community, Karmada also requires some controllers from
Kubernetes. These controllers run as part of kube-controller-manager and are maintained by the Kubernetes community.
Users are recommended to deploy the kube-controller-manager along with Karmada components. And the installation
methods list in installation guide would help you deploy it as well as Karmada components.
Required Controllers
Not all controllers in kube-controller-manager are necessary for Karmada, if you are deploying
Karmada using other tools, you might have to configure the controllers by --controllers flag just like what we did in
example of kube-controller-manager deployment.
The following controllers are tested and recommended by Karmada.
namespace
The namespace controller runs as part of kube-controller-manager. It watches Namespace deletion and deletes
all resources in the given namespace.
For the Karmada control plane, we inherit this behavior to keep a consistent user experience. More than that, we also
rely on this feature in the implementation of Karmada controllers, for example, when un-registering a cluster,
Karmada would delete the execution namespace(named karmada-es-<cluster name>) that stores all the resources
propagated to that cluster, to ensure all the resources could be cleaned up from both the Karmada control plane and the
given cluster.
More details about the namespace controller, please refer to
namespace controller sync logic.
garbagecollector
The garbagecollector controller runs as part of kube-controller-manager. It is used to clean up garbage resources.
It manages owner reference and
deletes the resources once all owners are absent.
For the Karmada control plane, we also use owner reference to link objects to each other. For example, each
ResourceBinding has an owner reference that link to the resource template. Once the resource template is removed,
the ResourceBinding will be removed by garbagecollector controller automatically.
For more details about garbage collection mechanisms, please refer to Garbage Collection.
serviceaccount-token
The serviceaccount-token controller runs as part of kube-controller-manager.
It watches ServiceAccount creation and creates a corresponding ServiceAccount token Secret to allow API access.
For the Karmada control plane, after a ServiceAccount object is created by the administrator, we also need
serviceaccount-token controller to generate the ServiceAccount token Secret, which will be a relief for
administrator as he/she doesn't need to manually prepare the token.
More details please refer to:
Optional Controllers
ttl-after-finished
The ttl-after-finished controller runs as part of kube-controller-manager.
It watches Job updates and limits the lifetime of finished Jobs.
The TTL timer starts when the Job finishes, and the finished Job will be cleaned up after the TTL expires.
For the Karmada control plane, we also provide the capability to clean up finished Jobs automatically by
specifying the .spec.ttlSecondsAfterFinished field of a Job, which will be a relief for the control plane.
More details please refer to:
bootstrapsigner
The bootstrapsigner controller runs as part of kube-controller-manager.
The tokens are also used to create a signature for a specific ConfigMap used in a "discovery" process through a bootstrapsigner controller.
For the Karmada control plane, we also provide cluster-info ConfigMap in kube-public namespace. This is used early in a cluster bootstrap process before the client trusts the API server. The signed ConfigMap can be authenticated by the shared token.
Note: this controller currently is used to register member clusters with PULL mode by
karmadactl register.
More details please refer to:
tokencleaner
The tokencleaner controller runs as part of kube-controller-manager.
Expired tokens can be deleted automatically by enabling the tokencleaner controller on the controller manager.
Note: this controller currently is used to register member clusters with PULL mode by
karmadactl register.
More details please refer to:
csrapproving, csrcleaner, csrsigning
The controllers runs as part of kube-controller-manager.
The csrapproving controller uses the SubjectAccessReview API to determine if a given user is authorized to request a CSR, then approves based on the authorization outcome.
The csrcleaner controller clears expired csr periodically.
The csrsigning controller signs the certificate using Karmada root CA.
Note: these controllers currently are used to register member clusters with PULL mode by
karmadactl register.
More details please refer to: