使用 kubeadm 進行憑證管理

由 kubeadm 產生的用戶端憑證在 1 年後過期。本頁說明如何使用 kubeadm 管理憑證續訂。它還涵蓋與 kubeadm 憑證管理相關的其他任務。

Kubernetes 專案建議立即升級到最新的修補程式版本，並確保您正在運行 Kubernetes 的受支援次要版本。遵循此建議有助於您保持安全。

開始之前

您應該熟悉 Kubernetes 中的 PKI 憑證和需求。

您應該熟悉如何將組態檔案傳遞給 kubeadm 命令。

本指南涵蓋 openssl 命令的用法（用於手動憑證簽署，如果您選擇該方法），但您可以使用您偏好的工具。

這裡的一些步驟使用 sudo 進行管理員存取。您可以使用任何等效的工具。

使用自訂憑證

預設情況下，kubeadm 會產生叢集運行所需的所有憑證。您可以透過提供自己的憑證來覆寫此行為。

為此，您必須將它們放置在 --cert-dir 標誌或 kubeadm ClusterConfiguration 的 certificatesDir 欄位指定的任何目錄中。預設情況下，這是 /etc/kubernetes/pki。

如果在運行 kubeadm init 之前給定的憑證和私鑰對存在，kubeadm 不會覆寫它們。這表示您可以，例如，將現有的 CA 複製到 /etc/kubernetes/pki/ca.crt 和 /etc/kubernetes/pki/ca.key，而 kubeadm 將使用此 CA 簽署其餘的憑證。

選擇加密演算法

kubeadm 允許您選擇用於建立公開金鑰和私密金鑰的加密演算法。這可以透過使用 kubeadm 組態的 encryptionAlgorithm 欄位來完成

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
encryptionAlgorithm: <ALGORITHM>

<ALGORITHM> 可以是 RSA-2048 (預設值)、RSA-3072、RSA-4096 或 ECDSA-P256 之一。

選擇憑證有效期限

kubeadm 允許您選擇 CA 和葉憑證的有效期限。這可以透過使用 kubeadm 組態的 certificateValidityPeriod 和 caCertificateValidityPeriod 欄位來完成

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
certificateValidityPeriod: 8760h # Default: 365 days × 24 hours = 1 year
caCertificateValidityPeriod: 87600h # Default: 365 days × 24 hours * 10 = 10 years

這些欄位的值遵循 Go 的 time.Duration 值的可接受格式，最長支援的單位為 h（小時）。

外部 CA 模式

也可以僅提供 ca.crt 檔案，而不提供 ca.key 檔案（這僅適用於根 CA 檔案，不適用於其他憑證對）。如果所有其他憑證和 kubeconfig 檔案都已就位，kubeadm 會識別此條件並啟用「外部 CA」模式。 kubeadm 將在沒有磁碟上的 CA 金鑰的情況下繼續進行。

相反地，請使用 --controllers=csrsigner 獨立運行 controller-manager，並指向 CA 憑證和金鑰。

當使用外部 CA 模式時，有多種方法可以準備組件憑證。

手動準備組件憑證

PKI 憑證和需求 包含有關如何手動準備 kubeadm 組件憑證所需的所有資訊。

本指南涵蓋 openssl 命令的用法（用於手動憑證簽署，如果您選擇該方法），但您可以使用您偏好的工具。

透過簽署 kubeadm 產生的 CSR 來準備憑證

kubeadm 可以 產生 CSR 檔案，您可以使用 openssl 和您的外部 CA 等工具手動簽署這些檔案。這些 CSR 檔案將包含 kubeadm 部署的組件所需憑證的所有規格。

透過使用 kubeadm phases 自動準備組件憑證

或者，可以使用 kubeadm phase 命令來自動化此過程。

