kubeadm join

此指令會初始化新的 Kubernetes 節點，並將其加入現有的叢集。

在您想要加入現有叢集的任何機器上執行此指令

概要

當加入 kubeadm 初始化的叢集時，我們需要建立雙向信任。這分為探索 (讓節點信任 Kubernetes 控制平面) 和 TLS 啟動引導 (讓 Kubernetes 控制平面信任節點)。

探索有 2 種主要方案。第一種是使用共用權杖以及 API 伺服器的 IP 位址。第二種是提供檔案 - 標準 kubeconfig 檔案的子集。探索/kubeconfig 檔案支援權杖、client-go 驗證外掛程式 ("exec")、"tokenFile" 和 "authProvider"。此檔案可以是本機檔案，也可以透過 HTTPS URL 下載。格式為 kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443、kubeadm join --discovery-file path/to/file.conf 或 kubeadm join --discovery-file https://url/file.conf。只能使用一種格式。如果探索資訊是從 URL 載入的，則必須使用 HTTPS。此外，在這種情況下，主機安裝的 CA 憑證組合會用於驗證連線。

如果您使用共用權杖進行探索，您也應該傳遞 --discovery-token-ca-cert-hash 旗標，以驗證 Kubernetes 控制平面提供的根憑證授權單位 (CA) 的公開金鑰。此旗標的值指定為 "<雜湊類型>:<十六進位編碼值>"，其中支援的雜湊類型為 "sha256"。雜湊是針對主體公開金鑰資訊 (SPKI) 物件的位元組計算的 (如 RFC7469 中所述)。此值可在 "kubeadm init" 的輸出中取得，或可以使用標準工具計算。--discovery-token-ca-cert-hash 旗標可以重複多次，以允許多個公開金鑰。

如果您無法預先知道 CA 公開金鑰雜湊，您可以傳遞 --discovery-token-unsafe-skip-ca-verification 旗標來停用此驗證。這會削弱 kubeadm 安全模型，因為其他節點可能會模擬 Kubernetes 控制平面。

TLS 啟動引導機制也是透過共用權杖驅動的。這用於暫時使用 Kubernetes 控制平面進行驗證，以提交本機建立的金鑰組的憑證簽署請求 (CSR)。依預設，kubeadm 將設定 Kubernetes 控制平面以自動核准這些簽署請求。此權杖會透過 --tls-bootstrap-token abcdef.1234567890abcdef 旗標傳遞。

通常，相同的權杖用於這兩個部分。在這種情況下，可以使用 --token 旗標，而不是單獨指定每個權杖。

"join [api-server-endpoint]" 指令會執行以下階段

preflight              Run join pre-flight checks
control-plane-prepare  Prepare the machine for serving a control plane
  /download-certs        Download certificates shared among control-plane nodes from the kubeadm-certs Secret
  /certs                 Generate the certificates for the new control plane components
  /kubeconfig            Generate the kubeconfig for the new control plane components
  /control-plane         Generate the manifests for the new control plane components
kubelet-start          Write kubelet settings, certificates and (re)start the kubelet
control-plane-join     Join a machine as a control plane instance
  /etcd                  Add a new local etcd member
  /mark-control-plane    Mark a node as a control-plane
wait-control-plane     EXPERIMENTAL: Wait for the control plane to start

kubeadm join [api-server-endpoint] [flags]

選項

從父指令繼承的選項

加入工作流程

kubeadm join 啟動 Kubernetes 工作節點或控制平面節點，並將其新增至叢集。此動作包含工作節點的以下步驟

1. kubeadm 從 API 伺服器下載必要的叢集資訊。預設情況下，它使用啟動令牌和 CA 金鑰雜湊來驗證該資料的真實性。根 CA 也可以透過檔案或 URL 直接探索。

2. 一旦叢集資訊已知，kubelet 就可以啟動 TLS 啟動程序。

   TLS 啟動使用共用令牌臨時向 Kubernetes API 伺服器驗證身分，以提交憑證簽署請求 (CSR)；預設情況下，控制平面會自動簽署此 CSR 請求。

3. 最後，kubeadm 設定本機 kubelet 以使用指派給節點的明確身分連接到 API 伺服器。

對於控制平面節點，會執行其他步驟

1. 從叢集下載控制平面節點之間共用的憑證 (如果使用者明確要求)。

