閱讀本文章前，請先閱讀一下本文參考的相關文檔:
一、TLS bootstrapping
1、簡介
當集群開啟了 TLS 認證后，每個節點的 kubelet 組件都要使用由 apiserver 使用的 CA 簽發的有效證書才能與 apiserver 通訊；此時如果節點多起來，為每個節點單獨簽署證書將是一件非常繁瑣的事情；TLS bootstrapping 功能就是讓 kubelet 先使用一個預定的低權限用戶連接到 apiserver，然后向 apiserver 申請證書，kubelet 的證書由 apiserver 動態簽署；在配合 RBAC 授權模型下的工作流程大致如下所示(不完整，下面細說)
2、TLS bootstrapping 相關術語
2.1、kubelet server
在官方 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.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 端口證書時產生的
3、TLS bootstrapping 具體引導過程
3.1、Kubernetes TLS 與 RBAC 認證
在說具體的引導過程之前先談一下 TLS 和 RBAC，因為這兩個事不整明白下面的都不用談；
- TLS 作用
眾所周知 TLS 的作用就是對通訊加密，防止中間人竊聽；同時如果證書不信任的話根本就無法與 apiserver 建立連接，更不用提有沒有權限向 apiserver 請求指定內容
- RBAC 作用
當 TLS 解決了通訊問題后，那么權限問題就應由 RBAC 解決(可以使用其他權限模型，如 ABAC)；RBAC 中規定了一個用戶或者用戶組(subject)具有請求哪些 api 的權限；在配合 TLS 加密的時候，實際上 apiserver 讀取客戶端證書的 CN 字段作為用戶名，讀取 O 字段作為用戶組
從以上兩點上可以總結出兩點: 第一，想要與 apiserver 通訊就必須采用由 apiserver CA 簽發的證書，這樣才能形成信任關系，建立 TLS 連接；第二，可以通過證書的 CN、O 字段來提供 RBAC 所需的用戶與用戶組
3.2、kubelet 首次啟動流程
看完上面的介紹，不知道有沒有人想過，既然 TLS bootstrapping 功能是讓 kubelet 組件去 apiserver 申請證書，然后用於連接 apiserver；那么第一次啟動時沒有證書如何連接 apiserver ?
這個問題實際上可以去查看一下 bootstrap.kubeconfig 和 token.csv 得到答案: 在 apiserver 配置中指定了一個 token.csv 文件，該文件中是一個預設的用戶配置；同時該用戶的 Token 和 apiserver 的 CA 證書被寫入了 kubelet 所使用的 bootstrap.kubeconfig 配置文件中；這樣在首次請求時，kubelet 使用 bootstrap.kubeconfig 中的 apiserver CA 證書來與 apiserver 建立 TLS 通訊，使用 bootstrap.kubeconfig 中的用戶 Token 來向 apiserver 聲明自己的 RBAC 授權身份，如下圖所示：
在有些用戶首次啟動時，可能與遇到 kubelet 報 401 無權訪問 apiserver 的錯誤；這是因為在默認情況下，kubelet 通過 bootstrap.kubeconfig 中的預設用戶 Token 聲明了自己的身份，然后創建 CSR 請求；但是不要忘記這個用戶在我們不處理的情況下他沒任何權限的，包括創建 CSR 請求；所以需要如下命令創建一個 ClusterRoleBinding，將預設用戶 kubelet-bootstrap 與內置的 ClusterRole system:node-bootstrapper 綁定到一起，使其能夠發起 CSR 請求
kubectl create clusterrolebinding kubelet-bootstrap \ --clusterrole=system:node-bootstrapper \ --user=kubelet-bootstrap
3.3、手動簽發證書
在 kubelet 首次啟動后，如果用戶 Token 沒問題，並且 RBAC 也做了相應的設置，那么此時在集群內應該能看到 kubelet 發起的 CSR 請求
出現 CSR 請求后，可以使用 kubectl 手動簽發(允許) kubelet 的證書
當成功簽發證書后，目標節點的 kubelet 會將證書寫入到 --cert-dir= 選項指定的目錄中；注意此時如果不做其他設置應當生成四個文件
而 kubelet 與 apiserver 通訊所使用的證書為 kubelet-client.crt，剩下的 kubelet.crt 將會被用於 kubelet server(10250) 做鑒權使用；注意，此時 kubelet.crt 這個證書是個獨立於 apiserver CA 的自簽 CA，並且刪除后 kubelet 組件會重新生成它
4、TLS bootstrapping 證書自動續期
4.1、RBAC 授權
首先…首先好幾次了…嗯，就是說 kubelet 所發起的 CSR 請求是由 controller manager 簽署的；如果想要是實現自動續期，就需要讓 controller manager 能夠在 kubelet 發起證書請求的時候自動幫助其簽署證書；那么 controller manager 不可能對所有的 CSR 證書申請都自動簽署，這時候就需要配置 RBAC 規則，保證 controller manager 只對 kubelet 發起的特定 CSR 請求自動批准即可；在 TLS bootstrapping 官方文檔中，針對上面 2.2 章節提出的 3 種 CSR 請求分別給出了 3 種對應的 ClusterRole，如下所示：
# A ClusterRole which instructs the CSR approver to approve a user requesting # node client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: approve-node-client-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/nodeclient"] verbs: ["create"] --- # A ClusterRole which instructs the CSR approver to approve a node renewing its # own client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: approve-node-client-renewal-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeclient"] verbs: ["create"] --- # A ClusterRole which instructs the CSR approver to approve a node requesting a # serving cert matching its client cert. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: approve-node-server-renewal-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeserver"] verbs: ["create"]
RBAC 中 ClusterRole 只是描述或者說定義一種集群范圍內的能力，這三個 ClusterRole 在 1.7 之前需要自己手動創建，在 1.8 后 apiserver 會自動創建前兩個(1.8 以后名稱有改變，自己查看文檔)；以上三個 ClusterRole 含義如下：
- approve-node-client-csr: 具有自動批准 nodeclient 類型 CSR 請求的能力
- approve-node-client-renewal-csr: 具有自動批准 selfnodeclient 類型 CSR 請求的能力
- approve-node-server-renewal-csr: 具有自動批准 selfnodeserver 類型 CSR 請求的能力
所以，如果想要 kubelet 能夠自動續期，那么就應當將適當的 ClusterRole 綁定到 kubelet 自動續期時所所采用的用戶或者用戶組身上。
4.2、自動續期下的引導過程
在自動續期下引導過程與單純的手動批准 CSR 有點差異，具體的引導流程地址如下
- kubelet 讀取 bootstrap.kubeconfig，使用其 CA 與 Token 向 apiserver 發起第一次 CSR 請求(nodeclient)
- apiserver 根據 RBAC 規則自動批准首次 CSR 請求(approve-node-client-csr)，並下發證書(kubelet-client.crt)
- kubelet 使用剛剛簽發的證書(O=system:nodes, CN=system:node:NODE_NAME)與 apiserver 通訊，並發起申請 10250 server 所使用證書的 CSR 請求
- apiserver 根據 RBAC 規則自動批准 kubelet 為其 10250 端口申請的證書(kubelet-server-current.crt)
- 證書即將到期時，kubelet 自動向 apiserver 發起用於與 apiserver 通訊所用證書的 renew CSR 請求和 renew 本身 10250 端口所用證書的 CSR 請求
- apiserver 根據 RBAC 規則自動批准兩個證書
- kubelet 拿到新證書后關閉所有連接，reload 新證書，以后便一直如此
從以上流程我們可以看出，我們如果要創建 RBAC 規則，則至少能滿足四種情況:
- 自動批准 kubelet 首次用於與 apiserver 通訊證書的 CSR 請求(nodeclient)
- 自動批准 kubelet 首次用於 10250 端口鑒權的 CSR 請求(實際上這個請求走的也是 selfnodeserver 類型 CSR)
- 自動批准 kubelet 后續 renew 用於與 apiserver 通訊證書的 CSR 請求(selfnodeclient)
- 自動批准 kubelet 后續 renew 用於 10250 端口鑒權的 CSR 請求(selfnodeserver)
基於以上四種情況，我們需要創建 3 個 ClusterRoleBinding，創建如下：
# 自動批准 kubelet 的首次 CSR 請求(用於與 apiserver 通訊的證書) kubectl create clusterrolebinding node-client-auto-approve-csr --clusterrole=approve-node-client-csr --group=system:bootstrappers # 自動批准 kubelet 后續 renew 用於與 apiserver 通訊證書的 CSR 請求 kubectl create clusterrolebinding node-client-auto-renew-crt --clusterrole=approve-node-client-renewal-csr --group=system:nodes # 自動批准 kubelet 發起的用於 10250 端口鑒權證書的 CSR 請求(包括后續 renew) kubectl create clusterrolebinding node-server-auto-renew-crt --clusterrole=approve-node-server-renewal-csr --group=system:nodes
4.3、開啟自動續期
在 1.7 后，kubelet 啟動時增加 --feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true 選項，則 kubelet 在證書即將到期時會自動發起一個 renew 自己證書的 CSR 請求；同時 controller manager 需要在啟動時增加 --feature-gates=RotateKubeletServerCertificate=true 參數，再配合上面創建好的 ClusterRoleBinding，kubelet client 和 kubelet server 證才書會被自動簽署；
注意，1.7 版本設置自動續期參數后，新的 renew 請求不會立即開始，而是在證書總有效期的 70%~90% 的時間時發起；而且經測試 1.7 版本即使自動簽發了證書，kubelet 在不重啟的情況下不會重新應用新證書；在 1.8 后 kubelet 組件在增加一個 --rotate-certificates 參數后，kubelet 才會自動重載新證書
4.3、證書過期問題
需要重復強調一個問題是: TLS bootstrapping 時的證書實際是由 kube-controller-manager 組件來簽署的，也就是說證書有效期是 kube-controller-manager 組件控制的；所以在 1.7 版本以后(我查文檔發現的從1.7開始有) kube-controller-manager 組件提供了一個 --experimental-cluster-signing-duration 參數來設置簽署的證書有效時間；默認為 8760h0m0s，將其改為 87600h0m0s 即 10 年后再進行 TLS bootstrapping 簽署證書即可。
5、TLS bootstrapping 總結以及詳細操作
5.1、主要流程細節
kubelet 首次啟動通過加載 bootstrap.kubeconfig 中的用戶 Token 和 apiserver CA 證書發起首次 CSR 請求，這個 Token 被預先內置在 apiserver 節點的 token.csv 中，其身份為 kubelet-bootstrap 用戶和 system:bootstrappers 用戶組；想要首次 CSR 請求能成功(成功指的是不會被 apiserver 401 拒絕)，則需要先將 kubelet-bootstrap 用戶和 system:node-bootstrapper 內置 ClusterRole 綁定；
對於首次 CSR 請求可以手動批准，也可以將 system:bootstrappers 用戶組與 approve-node-client-csr ClusterRole 綁定實現自動批准(1.8 之前這個 ClusterRole 需要手動創建，1.8 后 apiserver 自動創建，並更名為 system:certificates.k8s.io:certificatesigningrequests:nodeclient)
默認簽署的的證書只有 1 年有效期，如果想要調整證書有效期可以通過設置 kube-controller-manager 的 --experimental-cluster-signing-duration 參數實現，該參數默認值為 8760h0m0s
對於證書自動續簽，需要通過協調兩個方面實現；第一，想要 kubelet 在證書到期后自動發起續期請求，則需要在 kubelet 啟動時增加 --feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true 來實現；第二，想要讓 controller manager 自動批准續簽的 CSR 請求需要在 controller manager 啟動時增加 --feature-gates=RotateKubeletServerCertificate=true 參數，並綁定對應的 RBAC 規則；同時需要注意的是 1.7 版本的 kubelet 自動續簽后需要手動重啟 kubelet 以使其重新加載新證書，而 1.8 后只需要在 kublet 啟動時附帶 --rotate-certificates 選項就會自動重新加載新證書
5.2、證書及配置文件作用
- token.csv
該文件為一個用戶的描述文件，基本格式為 Token,用戶名,UID,用戶組；這個文件在 apiserver 啟動時被 apiserver 加載，然后就相當於在集群內創建了一個這個用戶；接下來就可以用 RBAC 給他授權；持有這個用戶 Token 的組件訪問 apiserver 的時候，apiserver 根據 RBAC 定義的該用戶應當具有的權限來處理相應請求
- bootstarp.kubeconfig
該文件中內置了 token.csv 中用戶的 Token，以及 apiserver CA 證書；kubelet 首次啟動會加載此文件，使用 apiserver CA 證書建立與 apiserver 的 TLS 通訊，使用其中的用戶 Token 作為身份標識像 apiserver 發起 CSR 請求
- 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 端口
- kubelet-server.crt
該文件在 kubelet 完成 TLS bootstrapping 后並且配置了 --feature-gates=RotateKubeletServerCertificate=true 時才會生成；這種情況下該證書由 apiserver CA 簽署，默認有效期同樣是 1 年，被用作 kubelet 10250 api 端口鑒權
- kubelet-client-current.pem
這是一個軟連接文件，當 kubelet 配置了 --feature-gates=RotateKubeletClientCertificate=true 選項后，會在證書總有效期的 70%~90% 的時間內發起續期請求，請求被批准后會生成一個 kubelet-client-時間戳.pem；kubelet-client-current.pem 文件則始終軟連接到最新的真實證書文件，除首次啟動外，kubelet 一直會使用這個證書同 apiserver 通訊
- kubelet-server-current.pem
同樣是一個軟連接文件，當 kubelet 配置了 --feature-gates=RotateKubeletServerCertificate=true 選項后，會在證書總有效期的 70%~90% 的時間內發起續期請求，請求被批准后會生成一個 kubelet-server-時間戳.pem；kubelet-server-current.pem 文件則始終軟連接到最新的真實證書文件，該文件將會一直被用於 kubelet 10250 api 端口鑒權
5.3、1.7 TLS bootstrapping 配置
apiserver 預先放置 token.csv，內容樣例如下
6df3c701f979cee17732c30958745947,kubelet-bootstrap,10001,"system:bootstrappers"
允許 kubelet-bootstrap 用戶創建首次啟動的 CSR 請求
kubectl create clusterrolebinding kubelet-bootstrap \ --clusterrole=system:node-bootstrapper \ --user=kubelet-bootstrap
配置 kubelet 自動續期，RotateKubeletClientCertificate 用於自動續期 kubelet 連接 apiserver 所用的證書(kubelet-client-xxxx.pem)，RotateKubeletServerCertificate 用於自動續期 kubelet 10250 api 端口所使用的證書(kubelet-server-xxxx.pem)
KUBELET_ARGS="--cgroup-driver=cgroupfs \ --cluster-dns=10.254.0.2 \ --resolv-conf=/etc/resolv.conf \ --experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig \ --feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true \ --kubeconfig=/etc/kubernetes/kubelet.kubeconfig \ --fail-swap-on=false \ --cert-dir=/etc/kubernetes/ssl \ --cluster-domain=cluster.local. \ --hairpin-mode=promiscuous-bridge \ --serialize-image-pulls=false \ --pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0"
配置 controller manager 自動批准相關 CSR 請求，如果不配置 --feature-gates=RotateKubeletServerCertificate=true 參數，則即使配置了相關的 RBAC 規則，也只會自動批准 kubelet client 的 renew 請求
KUBE_CONTROLLER_MANAGER_ARGS="--address=0.0.0.0 \ --service-cluster-ip-range=10.254.0.0/16 \ --feature-gates=RotateKubeletServerCertificate=true \ --cluster-name=kubernetes \ --cluster-signing-cert-file=/etc/kubernetes/ssl/k8s-root-ca.pem \ --cluster-signing-key-file=/etc/kubernetes/ssl/k8s-root-ca-key.pem \ --service-account-private-key-file=/etc/kubernetes/ssl/k8s-root-ca-key.pem \ --root-ca-file=/etc/kubernetes/ssl/k8s-root-ca.pem \ --leader-elect=true \ --node-monitor-grace-period=40s \ --node-monitor-period=5s \ --pod-eviction-timeout=5m0s"
創建自動批准相關 CSR 請求的 ClusterRole
# A ClusterRole which instructs the CSR approver to approve a user requesting # node client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: approve-node-client-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/nodeclient"] verbs: ["create"] --- # A ClusterRole which instructs the CSR approver to approve a node renewing its # own client credentials. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: approve-node-client-renewal-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeclient"] verbs: ["create"] --- # A ClusterRole which instructs the CSR approver to approve a node requesting a # serving cert matching its client cert. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: approve-node-server-renewal-csr rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeserver"] verbs: ["create"]
將 ClusterRole 綁定到適當的用戶組，以完成自動批准相關 CSR 請求
# 自動批准 system:bootstrappers 組用戶 TLS bootstrapping 首次申請證書的 CSR 請求 kubectl create clusterrolebinding node-client-auto-approve-csr --clusterrole=approve-node-client-csr --group=system:bootstrappers # 自動批准 system:nodes 組用戶更新 kubelet 自身與 apiserver 通訊證書的 CSR 請求 kubectl create clusterrolebinding node-client-auto-renew-crt --clusterrole=approve-node-client-renewal-csr --group=system:nodes # 自動批准 system:nodes 組用戶更新 kubelet 10250 api 端口證書的 CSR 請求 kubectl create clusterrolebinding node-server-auto-renew-crt --clusterrole=approve-node-server-renewal-csr --group=system:nodes
一切就緒后啟動 kubelet 組件即可，不過需要注意的是 1.7 版本 kubelet 不會自動重載 renew 的證書，需要自己手動重啟
5.4、1.8 TLS bootstrapping 配置
apiserver 預先放置 token.csv，內容樣例如下
6df3c701f979cee17732c30958745947,kubelet-bootstrap,10001,"system:bootstrappers"
允許 kubelet-bootstrap 用戶創建首次啟動的 CSR 請求
kubectl create clusterrolebinding kubelet-bootstrap \ --clusterrole=system:node-bootstrapper \ --user=kubelet-bootstrap
配置 kubelet 自動續期，RotateKubeletClientCertificate 用於自動續期 kubelet 連接 apiserver 所用的證書(kubelet-client-xxxx.pem)，RotateKubeletServerCertificate 用於自動續期 kubelet 10250 api 端口所使用的證書(kubelet-server-xxxx.pem)，--rotate-certificates 選項使得 kubelet 能夠自動重載新證書
KUBELET_ARGS="--cgroup-driver=cgroupfs \ --cluster-dns=10.254.0.2 \ --resolv-conf=/etc/resolv.conf \ --experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig \ --feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true \ --rotate-certificates \ --kubeconfig=/etc/kubernetes/kubelet.kubeconfig \ --fail-swap-on=false \ --cert-dir=/etc/kubernetes/ssl \ --cluster-domain=cluster.local. \ --hairpin-mode=promiscuous-bridge \ --serialize-image-pulls=false \ --pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0"
配置 controller manager 自動批准相關 CSR 請求，如果不配置 --feature-gates=RotateKubeletServerCertificate=true 參數，則即使配置了相關的 RBAC 規則，也只會自動批准 kubelet client 的 renew 請求
KUBE_CONTROLLER_MANAGER_ARGS="--address=0.0.0.0 \ --service-cluster-ip-range=10.254.0.0/16 \ --cluster-name=kubernetes \ --cluster-signing-cert-file=/etc/kubernetes/ssl/k8s-root-ca.pem \ --cluster-signing-key-file=/etc/kubernetes/ssl/k8s-root-ca-key.pem \ --service-account-private-key-file=/etc/kubernetes/ssl/k8s-root-ca-key.pem \ --feature-gates=RotateKubeletServerCertificate=true \ --root-ca-file=/etc/kubernetes/ssl/k8s-root-ca.pem \ --leader-elect=true \ --experimental-cluster-signing-duration 10m0s \ --node-monitor-grace-period=40s \ --node-monitor-period=5s \ --pod-eviction-timeout=5m0s"
創建自動批准相關 CSR 請求的 ClusterRole，相對於 1.7 版本，1.8 的 apiserver 自動創建了前兩條 ClusterRole，所以只需要創建一條就行了
# A ClusterRole which instructs the CSR approver to approve a node requesting a # serving cert matching its client cert. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: system:certificates.k8s.io:certificatesigningrequests:selfnodeserver rules: - apiGroups: ["certificates.k8s.io"] resources: ["certificatesigningrequests/selfnodeserver"] verbs: ["create"]
將 ClusterRole 綁定到適當的用戶組，以完成自動批准相關 CSR 請求
# 自動批准 system:bootstrappers 組用戶 TLS bootstrapping 首次申請證書的 CSR 請求 kubectl create clusterrolebinding node-client-auto-approve-csr --clusterrole=system:certificates.k8s.io:certificatesigningrequests:nodeclient --group=system:bootstrappers # 自動批准 system:nodes 組用戶更新 kubelet 自身與 apiserver 通訊證書的 CSR 請求 kubectl create clusterrolebinding node-client-auto-renew-crt --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeclient --group=system:nodes # 自動批准 system:nodes 組用戶更新 kubelet 10250 api 端口證書的 CSR 請求 kubectl create clusterrolebinding node-server-auto-renew-crt --clusterrole=system:certificates.k8s.io:certificatesigningrequests:selfnodeserver --group=system:nodes
一切就緒后啟動 kubelet 組件即可，1.8 版本 kubelet 會自動重載證書，以下為 1.8 版本在運行一段時間后的相關證書截圖