• 前往您要準備為具有外部 CA 的 kubeadm 控制平面節點的主機。
• 將您擁有的外部 CA 檔案 ca.crt 和 ca.key 複製到節點上的 /etc/kubernetes/pki 中。
• 準備一個臨時的 kubeadm 組態檔案，名為 config.yaml，可用於 kubeadm init。確保此檔案包含任何相關的叢集範圍或主機特定的資訊，這些資訊可能包含在憑證中，例如 ClusterConfiguration.controlPlaneEndpoint、ClusterConfiguration.certSANs 和 InitConfiguration.APIEndpoint。
• 在同一主機上，執行命令 kubeadm init phase kubeconfig all --config config.yaml 和 kubeadm init phase certs all --config config.yaml。這將在 /etc/kubernetes/ 及其 pki 子目錄下產生所有需要的 kubeconfig 檔案和憑證。
• 檢查產生的檔案。刪除 /etc/kubernetes/pki/ca.key，刪除或移動到安全位置檔案 /etc/kubernetes/super-admin.conf。
• 在將調用 kubeadm join 的節點上，也刪除 /etc/kubernetes/kubelet.conf。此檔案僅在將調用 kubeadm init 的第一個節點上是必需的。
• 請注意，某些檔案（例如 pki/sa.*、pki/front-proxy-ca.* 和 pki/etc/ca.*）在控制平面節點之間共用。您可以產生它們一次，然後 手動將它們分發 到將調用 kubeadm join 的節點，或者您可以使用 kubeadm init 的 --upload-certs 功能和 kubeadm join 的 --certificate-key 來自動化此分發。

在所有節點上準備好憑證後，調用 kubeadm init 和 kubeadm join 以使這些節點加入叢集。 kubeadm 將使用 /etc/kubernetes/ 及其 pki 子目錄下的現有 kubeconfig 和憑證檔案。

憑證到期和管理

您可以使用 check-expiration 子命令來檢查憑證何時到期

kubeadm certs check-expiration

輸出類似於此

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no
apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no
apiserver-etcd-client      Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Dec 30, 2020 23:36 UTC   364d            ca                      no
controller-manager.conf    Dec 30, 2020 23:36 UTC   364d                                    no
etcd-healthcheck-client    Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
etcd-peer                  Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
etcd-server                Dec 30, 2020 23:36 UTC   364d            etcd-ca                 no
front-proxy-client         Dec 30, 2020 23:36 UTC   364d            front-proxy-ca          no
scheduler.conf             Dec 30, 2020 23:36 UTC   364d                                    no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Dec 28, 2029 23:36 UTC   9y              no
etcd-ca                 Dec 28, 2029 23:36 UTC   9y              no
front-proxy-ca          Dec 28, 2029 23:36 UTC   9y              no

此命令會顯示 /etc/kubernetes/pki 資料夾中用戶端憑證以及 kubeadm 使用的 kubeconfig 檔案（admin.conf、controller-manager.conf 和 scheduler.conf）中嵌入的用戶端憑證的到期/剩餘時間。

此外，kubeadm 會通知使用者憑證是否為外部管理；在這種情況下，使用者應負責手動或使用其他工具管理憑證續約。

kubelet.conf 設定檔未包含在以上清單中，因為 kubeadm 將 kubelet 設定為使用 /var/lib/kubelet/pki 下的可輪換憑證進行自動憑證續約。若要修復過期的 kubelet 用戶端憑證，請參閱Kubelet 用戶端憑證輪換失敗。

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

自動憑證續約

kubeadm 會在控制平面升級期間續約所有憑證。

此功能旨在解決最簡單的使用案例；如果您對憑證續約沒有特定要求，並且定期執行 Kubernetes 版本升級（每次升級間隔少於 1 年），kubeadm 將負責保持您的叢集為最新狀態並具有合理的安全性。

如果您對憑證續約有更複雜的要求，您可以選擇退出預設行為，方法是將 --certificate-renewal=false 傳遞給 kubeadm upgrade apply 或 kubeadm upgrade node。

手動憑證續約

您可以隨時使用 kubeadm certs renew 命令以及適當的命令列選項手動續約憑證。如果您正在執行具有複寫控制平面的叢集，則需要在所有控制平面節點上執行此命令。

此命令使用儲存在 /etc/kubernetes/pki 中的 CA（或 front-proxy-CA）憑證和金鑰執行續約。

