remove insecureSkipTLSVerify in local-up-karmada script

[chaosi-zju]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Backupground: insecureSkipTLSVerify=true means prohibit clientside from verifing the cert of serverside, this is an unsafe configuration, we can avoid unnecessary unsafe configurations.

This PR mainly aims to remove insecureSkipTLSVerify in YAML artifacts used by deploy-karmada.sh.

Which issue(s) this PR fixes:

part of #4024

Special notes for your reviewer:

I have finished following verification test：

• 1. install by hack/local-up-karmada.sh success.
  

• 2. each APIService's AVAILABLE filed equals to True.

  kubectl --context karmada-apiserver get apiservice | grep -E 'NAME | karmada-system'
  

• 3. after I specified the caBunde to apiservice, it occurred new problem as below：

  E0904 21:14:51.103247 3048272 memcache.go:287] couldn't get resource list for custom.metrics.k8s.io/v1beta1: the server is currently unable to handle the request
  E0904 21:14:51.103864 3048272 memcache.go:287] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
  E0904 21:14:51.104357 3048272 memcache.go:287] couldn't get resource list for custom.metrics.k8s.io/v1beta2: the server is currently unable to handle the request
  ...
  GET https://172.18.0.4:5443/apis/custom.metrics.k8s.io/v1beta2?timeout=32s 503 Service Unavailable in 4 milliseconds
  Response Body: error trying to reach service: x509: certificate is valid for localhost, localhost, not karmada-metrics-adapter.karmada-system.svc

  reason: we didn't provide our custom aggregate-apiserver with certificate, we should sign certificate for them.
  resolution: add following launch parameters to karmada-metrics-adapter

  - --tls-cert-file=/etc/karmada/pki/karmada.crt
  - --tls-private-key-file=/etc/karmada/pki/karmada.key

  before add parameters (in picture, ka means kubectl --context karmada-apiserver):
  
  after add parameters:
  

• 4. check if helm installation also used those YAML artifacts, if so, synchronize modifications.
  the karmada-aggregated-apiserver-apiservice.yaml in below picture is just printing a string type key, not quoting the same name file which I modified.
  
  done, no influence to other place.
  updated: hack/deploy-metrics-adapter used karmada-metrics-adapter-apiservice.yaml which I modified.
  verification:
  
  

Does this PR introduce a user-facing change?:

none

[whitewindmills]

an enhancement is right label.
/remove-kind bug
/kind feature

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: -0.01% ⚠️

Comparison is base (7c96e0d) 53.83% compared to head (33b9269) 53.82%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4026      +/-   ##
==========================================
- Coverage   53.83%   53.82%   -0.01%     
==========================================
  Files         231      231              
  Lines       23013    23013              
==========================================
- Hits        12388    12386       -2     
- Misses       9953     9954       +1     
- Partials      672      673       +1     

Flag	Coverage Δ
unittests	53.82% <ø> (-0.01%)	⬇️

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

see 2 files with indirect coverage changes

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

[chaosi-zju]

Thanks for start reviewing~ @RainbowMango @XiShanYongYe-Chang

besides, I modified the launch params of metrics-adapter, have a look @jwcesign

[XiShanYongYe-Chang]

/assign

[XiShanYongYe-Chang]

Good job and nice explanation step.

[XiShanYongYe-Chang]

/lgtm

[jwcesign]

Other lgtm

[RainbowMango]

PR is on going, after motification we should ensure：

PR is still ongoing? Please update the PR descriptions once it ready for review or moving forward.

[RainbowMango]

reason: we didn't provide our custom aggregate-apiserver with certificate, we should sign certificate for them.

What's the ka thing?
I tried following command against karmada-apiserver, didn't find these errors:

-bash-5.0# karmadactl get po
No resources found in  namespace.
-bash-5.0# kubectl get pod
No resources found in default namespace.

[chaosi-zju]

What's the ka thing?

sorry, ka is a alias to kubectl --context karmada-apiserver, I'll add description to above.

I tried following command against karmada-apiserver, didn't find these errors:

the error is introduced after I add caBundle to apiservice, then I add - --tls-cert-file=/etc/karmada/pki/karmada.crt parameter to karmada-metrics-adapter, the error fixed. (I have corrected the description above too.)

[chaosi-zju]

PR is still ongoing? Please update the PR descriptions once it ready for review or moving forward.

ok, and PR is ready to merge

[RainbowMango]

/lgtm
/approve

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [RainbowMango]

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