add domain support for certgen.sh

[lwabish]

What type of PR is this?
/kind bug

What this PR does / why we need it:
the original script failed when providing a domain name.
Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

[fisherxu]

@lwabish Why do you build the certs manually instead of using the certs generted by cloudcore?

[lwabish]

@lwabish Why do you build the certs manually instead of using the certs generted by cloudcore?

I was following the Enable kubectl logs Feature steps after install cloudcore and init my edge node. @fisherxu

[fisherxu]

Ok, it should only use the stream func.

[lwabish]

Ok, it should only use the stream func.

yes,indeed. So should I leave the genCert() funciton as it was?

[fisherxu]

stream is only used to the communition between cloudcore and apiserver, I think the domain name is used to communicate between cloudhub and edgehub, so it's no need to add the domain name in stream's certs. And genCert haven't been used now..

[lwabish]

oh I see.
In this case, I deployed cloudcore in k8s,so I need to use cloudcore.kubeedge to generate the stream cert so that apiserver can locate cloudcore, is this right?

[kubeedge-bot]

@ramezanius: adding LGTM is restricted to approvers and reviewers in OWNERS files.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fisherxu]

In this case, I deployed cloudcore in k8s,so I need to use cloudcore.kubeedge to generate the stream cert so that apiserver can locate cloudcore, is this right?

Yes, if the cloudocre domain used for edgeside, the domain name maybe a public domain. If apiserver connects to the cloudcore, it may not have to use that public domin, domain name incluster should be also fine, like svc.ns.cluster.local.

Anyway, set the domain name in stream's certs is reasonable, and can we set another env value like CLOUDCORE_DOMAINS? And the docs also need to be updated :) @lwabish

[fisherxu]

Looks good, and could you please squash the 4 commits? Thanks.

[lwabish]

previous commits squashed.
is the "fetch upstream commit" necessary to be squashed too?

[fisherxu]

previous commits squashed. is the "fetch upstream commit" necessary to be squashed too?

Yes, fetch upstream commit is no needed here :)

[lwabish]

previous commits squashed. is the "fetch upstream commit" necessary to be squashed too?

Yes, fetch upstream commit is no needed here :)

done

[fisherxu]

Thanks, and would you like to update the docs? Ref: https://github.com/kubeedge/website/blob/master/content/en/docs/setup/keadm.md#enable-kubectl-logs-feature

[fisherxu]

/lgtm
/approve

[kubeedge-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fisherxu, ramezanius

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 [fisherxu]

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

[lwabish]

Thanks, and would you like to update the docs? Ref: https://github.com/kubeedge/website/blob/master/content/en/docs/setup/keadm.md#enable-kubectl-logs-feature

sure, i'll work on it later.
I also found that the stream certs of cloudcore deployed using helm was generated within the helm chart, running certgen.sh stream is not needed in this case. So maybe I could also try improving the doc about stream certs.