kubeadm certs renew 使用現有憑證作為屬性（通用名稱、組織、主體別名）的權威來源，並且不依賴 kubeadm-config ConfigMap。即便如此，Kubernetes 專案仍建議保持已服務的憑證和該 ConfigMap 中的相關值同步，以避免任何混淆的風險。

執行命令後，您應重新啟動控制平面 Pod。這是必要的，因為目前並非所有元件和憑證都支援動態憑證重新載入。靜態 Pod 由本機 kubelet 管理，而不是由 API Server 管理，因此無法使用 kubectl 來刪除和重新啟動它們。若要重新啟動靜態 Pod，您可以暫時從 /etc/kubernetes/manifests/ 中移除其 manifest 檔案，並等待 20 秒（請參閱 KubeletConfiguration 結構中的 fileCheckFrequency 值）。如果 Pod 不再位於 manifest 目錄中，kubelet 將終止該 Pod。然後您可以將檔案移回，並在另一個 fileCheckFrequency 期間後，kubelet 將重新建立 Pod，並且元件的憑證續約即可完成。

kubeadm certs renew 可以續約任何特定憑證，或者使用子命令 all，它可以續約所有憑證

# If you are running cluster with a replicated control plane, this command
# needs to be executed on all the control-plane nodes.
kubeadm certs renew all

複製管理員憑證（選用）

使用 kubeadm 建置的叢集通常會將 admin.conf 憑證複製到 $HOME/.kube/config 中，如使用 kubeadm 建立叢集中所述。在這樣的系統上，若要在續約 admin.conf 後更新 $HOME/.kube/config 的內容，您可以執行以下命令

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

使用 Kubernetes 憑證 API 續約憑證

本節提供有關如何使用 Kubernetes 憑證 API 執行手動憑證續約的更多詳細資訊。

設定簽署者

Kubernetes 憑證授權單位無法直接運作。您可以設定外部簽署者，例如 cert-manager，或者您可以使用內建簽署者。

內建簽署者是 kube-controller-manager 的一部分。

若要啟用內建簽署者，您必須傳遞 --cluster-signing-cert-file 和 --cluster-signing-key-file 旗標。

如果您要建立新的叢集，則可以使用 kubeadm 設定檔

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
controllerManager:
  extraArgs:
  - name: "cluster-signing-cert-file"
    value: "/etc/kubernetes/pki/ca.crt"
  - name: "cluster-signing-key-file"
    value: "/etc/kubernetes/pki/ca.key"

建立憑證簽署請求 (CSR)

請參閱 建立 CertificateSigningRequest，以瞭解如何使用 Kubernetes API 建立 CSR。

使用外部 CA 續約憑證

本節提供有關如何使用外部 CA 執行手動憑證續約的更多詳細資訊。

為了更好地與外部 CA 整合，kubeadm 也可以產生憑證簽署請求 (CSR)。CSR 代表向 CA 請求用戶端已簽署憑證。在 kubeadm 術語中，通常由磁碟上的 CA 簽署的任何憑證都可以產生為 CSR。但是，CA 無法產生為 CSR。

使用憑證簽署請求 (CSR) 進行續約

可以透過產生新的 CSR 並使用外部 CA 簽署它們來續約憑證。有關使用 kubeadm 產生的 CSR 的更多詳細資訊，請參閱 簽署 kubeadm 產生的憑證簽署請求 (CSR) 章節。

憑證授權單位 (CA) 輪換

kubeadm 不支援直接輪換或替換 CA 憑證。

有關手動輪換或替換 CA 的更多資訊，請參閱 手動輪換 CA 憑證。

啟用已簽署的 kubelet 伺服器憑證

預設情況下，kubeadm 部署的 kubelet 伺服器憑證是自簽署的。這表示來自外部服務（如 metrics-server）到 kubelet 的連線無法使用 TLS 保護。

若要將新 kubeadm 叢集中的 kubelet 設定為取得正確簽署的伺服器憑證，您必須將以下最簡設定傳遞給 kubeadm init

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
serverTLSBootstrap: true

