kubelet tls

當成功簽發證書後，目標節點的 kubelet 會將證書寫入到 --cert-dir= 選項指定的目錄中；此時若是不作其餘設置應當生成上述除ca.pem之外的4個文件

kubelet-client.crt 該文件在 kubelet 完成 TLS bootstrapping 後生成，此證書是由 controller manager 簽署的，此後 kubelet 將會加載該證書，用於與 apiserver 創建 TLS 通信，同時使用該證書的 CN 字段做爲用戶名，O 字段做爲用戶組向 apiserver 發起其餘請求
kubelet.crt 該文件在 kubelet 完成 TLS bootstrapping 後而且沒有配置 --feature-gates=RotateKubeletServerCertificate=true 時纔會生成；這種狀況下該文件爲一個獨立於 apiserver CA 的自籤 CA 證書，有效期爲 1 年；被用做 kubelet 10250 api 端口

在官方 TLS bootstrapping 文檔中屢次提到過 kubelet server 這個東西；在通過翻閱大量文檔以及 TLS bootstrapping 設計文檔後得出，kubelet server * 指的應該是 kubelet 的 10250 端口 *；

kubelet 組件在工做時，採用主動的查詢機制，即按期請求 apiserver 獲取本身所應當處理的任務，如哪些 pod 分配到了本身身上，從而去處理這些任務；同時 kubelet 本身還會暴露出兩個自己 api 的端口，用於將本身自己的私有 api 暴露出去，這兩個端口分別是 10250 與 10255；對於 10250 端口，kubelet 會在其上採用 TLS 加密以提供適當的鑑權功能；對於 10255 端口，kubelet 會以只讀形式暴露組件自己的私有 api，而且不作鑑權處理 *

總結一下，就是說 kubelet 上實際上有兩個地方用到證書，一個是用於與 API server 通信所用到的證書，另外一個是 kubelet 的 10250 私有 api 端口須要用到的證書 *

2.二、CSR 請求類型
kubelet 發起的 CSR 請求都是由 controller manager 來作實際簽署的，對於 controller manager 來講，TLS bootstrapping 下 kubelet 發起的 CSR 請求大體分爲如下三種

nodeclient: kubelet 以 O=system:nodes 和 CN=system:node:(node name) 形式發起的 CSR 請求
selfnodeclient: kubelet client renew 本身的證書發起的 CSR 請求(與上一個證書就有相同的 O 和 CN)
selfnodeserver: kubelet server renew 本身的證書發起的 CSR 請求

大白話加本身測試得出的結果: nodeclient 類型的 CSR 僅在第一次啓動時會產生，selfnodeclient 類型的 CSR 請求實際上就是 kubelet renew 本身做爲 client 跟 apiserver 通信時使用的證書產生的，selfnodeserver 類型的 CSR 請求則是 kubelet 首次申請或後續 renew 本身的 10250 api 端口證書時產生的 *

做者：ywhu
連接：https://www.jianshu.com/p/bb973ab1029b
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。