問題：
1）從kubelet.service中我們能看到參數–kubeconfig=/etc/kubernetes/kubelet.kubeconfig，但是節點配置流程中卻並未添加該文件，如下，那麼該文件是怎麼來的呢？記錄了什麼信息？
ls /etc/kubernetes/
bootstrap.kubeconfig ca kube-proxy.kubeconfig
2）節點配置完成啓動kubelet後，執行kubectl get csr能看到Pending狀態，那麼kubectl certificate approve是怎麼認證節點並建立通信的呢？
$ kubectl get csr
NAME AGE REQUESTOR CONDITION
node-csr-URWr1jYw4q-Zg9sqnbzMJ1do9OMCWfiJkWbqy8zaQ7s 1h kubelet-bootstrap Pending
分析：
首先看看kubelet相關啓動流程，如下：
kubelet.go:
command.Execute()
server.go:
NewKubeletCommand()->Run()->run()->bootstrap.LoadClientCert()
bootstrap.go:
LoadClientCert()->verifyBootstrapClientConfig(kubeconfigPath)->loadRESTClientConfig(bootstrapPath)->certificates.NewForConfig(bootstrapClientConfig)->csr.RequestNodeCertificate->clientcmd.WriteToFile(kubeconfigData, kubeconfigPath)
a）verifyBootstrapClientConfig中的kubeconfigPath自然就是kubelet啓動參數中傳入的–kubeconfig，這裏的配置驗證主要是解析客戶端配置、加載傳輸配置、加載tls配置、解析證書、證書過期校驗。如果一切正常，LoadClientCert會直接返回nil，進入後續工作流程。
b）如果配置、證書錯誤或者kubelet.kubeconfig不存在均會返回false，之後加載解析的的就是bootstrap.kubeconfig這個文件了。這就進入關鍵點csr.RequestNodeCertificate了，首先會通過MakeEllipticPrivateKeyPEM生成私鑰，之後使用認證請求、私鑰、節點名生成CSR請求證書，發送後通過WaitForCertificate等待master審批，超時等待時間爲1小時。審批完成後將相關配置以及證書寫入kubelet.kubeconfig文件中。
結論：
這樣問題的答案已經很清晰了，對於問題1），kubelet.kubeconfig是master批覆CSR請求後客戶端生成的。而問題2），其實master、node建立通信的過程就是標準的CSR請求流程，而Pending狀態就是節點等待master審批CSR請求的等待狀態，在這期間節點會一直阻塞在這裏。