2. 產生控制平面組件資訊清單、憑證和 kubeconfig。

3. 新增新的本機 etcd 成員。

使用 kubeadm 的加入階段

Kubeadm 允許您使用 kubeadm join phase 以階段方式將節點加入叢集。

若要檢視階段和子階段的排序清單，您可以呼叫 kubeadm join --help。清單將位於說明畫面的頂端，每個階段旁邊都會有說明。請注意，透過呼叫 kubeadm join，所有階段和子階段都將以完全相同的順序執行。

某些階段具有獨特的旗標，因此如果您想查看可用選項的清單，請新增 `--help`，例如

kubeadm join phase kubelet-start --help

類似於 kubeadm init phase 指令，kubeadm join phase 允許您使用 `--skip-phases` 旗標跳過階段清單。

例如

sudo kubeadm join --skip-phases=preflight --config=config.yaml

或者，您可以使用 `JoinConfiguration` 中的 `skipPhases` 欄位。

探索要信任哪個叢集 CA

kubeadm 探索有幾個選項，每個選項都有安全性權衡。適用於您環境的正確方法取決於您如何佈建節點以及您對網路和節點生命週期的安全性期望。

基於令牌的探索與 CA 釘選

這是 kubeadm 中的預設模式。在此模式下，kubeadm 下載叢集組態 (包括根 CA)，並使用令牌驗證它，以及驗證根 CA 公鑰是否與提供的雜湊值相符，以及 API 伺服器憑證在根 CA 下是否有效。

CA 金鑰雜湊值的格式為 `sha256:<hex_encoded_hash>`。預設情況下，雜湊值會印在 `kubeadm init` 指令的結尾或 `kubeadm token create --print-join-command` 指令的輸出中。它採用標準格式 (請參閱 RFC7469)，也可以由第三方工具或佈建系統計算。例如，使用 OpenSSL CLI

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

`kubeadm join` 指令範例

適用於工作節點

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

適用於控制平面節點

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443

如果 `kubeadm init` 指令是使用 `--upload-certs` 呼叫的，您也可以使用 `--certificate-key` 為控制平面節點呼叫 `join`，以將憑證複製到此節點。

優點

• 即使其他工作節點或網路遭到入侵，也允許啟動節點安全地探索控制平面節點的信任根。

• 方便手動執行，因為所有需要的資訊都適合單一 `kubeadm join` 指令。

缺點

• CA 雜湊值通常在控制平面節點佈建完成後才會知道，這可能會使建置使用 kubeadm 的自動化佈建工具變得更加困難。透過預先產生您的 CA，您可以規避此限制。

基於令牌的探索，不使用 CA 釘選

此模式僅依賴對稱令牌來簽署 (HMAC-SHA256) 探索資訊，該資訊建立控制平面的信任根。若要使用此模式，加入節點必須跳過 CA 公鑰的雜湊驗證，方法是使用 `--discovery-token-unsafe-skip-ca-verification`。如果可能，您應該考慮使用其他模式之一。

`kubeadm join` 指令範例

kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443

優點

• 仍然可以防禦許多網路層級的攻擊。

• 令牌可以預先產生，並與控制平面節點和工作節點共用，然後它們可以平行啟動而無需協調。這使其可以用於許多佈建情境。

缺點

• 如果攻擊者能夠透過某些漏洞竊取啟動令牌，他們可以使用該令牌 (以及網路層級的存取權) 來模擬控制平面節點給其他啟動節點。這在您的環境中可能是或可能不是適當的權衡。

基於檔案或 HTTPS 的探索

這提供了一種帶外方式，用於在控制平面節點和啟動節點之間建立信任根。如果您使用 kubeadm 建置自動化佈建，請考慮使用此模式。探索檔案的格式是常規 Kubernetes kubeconfig 檔案。

如果探索檔案不包含憑證，將會使用 TLS 探索令牌。

`kubeadm join` 指令範例

• kubeadm join --discovery-file path/to/file.conf (本機檔案)

• kubeadm join --discovery-file https://url/file.conf (遠端 HTTPS URL)

優點

• 即使網路或其他工作節點遭到入侵，也允許啟動節點安全地探索控制平面節點的信任根。

缺點

