Question about Karmada Agent Deployment Method

[richer421]

Environment
Control Plane Deployment: Karmada deployed via Helm + Karmada Operator

Cluster Type: Trying to register member clusters to Karmada

Tools Used: karmadactl register

Problem Description
I'm attempting to register member clusters to my Karmada control plane using karmadactl register, but I'm encountering numerous permission issues during the process.

Specific Issues Encountered:
Bootstrap token permission errors:

Error from server (Forbidden): certificatesigningrequests.certificates.k8s.io is forbidden: 
User "system:bootstrap:xxxxx" cannot create resource "certificatesigningrequests" 
in API group "certificates.k8s.io" at the cluster scope
Anonymous user access issues:
configmaps "cluster-info" is forbidden: User "system:anonymous" cannot get resource "configmaps" 
in API group "" in the namespace "kube-public"

My Questions:
Agent Deployment Method: What is the recommended way to deploy Karmada agent when the control plane is deployed via Helm + Karmada Operator?

Missing RBAC Configuration: Am I missing some critical RBAC configurations? I've checked the documentation but didn't find clear instructions for agent deployment in this setup.

karmadactl Compatibility: Is the karmadactl register approach only suitable for control planes that were also deployed using karmadactl init?

Enterprise Concerns: In larger enterprise environments, the karmadactl approach seems less mature because:

It doesn't easily support private image registries

[zhzhuang-zju]

@richer421 Thanks for your feedback, I'll take a look ASAP~

[zhzhuang-zju]

@richer421

Agent Deployment Method: What is the recommended way to deploy the Karmada agent when the control plane is deployed via Helm + Karmada Operator?

In fact, the recommended approach to deploy the Karmada agent is precisely by using the karmadactl register command. However, your earlier test results were correct: the current operator-based installation does not fully support karmadactl register, primarily due to missing essential RBAC configurations. Out of curiosity—may I ask why you chose to deploy the agent? For your reference, Karmada supports both Push and Pull mode clusters; you can find the differences here: https://karmada.io/docs/userguide/clustermanager/cluster-registration/#overview-of-cluster-mode.

Missing RBAC Configuration: Am I missing some critical RBAC configurations? I've checked the documentation but didn't find clear instructions for agent deployment in this setup.

The required RBAC permissions for karmada-agent in the Karmada control plane are documented in the agent permission section. You can also manually apply the necessary RBAC configuration using:

kubectl --kubeconfig /path/to/your/karmada-apiserver.config apply -f bootstrap-token-configuration.yaml

However, ideally, this support should be built-in rather than requiring manual user intervention.

karmadactl Compatibility: Is the karmadactl register approach only suitable for control planes that were also deployed using karmadactl init?

It shouldn’t be. The register command should not be tied exclusively to init. In fact, we’ve already tracked this issue—see #5755. Somehow, progress stalled, but I believe it’s time to revive this effort.

Enterprise Concerns: In larger enterprise environments, the karmadactl approach seems less mature because: It doesn't easily support private image registries.

Actually, the init command already supports custom image URLs. Could you clarify what specific limitations or inconveniences you’re encountering? If the concern is valid, we’d be happy to add proper support.

Thank you again for your thoughtful feedback and detailed explanation! Also, if you don’t mind sharing— are you using Karmada for personal learning or for enterprise evaluation?