如果您已建立叢集，則必須透過執行以下操作來調整它

• 在 kube-system 命名空間中尋找並編輯 kubelet-config-1.32 ConfigMap。在該 ConfigMap 中，kubelet 金鑰具有 KubeletConfiguration 文件作為其值。編輯 KubeletConfiguration 文件以設定 serverTLSBootstrap: true。
• 在每個節點上，在 /var/lib/kubelet/config.yaml 中新增 serverTLSBootstrap: true 欄位，並使用 systemctl restart kubelet 重新啟動 kubelet

欄位 serverTLSBootstrap: true 將透過從 certificates.k8s.io API 請求憑證來啟用 kubelet 伺服器憑證的引導程序。一個已知的限制是，這些憑證的 CSR（憑證簽署請求）無法由 kube-controller-manager 中的預設簽署者自動核准 - kubernetes.io/kubelet-serving。這將需要使用者或第三方控制器採取行動。

可以使用以下命令檢視這些 CSR

kubectl get csr

NAME        AGE     SIGNERNAME                        REQUESTOR                      CONDITION
csr-9wvgt   112s    kubernetes.io/kubelet-serving     system:node:worker-1           Pending
csr-lz97v   1m58s   kubernetes.io/kubelet-serving     system:node:control-plane-1    Pending

若要核准它們，您可以執行以下操作

kubectl certificate approve <CSR-name>

預設情況下，這些伺服器憑證將在一年後到期。Kubeadm 將 KubeletConfiguration 欄位 rotateCertificates 設定為 true，這表示在接近到期時，將會建立一組新的伺服器憑證 CSR，並且必須核准這些 CSR 才能完成輪換。若要瞭解更多資訊，請參閱 憑證輪換。

如果您正在尋找自動核准這些 CSR 的解決方案，建議您聯絡您的雲端供應商，詢問他們是否有 CSR 簽署者，可以使用頻外機制驗證節點身分。

可以使用第三方自訂控制器

• kubelet-csr-approver

除非此類控制器不僅驗證 CSR 中的 CommonName，而且還驗證請求的 IP 和網域名稱，否則它不是安全的機制。這將防止惡意行為者存取 kubelet 用戶端憑證，以建立 CSR 來請求任何 IP 或網域名稱的伺服器憑證。

為其他使用者產生 kubeconfig 檔案

在叢集建立期間，kubeadm init 會簽署 super-admin.conf 中的憑證，使其具有 Subject: O = system:masters, CN = kubernetes-super-admin。system:masters 是一個緊急情況時使用的超級使用者群組，它會繞過授權層（例如，RBAC）。檔案 admin.conf 也由控制平面節點上的 kubeadm 建立，它包含一個憑證，其 Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin。kubeadm:cluster-admins 是一個邏輯上屬於 kubeadm 的群組。如果您的叢集使用 RBAC（kubeadm 預設值），則 kubeadm:cluster-admins 群組會繫結到 cluster-admin ClusterRole。

您可以使用 kubeadm kubeconfig user 命令為其他使用者產生 kubeconfig 檔案。該命令接受命令列旗標和 kubeadm 設定 選項的組合。產生的 kubeconfig 將寫入 stdout，並且可以使用 kubeadm kubeconfig user ... > somefile.conf 管道傳輸到檔案。

可以與 --config 一起使用的範例設定檔

# example.yaml
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
# Will be used as the target "cluster" in the kubeconfig
clusterName: "kubernetes"
# Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig
controlPlaneEndpoint: "some-dns-address:6443"
# The cluster CA key and certificate will be loaded from this local directory
certificatesDir: "/etc/kubernetes/pki"

請確保這些設定與所需的目標叢集設定相符。若要查看現有叢集的設定，請使用

kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}"

以下範例將為新使用者 johndoe 產生一個 kubeconfig 檔案，其憑證在 24 小時內有效，並且屬於 appdevs 群組

kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h

以下範例將產生一個具有管理員憑證的 kubeconfig 檔案，其憑證在 1 週內有效

kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h

簽署 kubeadm 產生的憑證簽署請求 (CSR)

