hack/deploy-scheduler-estimator.sh support deploy estimator in the specified namespace

[zhzhuang-zju]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Currently, the karmada-operator does not provide the capability to install the estimator, so it is often combined with hack/deploy-scheduler-estimator.sh to deploy karmada-scheduler-estimator. However, to better align hack/deploy-scheduler-estimator.sh with the installation method of the karmada-operator, we need to:

• support deploy estimator in the specified namespace
• GRPC certificate names can be configured to meet the needs of users who want to customize their certificate names.

Additionally, split the parameter MEMBER_CLUSTER_NAME into MEMBER_CLUSTER_CONTEXT and MEMBER_CLUSTER_NAME. Sometimes these two values are different and need to be distinguished.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

• The new parameter is an optional parameter, and the default value remains unchanged
• local test

1. deploy karmada instance in test namespace
2. join member cluster member1 with cluster context member1-host
3. hack/deploy-scheduler-estimator.sh ~/.kube/karmada.config karmada-host ~/.kube/member1.config member1-host member1 test karmada-demo-cert

I0909 11:49:10.013859       1 cache.go:111] Start dialing estimator server(karmada-scheduler-estimator-member1.test.svc.cluster.local:10352) of cluster(member1).
I0909 11:49:10.044687       1 cache.go:119] Connection with estimator server(karmada-scheduler-estimator-member1.test.svc.cluster.local:10352) of cluster(member1) has been established.

Does this PR introduce a user-facing change?:

[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 assign xishanyongye-chang 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:

• OWNERS

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

[zhzhuang-zju]

cc @jabellard

[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 33.85%. Comparing base (32c2ef7) to head (ccd6d6f).
Report is 46 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    #5511      +/-   ##
==========================================
+ Coverage   31.70%   33.85%   +2.15%     
==========================================
  Files         643      643              
  Lines       44445    44509      +64     
==========================================
+ Hits        14090    15070     +980     
+ Misses      29325    28289    -1036     
- Partials     1030     1150     +120     

Flag	Coverage Δ
unittests	33.85% <ø> (+2.15%)	⬆️

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]

cc @chaosi-zju

[liangyuanpeng]

this is not requred, right? so how about pinrt two usage:

  echo "Usage: hack/deploy-scheduler-estimator.sh <HOST_CLUSTER_KUBECONFIG> <HOST_CLUSTER_NAME> <MEMBER_CLUSTER_KUBECONFIG> <MEMBER_CLUSTER_NAME>"
  echo "Usage: hack/deploy-scheduler-estimator.sh <HOST_CLUSTER_KUBECONFIG> <HOST_CLUSTER_NAME> <MEMBER_CLUSTER_KUBECONFIG> <MEMBER_CLUSTER_CONTEXT> [<MEMBER_CLUSTER_NAME> <SCHEDULER-ESTIMATOR-NAMESPACE> <GRPC_AUTH_SECRET_NAME>]"

[zhzhuang-zju]

nice suggestion

[chaosi-zju]

echo "Usage: hack/deploy-scheduler-estimator.sh <HOST_CLUSTER_KUBECONFIG> <HOST_CLUSTER_NAME> <MEMBER_CLUSTER_KUBECONFIG> <MEMBER_CLUSTER_CONTEXT> [<MEMBER_CLUSTER_NAME> <GRPC_AUTH_SECRET_NAME>]"

but after this modified, MEMBER_CLUSTER_NAME is actually the required parameter, since it will be applied to karmada-scheduler-estimator.yaml

[zhzhuang-zju]

MEMBER_CLUSTER_CONTEXT=$4
MEMBER_CLUSTER_NAME=${5:-$4}

By default, MEMBER_CLUSTER_CONTEXT and MEMBER_CLUSTER_NAME are the same value.

[chaosi-zju]

I still think the parameters of the later one is so long and confusing.
one moment HOST_CLUSTER_NAME, while one moment MEMBER_CLUSTER_CONTEXT, mixed use of nouns.

--

I think the parameters of karmadactl join is very clear, just like:

karmadactl join CLUSTER_NAME --kubeconfig KARMADA_KUBECONFIG --karmada-context KARMADA_CONTEXT --cluster-kubeconfig CLUSTER_KUBECONFIG --cluster-context CLUSTER_CONTEXT

the CLUSTER_NAME is the target object to deploy, while the following four args is the common and well understood k8s nouns.

So, I suggest the command to be:

hack/deploy-scheduler-estimator.sh <MEMBER_CLUSTER_NAME> <HOST_CLUSTER_KUBECONFIG> <HOST_CLUSTER_CONTEXT> <MEMBER_CLUSTER_KUBECONFIG> <MEMBER_CLUSTER_CONTEXT>

These parameters are required by the user according to the actual environment.

--

As for other parameters, they are optional and only necessary to a part of people. These can be passed by environment variables with our preset default value, just like

SCHEDULER_ESTIMATOR_NAMESPACE=${SCHEDULER_ESTIMATOR_NAMESPACE:-"karmada-system"}
GRPC_AUTH_SECRET_NAME=${GRPC_AUTH_SECRET_NAME:-"karmada-cert-secret"}

Otherwise, if I were a new user, a new proprietary name GRPC_AUTH_SECRET_NAME would dissuade me.

[zhzhuang-zju]

I'm fine with it. Previously, it was to maintain consistent behavior in the script. If there's no requirement for this, I'd be happy to modify it according to your suggestion.

[chaosi-zju]

why we need define this?

[zhzhuang-zju]

To meet users' needs for customizing gRPC certificate, this also avoids the differences in secret names caused by different installation methods.