kubeadm join

此命令初始化一個新 Kubernetes 節點並將其加入現有叢集。

在任何您希望加入現有叢集的機器上執行此命令。

Synopsis

當加入一個由 kubeadm 初始化過的叢集時，我們需要建立雙向信任。這分為發現（讓節點信任 Kubernetes 控制平面）和 TLS 引導（讓 Kubernetes 控制平面信任節點）。

有兩種主要的發現方案。第一種是使用共享令牌和 API 伺服器的 IP 地址。第二種是提供一個檔案——這是標準 kubeconfig 檔案的一個子集。發現/kubeconfig 檔案支援 token、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) 的公鑰。此標誌的值指定為“<hash-type>:<hex-encoded-value>”，其中支援的雜湊型別是“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` 標誌傳遞。

通常，發現和 TLS 引導使用相同的令牌。在這種情況下，可以使用 `--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     Wait for the control plane to start

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

Options

從父命令繼承的選項

join 的工作流程

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 的 join 階段

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

您也可以使用 --certificate-key 呼叫 join 來為一個控制平面節點複製證書，前提是 kubeadm init 命令是用 --upload-certs 呼叫的。

優點

• 即使網路或其他工作節點受到損害，也允許引導節點安全地發現控制平面節點的信任根。

• 易於手動執行，因為所需的所有資訊都包含在單個 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. 在新節點上使用 --ignore-preflight-errors=FileAvailable--etc-kubernetes-kubelet.conf 標誌執行 kubeadm join。

進一步加強安裝安全性

kubeadm 的預設設定可能不適用於所有人。本節介紹瞭如何在犧牲部分易用性的情況下收緊 kubeadm 安裝。

關閉節點客戶端證書的自動批准

預設情況下，啟用了 CSR 自動批准器，它會批准在使用 Bootstrap Token 進行身份驗證時為 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. 這將把 CSR 資源更改為 Active 狀態。

   kubectl get csr
   

   輸出類似於：

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

這強制執行了工作流程，即 kubeadm join 僅在已執行 kubectl certificate approve 後才能成功。

關閉對 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 對此主機所做的任何更改。