Revise yurtctl tutorial (openyurtio#26)

docs/tutorial/yurtctl.md

@@ -24,28 +24,24 @@ $ _output/bin/yurtctl convert --provider minikube
 
 3. yurt controller manager and yurthub Pods will be up and running in one minute. Let us verify them:
 ```bash
- $ kubectl get deploy yurt-ctrl-mgr -n kube-system
+$ kubectl get deploy yurt-ctrl-mgr -n kube-system
 NAME            READY   UP-TO-DATE   AVAILABLE   AGE
 yurt-ctrl-mgr   1/1     1            1           23h
-
- $ kubectl get po yurt-hub-minikube -n kube-system
+$ kubectl get po yurt-hub-minikube -n kube-system
 NAME                READY   STATUS    RESTARTS   AGE
 yurt-hub-minikube   1/1     Running   0          23h
 ```
 
 4. As the minikube cluster only contains one node, the node will be marked as an autonomous edge node. Let us verify this by inspecting the node's labels and annotations:
 ```
- # edge node will have label "alibabacloud.com/is-edge-worker" set as "true"
 $ kubectl describe node | grep Labels -A 3
-Labels:             alibabacloud.com/is-edge-worker=true
-
- # aautonomou node will have annotation "node.beta.alibabacloud.com/autonomy" set as "true"
+Labels:      alibabacloud.com/is-edge-worker=true
 $ kubectl describe node | grep Annotations -A 3
-Annotations:        node.beta.alibabacloud.com/autonomy: true
+Annotations: node.beta.alibabacloud.com/autonomy: true
 ```
 
-By now, the OpenYurt cluster is ready. Users will not notice any differences when operating the cluster.
-If you login to the node, you will find local caches are populated:
+By now, the OpenYurt cluster is ready. Users will not notice any differences compared to native Kubernetes when operating the cluster.
+If you login to the node, you will find the local cache has been populated:
 
 ```
 $ minikube ssh
@@ -54,7 +50,7 @@ configmaps  events  leases  nodes  pods  secrets  services
 ```
 
 
-### Test Node Autonomy
+### Test node autonomy
 
 To test if edge node autonomy works as expected, we will simulate a node "offline" scenario. 
 1. Let's first create a sample pod:
@@ -106,19 +102,19 @@ bbox   1/1     Running   0          19m
 
 ## Convert a multi-nodes Kubernetes cluster
 
-In practice, an OpenYurt cluster may consist of some edge nodes and some nodes in the cloud site. 
+An OpenYurt cluster may consist of some edge nodes and some nodes in the cloud site. 
 `yurtctl` allows users to specify a list of cloud nodes that won't be converted.
 
 
-1. Assume you have a [two-nodes minikube cluster](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/), 
+1. Start with a [two-nodes minikube cluster](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/), 
 ```bash
 $ kubectl get node
 NAME           STATUS   ROLES    AGE    VERSION
 minikube       Ready    master   2m5s   v1.18.2
 minikube-m02   Ready    <none>   84s    v1.18.2
 ```
 
-2. you can convert only one node to edge node(i.e., minikube-m02) by using the following command 
+2. You can convert only one node to edge node(i.e., minikube-m02) by using this command:
 ```bash
 $ _output/bin/yurtctl convert --cloud-nodes minikube --provider minikube
 convert.go:140] mark minikube as the cloud-node
@@ -157,8 +153,16 @@ Note that before performing the uninstall, please make sure all edge nodes are r
 
 ## Troubleshooting
 
-### 1. Fail to convert due to pulling image timeout
+### 1. Failure due to pulling image timeout
+
+The default timeout value of cluster conversion is 2 minutes. Sometimes pulling the related images 
+might take more than 2 minutes. To avoid the conversion failure due to pulling images timeout, you can pull all images on the node manually
+or use automation tools such as `broadcastjob`(from [Kruise](https://github.com/openkruise/kruise/blob/master/docs/concepts/broadcastJob/README.md)) in advance.
 
-The default timeout value of the conversion is 2 minutes. Sometimes pulling the related images 
-can take more than 2 minutes. To avoid the conversion failure due to pulling images timeout, you can pull images on the node manually
-or use automation tools such as the `broadcastjob`(from [Kruise](https://github.com/openkruise/kruise/blob/master/docs/concepts/broadcastJob/README.md)) in advance.
+### 2. Adhoc failure recovery
+
+In case any adhoc failure makes the Kubelet fail to communicate with APIServer, one can recover the original Kubelet setup by
+running the following command in edge node directly:
+```
+$ sudo sed -i "s|--kubeconfig=.*kubelet.conf|--kubeconfig=/etc/kubernetes/kubelet.conf|g;" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf && sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
+```