您可以使用 kubeadm certs generate-csr 建立憑證簽署請求。呼叫此命令將為常規憑證產生 .csr / .key 檔案對。對於嵌入在 kubeconfig 檔案中的憑證，該命令將產生一個 .csr / .conf 對，其中金鑰已嵌入在 .conf 檔案中。

CSR 檔案包含 CA 簽署憑證的所有相關資訊。kubeadm 對其所有憑證和 CSR 使用 明確定義的規範。

預設憑證目錄為 /etc/kubernetes/pki，而 kubeconfig 檔案的預設目錄為 /etc/kubernetes。這些預設值可以分別使用旗標 --cert-dir 和 --kubeconfig-dir 覆寫。

若要將自訂選項傳遞給 kubeadm certs generate-csr，請使用 --config 旗標，該旗標接受 kubeadm 設定 檔案，類似於 kubeadm init 等命令。任何規範（例如額外的 SAN 和自訂 IP 位址）都必須儲存在同一個設定檔中，並透過將其作為 --config 傳遞來用於所有相關的 kubeadm 命令。

準備 CA 和服務帳戶檔案

在將執行 kubeadm init 的主要控制平面節點上，呼叫以下命令

sudo kubeadm init phase certs ca
sudo kubeadm init phase certs etcd-ca
sudo kubeadm init phase certs front-proxy-ca
sudo kubeadm init phase certs sa

這將使用 kubeadm 控制平面節點所需的所有自簽署 CA 檔案（憑證和金鑰）和服務帳戶（公鑰和私鑰）來填充 /etc/kubernetes/pki 和 /etc/kubernetes/pki/etcd 資料夾。

對於次要控制平面節點 (kubeadm join --control-plane)，無需呼叫上述命令。根據您設定 高可用性 叢集的方式，您必須手動從主要控制平面節點複製相同的檔案，或使用 kubeadm init 的自動 --upload-certs 功能。

產生 CSR

kubeadm certs generate-csr 命令會為 kubeadm 管理的所有已知憑證產生 CSR。命令完成後，您必須手動刪除不需要的 .csr、.conf 或 .key 檔案。

kubelet.conf 的考量事項

本節適用於控制平面和工作節點。

如果您已從控制平面節點刪除 ca.key 檔案（外部 CA 模式），則此叢集中的活動 kube-controller-manager 將無法簽署 kubelet 用戶端憑證。如果您的設定中不存在用於簽署這些憑證的外部方法（例如 外部簽署者），您可以手動簽署 kubelet.conf.csr，如本指南中所述。

請注意，這也表示自動kubelet 用戶端憑證輪換將被停用。如果這樣，在憑證接近到期時，您必須產生新的 kubelet.conf.csr，簽署憑證，將其嵌入到 kubelet.conf 中，然後重新啟動 kubelet。

如果這不適用於您的設定，您可以跳過處理次要控制平面和工作節點（所有呼叫 kubeadm join ... 的節點）上的 kubelet.conf.csr。這是因為活動 kube-controller-manager 將負責簽署新的 kubelet 用戶端憑證。

控制平面節點

在主要 (kubeadm init) 和次要 (kubeadm join --control-plane) 控制平面節點上執行以下命令，以產生所有 CSR 檔案

sudo kubeadm certs generate-csr

如果要使用外部 etcd，請依照使用 kubeadm 部署外部 etcd指南，以瞭解在 kubeadm 和 etcd 節點上需要哪些 CSR 檔案。可以移除 /etc/kubernetes/pki/etcd 下的其他 .csr 和 .key 檔案。

根據kubelet.conf 的考量中的說明，保留或刪除 kubelet.conf 和 kubelet.conf.csr 檔案。

Worker 節點

根據kubelet.conf 的考量中的說明，選擇性地呼叫

sudo kubeadm certs generate-csr

並僅保留 kubelet.conf 和 kubelet.conf.csr 檔案。或者，完全跳過 worker 節點的步驟。

為所有憑證簽署 CSR

針對所有具有 CSR 檔案的節點重複此步驟。