• 要求您必須有某種方式將探索資訊從控制平面節點傳輸到啟動節點。如果探索檔案包含憑證，您必須對其保密並透過安全通道傳輸。這可能透過您的雲端供應商或佈建工具實現。

使用 `kubeadm join` 的自訂 kubelet 憑證

為了允許 `kubeadm join` 使用預定義的 kubelet 憑證，並跳過新節點的用戶端 TLS 啟動和 CSR 核准

1. 從叢集中具有 `/etc/kubernetes/pki/ca.key` 的工作控制平面節點執行 kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf。`$NODE` 必須設定為新節點的名稱。
2. 手動修改產生的 `kubelet.conf` 以調整叢集名稱和伺服器端點，或執行 kubeadm kubeconfig user --config (它接受 `InitConfiguration`)。

如果您的叢集沒有 `ca.key` 檔案，您必須在外部簽署 `kubelet.conf` 中的內嵌憑證。如需更多資訊，請參閱 PKI 憑證和需求 和 使用 kubeadm 進行憑證管理。

1. 將產生的 `kubelet.conf` 複製到新節點上的 `/etc/kubernetes/kubelet.conf`。
2. 在新節點上執行 `kubeadm join`，並帶有旗標 `--ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf`。

更進一步保護您的安裝

kubeadm 的預設值可能不適用於所有人。本節說明如何在犧牲一些可用性的情況下，加強 kubeadm 安裝的安全性。

關閉節點用戶端憑證的自動核准

預設情況下，啟用了 CSR 自動核准程式，當在驗證身分時使用啟動令牌時，它基本上會核准 kubelet 的任何用戶端憑證請求。如果您不希望叢集自動核准 kubelet 用戶端憑證，您可以透過執行此指令來關閉它

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

在那之後，`kubeadm join` 將會封鎖，直到管理員手動核准正在進行中的 CSR 為止

1. 使用 `kubectl get csr`，您可以看到原始 CSR 處於 Pending 狀態。

   kubectl get csr
   

   輸出類似於此

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending
   

2. kubectl certificate approve 允許管理員核准 CSR。此動作會告知憑證簽署控制器向請求者頒發憑證，其中包含 CSR 中請求的屬性。

   kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
   

   輸出類似於此

   certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
   

3. 這會將 CRS 資源變更為 Active 狀態。

   kubectl get csr
   

   輸出類似於此

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
   

這會強制執行工作流程，即只有在執行 `kubectl certificate approve` 後，`kubeadm join` 才會成功。

關閉對 `cluster-info` ConfigMap 的公開存取

為了使用令牌作為唯一的驗證資訊來實現加入流程，預設情況下會公開 ConfigMap，其中包含驗證控制平面節點身分所需的一些資料。雖然此 ConfigMap 中沒有私有資料，但有些使用者可能希望無論如何都將其關閉。這樣做將會停用使用 `kubeadm join` 流程的 `--discovery-token` 旗標的功能。以下是執行步驟

• 從 API 伺服器擷取 `cluster-info` 檔案

kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml

輸出類似於此

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <ca-cert>
    server: https://<ip>:<port>
  name: ""
contexts: []
current-context: ""
preferences: {}
users: []

• 使用 `cluster-info.yaml` 檔案作為 `kubeadm join --discovery-file` 的引數。

• 關閉對 `cluster-info` ConfigMap 的公開存取

kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo

這些指令應在 `kubeadm init` 之後但在 `kubeadm join` 之前執行。

使用組態檔案執行 kubeadm join

可以使用組態檔案而非命令列旗標來設定 `kubeadm join`，並且某些更進階的功能可能僅以組態檔案選項的形式提供。此檔案是使用 `--config` 旗標傳遞的，並且必須包含 `JoinConfiguration` 結構。在某些情況下，可能不允許將 `--config` 與其他旗標混合使用。

可以使用 kubeadm config print 指令印出預設組態。

如果您的組態未使用最新版本，**建議** 您使用 kubeadm config migrate 指令進行移轉。

如需有關組態的欄位和用法的更多資訊，您可以瀏覽我們的 API 參考文件。

接下來是什麼

• kubeadm init 以啟動 Kubernetes 控制平面節點。
• kubeadm token 以管理 `kubeadm join` 的令牌。
• kubeadm reset 以還原 `kubeadm init` 或 `kubeadm join` 對此主機所做的任何變更。