Support Karmada installed by operator to use karmadactl register

[zhzhuang-zju]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Karmadactl register is a command provided by Karmada to register pull mode clusters to the Karmada control plane. Currently, when Karmada is installed via the karmada-operator, there are functional issues when executing karmadactl register.

# the logs of karmada-agent
E1030 07:23:16.017086       1 leaderelection.go:351] error initially creating leader election record: leases.coordination.k8s.io "karmada-agent-kind-member4" is forbidden: can only access leases in the "kube-node-lease" system namespace

The purpose of this PR is to support Karmada installations by the operator to use karmadactl register. The changes include:

• Remove the NodeRestriction Admission Controller plugin from karmada-apiserver.

NodeRestriction limits the Node and Pod objects a kubelet can modify. In order to be limited by this admission controller, kubelets must use credentials in the system:nodes group, with a username in the form system:node:. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node. kubelets are not allowed to update or remove taints from their Node API object.

Due to the credentials used by the karmada-agent being in the system:nodes group, with a username in the form system:node:, its permissions are restricted.

• The hack script uses the karmadactl register command to register a pull mode member cluster.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

`karmada-operator`: Support Karmada installed by operator to use karmadactl register

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from zhzhuang-zju and additionally assign lonelycz for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• hack/OWNERS
• operator/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 42.31%. Comparing base (9c0bd72) to head (84b6770).
Report is 2 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5755      +/-   ##
==========================================
+ Coverage   42.25%   42.31%   +0.06%     
==========================================
  Files         655      655              
  Lines       55756    55756              
==========================================
+ Hits        23561    23595      +34     
+ Misses      30683    30649      -34     
  Partials     1512     1512              

Flag	Coverage Δ
unittests	42.31% <ø> (+0.06%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zhzhuang-zju]

error: couldn't save bootstrap-karmada-agent.conf to disk: mkdir /etc/karmada: permission denied

Due to the lack of permissions in CI to create directories /etc/karmada, this PR focuses on providing support for karmadactl register via the karmada-operator. Once PR #5429 is merged, the hack script will be updated to use the karmadactl register command to register the pull mode member cluster.

[zhzhuang-zju]

local Verification:

$ hack/local-up-karmada-by-operator.sh
$ hack/create-cluster.sh member4 ~/.kube/member4.config
$ eval $(karmadactl token create --print-register-command  --kubeconfig ~/.kube/karmada.config --karmada-context karmada-apiserver) --kubeconfig ~/.kube/member4.config --karmada-agent-image docker.io/karmada/karmada-agent:latest
[preflight] Running pre-flight checks
[preflight] All pre-flight checks were passed
[karmada-agent-start] Waiting to perform the TLS Bootstrap
[karmada-agent-start] Waiting to construct karmada-agent kubeconfig
[karmada-agent-start] Waiting to check cluster exists
[karmada-agent-start] Waiting the necessary secret and RBAC
[karmada-agent-start] Waiting karmada-agent Deployment

cluster(kind-member4) is joined successfully

[zhzhuang-zju]

cc @jabellard @RainbowMango

[RainbowMango]

/hold
Given the hack/deploy-karmada-by-operator.sh is not developed for end users, the enhancement should against karmada-opeator instead of shell script desined for testing.

[zhzhuang-zju]

/hold Given the hack/deploy-karmada-by-operator.sh is not developed for end users, the enhancement should against karmada-opeator instead of shell script desined for testing.

good point! Incorporating RBAC configurations into the workflow of the karmada-operator is more reasonable