在 /etc/kubernetes 目錄中寫入以下腳本，導覽至該目錄並執行腳本。該腳本將為 /etc/kubernetes 樹狀目錄中存在的所有 CSR 檔案產生憑證。

#!/bin/bash

# Set certificate expiration time in days
DAYS=365

# Process all CSR files except those for front-proxy and etcd
find ./ -name "*.csr" | grep -v "pki/etcd" | grep -v "front-proxy" | while read -r FILE;
do
    echo "* Processing ${FILE} ..."
    FILE=${FILE%.*} # Trim the extension
    if [ -f "./pki/ca.srl" ]; then
        SERIAL_FLAG="-CAserial ./pki/ca.srl"
    else
        SERIAL_FLAG="-CAcreateserial"
    fi
    openssl x509 -req -days "${DAYS}" -CA ./pki/ca.crt -CAkey ./pki/ca.key ${SERIAL_FLAG} \
        -in "${FILE}.csr" -out "${FILE}.crt"
    sleep 2
done

# Process all etcd CSRs
find ./pki/etcd -name "*.csr" | while read -r FILE;
do
    echo "* Processing ${FILE} ..."
    FILE=${FILE%.*} # Trim the extension
    if [ -f "./pki/etcd/ca.srl" ]; then
        SERIAL_FLAG=-CAserial ./pki/etcd/ca.srl
    else
        SERIAL_FLAG=-CAcreateserial
    fi
    openssl x509 -req -days "${DAYS}" -CA ./pki/etcd/ca.crt -CAkey ./pki/etcd/ca.key ${SERIAL_FLAG} \
        -in "${FILE}.csr" -out "${FILE}.crt"
done

# Process front-proxy CSRs
echo "* Processing ./pki/front-proxy-client.csr ..."
openssl x509 -req -days "${DAYS}" -CA ./pki/front-proxy-ca.crt -CAkey ./pki/front-proxy-ca.key -CAcreateserial \
    -in ./pki/front-proxy-client.csr -out ./pki/front-proxy-client.crt

將憑證嵌入到 kubeconfig 檔案中

針對所有具有 CSR 檔案的節點重複此步驟。

在 /etc/kubernetes 目錄中寫入以下腳本，導覽至該目錄並執行腳本。該腳本將取得在上一步中為 kubeconfig 檔案從 CSR 簽署的 .crt 檔案，並將它們嵌入到 kubeconfig 檔案中。

#!/bin/bash

CLUSTER=kubernetes
find ./ -name "*.conf" | while read -r FILE;
do
    echo "* Processing ${FILE} ..."
    KUBECONFIG="${FILE}" kubectl config set-cluster "${CLUSTER}" --certificate-authority ./pki/ca.crt --embed-certs
    USER=$(KUBECONFIG="${FILE}" kubectl config view -o jsonpath='{.users[0].name}')
    KUBECONFIG="${FILE}" kubectl config set-credentials "${USER}" --client-certificate "${FILE}.crt" --embed-certs
done

執行清理

在所有具有 CSR 檔案的節點上執行此步驟。

在 /etc/kubernetes 目錄中寫入以下腳本，導覽至該目錄並執行腳本。

#!/bin/bash

# Cleanup CSR files
rm -f ./*.csr ./pki/*.csr ./pki/etcd/*.csr # Clean all CSR files

# Cleanup CRT files that were already embedded in kubeconfig files
rm -f ./*.crt

（可選）將 .srl 檔案移動到下一個要處理的節點。

（可選）如果使用外部 CA，請移除 /etc/kubernetes/pki/ca.key 檔案，如外部 CA 節點章節中所述。

kubeadm 節點初始化

一旦 CSR 檔案已簽署，且所需的憑證已放置在您要用作節點的主機上，您就可以使用 kubeadm init 和 kubeadm join 命令從這些節點建立 Kubernetes 叢集。在 init 和 join 期間，kubeadm 會使用在主機本機檔案系統的 /etc/kubernetes 樹狀目錄中找到的現有憑證、加密金鑰和 kubeconfig 檔案。