TLS 啟動引導

　　在一個 Kubernetes 叢集中，工作節點上的元件（kubelet 和 kube-proxy）需要與 Kubernetes 主控元件通訊，尤其是 kube-apiserver。 為了確保通訊本身是私密的、不被幹擾，並且確保叢集的每個元件都在與另一個 可信的元件通訊，我們強烈建議使用節點上的客戶端 TLS 證書。

　　啟動引導這些元件的正常過程，尤其是需要證書來與 kube-apiserver 安全通訊的 工作節點，可能會是一個具有挑戰性的過程，因為這一過程通常不受 Kubernetes 控制， 需要不少額外工作。 這也使得初始化或者擴縮一個叢集的操作變得具有挑戰性。

　　為了簡化這一過程，從 1.4 版本開始，Kubernetes 引入了一個證書請求和簽名 API 以便簡化此過程。該提案可在

　　本文件描述節點初始化的過程，如何為 kubelet 配置 TLS 客戶端證書啟動引導， 以及其背後的工作原理。

初始化過程

當工作節點啟動時，kubelet 執行以下操作：

1. 尋找自己的kubeconfig檔案
2. 檢索 API 伺服器的 URL 和憑據，通常是來自kubeconfig檔案中的 TLS 金鑰和已簽名證書
3. 嘗試使用這些憑據來與 API 伺服器通訊

假定 kube-apiserver 成功地認證了 kubelet 的憑據資料，它會將 kubelet 視為 一個合法的節點並開始將 Pods 分派給該節點。

注意，簽名的過程依賴於：

• kubeconfig中包含金鑰和本地主機的證書
• 證書被 kube-apiserver 所信任的一個證書機構（CA）所簽名

負責部署和管理叢集的人有以下責任：

1. 建立 CA 金鑰和證書
2. 將 CA 證書釋出到 kube-apiserver 執行所在的主控節點上
3. 為每個 kubelet 建立金鑰和證書；強烈建議為每個 kubelet 使用獨一無二的、 CN 取值與眾不同的金鑰和證書
4. 使用 CA 金鑰對 kubelet 證書籤名
5. 將 kubelet 金鑰和簽名的證書釋出到 kubelet 執行所在的特定節點上

本文中描述的 TLS 啟動引導過程有意簡化甚至完全自動化上述過程，尤其是 第三步之後的操作，因為這些步驟是初始化或者擴縮叢集時最常見的操作。

啟動引導初始化

在啟動引導初始化過程中，會發生以下事情：

1. kubelet 啟動
2. kubelet 看到自己沒有對應的kubeconfig檔案
3. kubelet 搜尋並發現bootstrap-kubeconfig檔案
4. kubelet 讀取該啟動引導檔案，從中獲得 API 伺服器的 URL 和用途有限的 一個“令牌（Token）”
5. kubelet 建立與 API 伺服器的連線，使用上述令牌執行身份認證
6. kubelet 現在擁有受限制的憑據來建立和取回證書籤名請求（CSR）
7. kubelet 為自己建立一個 CSR，並將其 signerName 設定為kubernetes.io/kube-apiserver-client-kubelet
8. CSR 被以如下兩種方式之一批覆：

• 如果配置了，kube-controller-manager 會自動批覆該 CSR
• 如果配置了，一個外部程序，或者是人，使用 Kubernetes API 或者使用kubectl來批覆該 CSR

1. kubelet 所需要的證書被建立

1. 證書被髮放給 kubelet
2. kubelet 取回該證書
3. kubelet 建立一個合適的kubeconfig，其中包含金鑰和已簽名的證書
4. kubelet 開始正常操作
5. 可選地，如果配置了，kubelet 在證書接近於過期時自動請求更新證書
6. 更新的證書被批覆併發放；取決於配置，這一過程可能是自動的或者手動完成

本文的其餘部分描述配置 TLS 啟動引導的必要步驟及其侷限性。