[feature request] yurtctl join use node-servant to finish some job

[adamzhoul]

it's a job after #516

in yurtctl join, what it does to the node itself is included in the node-servant
so we should remove that part of the code and use node-servant package instead

/help

[openyurt-bot]

@adamzhoul:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

it's a job after #516

in yurtctl join, what it does to the node itself is included in the node-servant
so we should remove that part of the code and use node-servant package instead

/help

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.

[adamzhoul]

/assign @adamzhoul

[adamzhoul]

/assign @adamzhoul

[zyjhtangtang]

yurtctl join uses yurt-hub to generate node certificates, and does not include the logic of node-servant. If node-servant is introduced, the yurtctl join process will become complicated. Therefore, I don’t think it is necessary to introduce node-servant in yurtctl join.

[adamzhoul]

thanks for pointing this out @zyjhtangtang
I start to read this part of the code recently.

the core thought is, any operating directly to nodes like revise kubelet or install yurthub can use node-servant.
maybe by import pkg.
other controller logic parts can remain unchanged.

[zyjhtangtang]

Oh, yurtctl join has the logic to install yurthub, this can use node servant. But, the configuration of kubelet is written directly and does not need to be revised. @adamzhoul

[adamzhoul]

by the way, this may introduce a special case:

node  operated by  `yurtctl convert` can retrieve by ` yurtctl revert`
node  operated by  `yurtctl join` can retrieve by `yurtctl reset`

in all, both convert and join will create an openyurt kind node.
but their creation may be different.

[zyjhtangtang]

Are the configuration parameters of kubelet different? @adamzhoul

[adamzhoul]

Here is now what they do to kubelet：

yurtctl convert

1. create kubeconfig file with full path: /var/lib/openyurt/kubelet.conf
2. backup KubeadmConfPath conf file: cp 10-kubeadm.conf 10-kubeadm.conf.bk
3. update 10-kubeadm.conf, set --kubeconfig=/var/lib/openyurt/kubelet.conf

node-servant

1. create kubeconfig file with full path: /var/lib/openyurt/kubelet.conf
2. append file /var/lib/kubelet/kubeadm-flags.env, add --kubeconfig=/var/lib/openyurt/kubelet.conf

append content effect as overwrite the params

yurtctl join

1. create kubeconfig file with full path: /etc/kubernetes/kubelet.conf

[adamzhoul]

forget to mention, all kubelet.conf is no different.

all leads traffic to 127.0.0.1

[zyjhtangtang]

It is necessary to unify the configuration of the three subcommands. This can provide a better user experience. Thanks @adamzhoul

[adamzhoul]

this may introduce a lot of code update to yurtctl join
so you should notice @zyjhtangtang

[zyjhtangtang]

ok, I will pay attention

[adamzhoul]

Hi @zyjhtangtang sorry for the late reply.
after serval days of digging on and off
got some thought below.

what is now

simplify what happened in yurtctl join (edgeNode):

1. write /etc/kubernetes/pki/ca.crt -------------> k8s root ca
2. write /etc/kubernetes/kubelet.conf -----------> spell kubeconfig file for kubelet, hard code apiServer: 127.0.0.1:10261
3. write /var/lib/kubelet/config.yaml -----------> get from configmap
4. write /var/lib/kubelet/kubeadm-flags.env
5. start kubelet
6. write /etc/kubernetes/manifests/yurthub.yaml --> yurthub use cert hubself mode, responsible for token->cert itself
   1. /etc/kubernetes/pki/ca.crt
   2. /var/lib/yurthub/bootstrap-hub.conf
   3. /var/lib/yurthub/pki/.
   4. /var/lib/yurthub/yurthub.conf

simplify what happened in yurtctl join (cloudNode):

1. /etc/kubernetes/bootstrap-kubelet.conf
2. /etc/kubernetes/pki/ca.crt
3. /var/lib/kubelet/config.yaml
4. /var/lib/kubelet/kubeadm-flags.env
5. start kubelet -------------------------> kubelet itself responsible for token->cert etc

in all:

different from kubeadm join which is very complicated.
yurtctl join is very simple, we can simply think its job is:

1. start kubelet
2. deploy yurthub if needed

what is updated

1. the way kubelet consume file kubelet.conf is updated as mentioned before.
2. yurhub is deployed on the cloud now, while yurtctl join(cloud node) could not.

what is the plan

so, we should simplify the process as follow:

1. run runKubeletStartJoinPhase to start kubelet
2. run node-servant/convert to convert to edge-node or cloud-node

the benefit：

1. we can delete file join-edge-node.go , keep runKubeletStartJoinPhase with slightly update is enough
2. any updates in the future won't affect yurtctl join logic, that's covered in node-servant
3. node yurtctl join can be yurtctl revert to a k8s node. this is amazing!

will start to code soon.
please give some comments if you have any thoughts. thanks @zyjhtangtang

[zyjhtangtang]

@adamzhoul Good job! Looking forward to the perfect function of yurtctl join to better enhance the user experience.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.