kubeadm init

此指令會初始化 Kubernetes 控制平面節點。

執行此指令以設定 Kubernetes 控制平面

概要

執行此指令以設定 Kubernetes 控制平面

「init」指令執行以下階段

preflight                     Run pre-flight checks
certs                         Certificate generation
  /ca                           Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components
  /apiserver                    Generate the certificate for serving the Kubernetes API
  /apiserver-kubelet-client     Generate the certificate for the API server to connect to kubelet
  /front-proxy-ca               Generate the self-signed CA to provision identities for front proxy
  /front-proxy-client           Generate the certificate for the front proxy client
  /etcd-ca                      Generate the self-signed CA to provision identities for etcd
  /etcd-server                  Generate the certificate for serving etcd
  /etcd-peer                    Generate the certificate for etcd nodes to communicate with each other
  /etcd-healthcheck-client      Generate the certificate for liveness probes to healthcheck etcd
  /apiserver-etcd-client        Generate the certificate the apiserver uses to access etcd
  /sa                           Generate a private key for signing service account tokens along with its public key
kubeconfig                    Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file
  /admin                        Generate a kubeconfig file for the admin to use and for kubeadm itself
  /super-admin                  Generate a kubeconfig file for the super-admin
  /kubelet                      Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes
  /controller-manager           Generate a kubeconfig file for the controller manager to use
  /scheduler                    Generate a kubeconfig file for the scheduler to use
etcd                          Generate static Pod manifest file for local etcd
  /local                        Generate the static Pod manifest file for a local, single-node local etcd instance
control-plane                 Generate all static Pod manifest files necessary to establish the control plane
  /apiserver                    Generates the kube-apiserver static Pod manifest
  /controller-manager           Generates the kube-controller-manager static Pod manifest
  /scheduler                    Generates the kube-scheduler static Pod manifest
kubelet-start                 Write kubelet settings and (re)start the kubelet
upload-config                 Upload the kubeadm and kubelet configuration to a ConfigMap
  /kubeadm                      Upload the kubeadm ClusterConfiguration to a ConfigMap
  /kubelet                      Upload the kubelet component config to a ConfigMap
upload-certs                  Upload certificates to kubeadm-certs
mark-control-plane            Mark a node as a control-plane
bootstrap-token               Generates bootstrap tokens used to join a node to a cluster
kubelet-finalize              Updates settings relevant to the kubelet after TLS bootstrap
  /enable-client-cert-rotation  Enable kubelet client certificate rotation
addon                         Install required addons for passing conformance tests
  /coredns                      Install the CoreDNS addon to a Kubernetes cluster
  /kube-proxy                   Install the kube-proxy addon to a Kubernetes cluster
show-join-command             Show the join command for control-plane and worker node

kubeadm init [flags]

選項

從父命令繼承的選項

初始化工作流程

kubeadm init 透過執行以下步驟來引導啟動 Kubernetes 控制平面節點

1. 執行一系列預檢以在進行變更之前驗證系統狀態。某些檢查只會觸發警告，其他檢查則被視為錯誤，並且會退出 kubeadm，直到問題被修正，或者使用者指定 --ignore-preflight-errors=<list-of-errors>。

2. 產生自我簽署的 CA，以設定叢集中每個元件的身分。使用者可以透過將自己的 CA 憑證和/或金鑰放入透過 --cert-dir (預設為 /etc/kubernetes/pki) 配置的憑證目錄中來提供。API 伺服器憑證將針對任何 --apiserver-cert-extra-sans 引數具有額外的 SAN 條目，必要時會轉換為小寫。

3. 在 /etc/kubernetes/ 中為 kubelet、controller-manager 和 scheduler 寫入 kubeconfig 檔案，以連接到 API 伺服器，每個檔案都有自己的身分。此外，還寫入了額外的 kubeconfig 檔案，用於作為管理實體的 kubeadm (admin.conf) 以及可以繞過 RBAC 的超級管理員使用者 (super-admin.conf)。

4. 為 API 伺服器、controller-manager 和 scheduler 產生靜態 Pod 清單。如果未提供外部 etcd，則會為 etcd 產生額外的靜態 Pod 清單。

   靜態 Pod 清單會寫入到 /etc/kubernetes/manifests；kubelet 監控此目錄以在啟動時建立 Pod。

   一旦控制平面 Pod 啟動並執行，kubeadm init 序列就可以繼續。

5. 將標籤和污點套用到控制平面節點，以便不會在那裡執行額外的工作負載。

6. 產生額外節點可用於向未來控制平面註冊自己的權杖。或者，使用者可以透過 --token 提供權杖，如 kubeadm token 文件中所述。

7. 進行所有必要的配置，以允許節點透過 Bootstrap Tokens 和 TLS Bootstrap 機制加入

   • 寫入 ConfigMap，以提供加入所需的所有資訊，並設定相關的 RBAC 存取規則。

   • 讓 Bootstrap Tokens 存取 CSR 簽署 API。

   • 為新的 CSR 請求配置自動批准。

   有關其他資訊，請參閱 kubeadm join。

8. 透過 API 伺服器安裝 DNS 伺服器 (CoreDNS) 和 kube-proxy 附加元件。在 Kubernetes 1.11 及更高版本中，CoreDNS 是預設的 DNS 伺服器。請注意，即使已部署 DNS 伺服器，在安裝 CNI 之前，它也不會被排程。

   警告

   自 v1.18 起，kube-dns 與 kubeadm 的使用已被棄用，並在 v1.21 中移除。

將初始化階段與 kubeadm 一起使用

kubeadm 允許您使用 kubeadm init phase 命令分階段建立控制平面節點。

要查看階段和子階段的排序列表，您可以呼叫 kubeadm init --help。該列表將位於說明畫面的頂部，每個階段旁邊都會有說明。請注意，透過呼叫 kubeadm init，所有階段和子階段都將按照此確切順序執行。

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

sudo kubeadm init phase control-plane controller-manager --help

您也可以使用 --help 來查看特定父階段的子階段列表

sudo kubeadm init phase control-plane --help

kubeadm init 還公開了一個名為 --skip-phases 的標誌，可用於略過某些階段。該標誌接受階段名稱列表，名稱可以從上面的排序列表中取得。

範例

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# you can now modify the control plane and etcd manifest files
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

此範例將根據 configfile.yaml 中的配置，將控制平面和 etcd 的清單檔案寫入到 /etc/kubernetes/manifests 中。這允許您修改檔案，然後使用 --skip-phases 略過這些階段。透過呼叫最後一個命令，您將使用自訂的清單檔案建立控制平面節點。

或者，您可以使用 InitConfiguration 下的 skipPhases 欄位。

將 kubeadm init 與組態檔一起使用

可以使用組態檔而不是命令列標誌來配置 kubeadm init，並且某些更進階的功能可能僅作為組態檔選項提供。此檔案使用 --config 標誌傳遞，並且必須包含 ClusterConfiguration 結構，以及可選的更多以 ---\n 分隔的結構。在某些情況下，可能不允許將 --config 與其他標誌混合使用。

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

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

有關組態的欄位和使用方式的更多資訊，您可以導覽至我們的 API 參考頁面。

將 kubeadm init 與功能閘道一起使用

kubeadm 支援一組 kubeadm 特有的功能閘道，並且只能在使用 kubeadm init 建立叢集期間套用。這些功能可以控制叢集的行為。功能閘道會在功能升級到 GA 後移除。

要傳遞功能閘道，您可以對 kubeadm init 使用 --feature-gates 標誌，或者在您使用 --config 傳遞 組態檔 時，將項目新增到 featureGates 欄位中。

不支援直接將 核心 Kubernetes 元件的功能閘道 傳遞給 kubeadm。相反地，可以透過 使用 kubeadm API 自訂元件 來傳遞它們。

功能閘道列表

功能閘道說明

ControlPlaneKubeletLocalMode

啟用此功能閘道後，當加入新的控制平面節點時，kubeadm 將配置 kubelet 連接到本機 kube-apiserver。這確保在滾動升級期間不會違反版本偏差策略。

EtcdLearnerMode

啟用此功能閘道後，當加入新的控制平面節點時，新的 etcd 成員將建立為學習者，並且僅在 etcd 資料完全對齊後才會升級為投票成員。

NodeLocalCRISocket

啟用此功能閘道後，kubeadm 將從檔案 /var/lib/kubelet/instance-config.yaml 讀取/寫入每個節點的 CRI socket，而不是從節點物件上的註釋 kubeadm.alpha.kubernetes.io/cri-socket 讀取/寫入。新的檔案會作為實例配置修補程式套用，在套用任何其他使用者管理的修補程式之前 (當使用 --patches 標誌時)。它包含來自 KubeletConfiguration 檔案格式 的單一欄位 containerRuntimeEndpoint。如果在升級期間啟用功能閘道，但檔案 /var/lib/kubelet/instance-config.yaml 尚不存在，kubeadm 將嘗試從檔案 /var/lib/kubelet/kubeadm-flags.env 讀取 CRI socket 值。

WaitForAllControlPlaneComponents

啟用此功能閘道後，kubeadm 將等待控制平面節點上的所有控制平面元件 (kube-apiserver、kube-controller-manager、kube-scheduler) 在其 /livez 或 /healthz 端點上報告狀態 200。這些檢查在 https://ADDRESS:PORT/ENDPOINT 上執行。

• PORT 取自元件的 --secure-port。
• ADDRESS 對於 kube-apiserver 是 --advertise-address，對於 kube-controller-manager 和 kube-scheduler 是 --bind-address。
• ENDPOINT 僅對 kube-controller-manager 為 /healthz，直到它也支援 /livez 為止。

如果您在 kubeadm 組態中指定自訂的 ADDRESS 或 PORT，它們將會被採用。在未啟用功能閘道的情況下，kubeadm 將僅等待控制平面節點上的 kube-apiserver 準備就緒。等待過程在主機上的 kubelet 由 kubeadm 啟動後立即開始。建議您啟用此功能閘道，以觀察在 kubeadm init 或 kubeadm join 命令執行期間所有控制平面元件的就緒狀態。

已棄用的功能閘道列表

功能閘道說明

PublicKeysECDSA

可用於建立使用 ECDSA 憑證而不是預設 RSA 演算法的叢集。使用 kubeadm certs renew 也支援續訂現有的 ECDSA 憑證，但是您無法動態或在升級期間在 RSA 和 ECDSA 演算法之間切換。v1.31 之前的 Kubernetes 版本存在一個錯誤，即使您啟用了 PublicKeysECDSA 功能閘道，產生的 kubeconfig 檔案中的金鑰仍設定為使用 RSA。此功能閘道已被棄用，以支持 kubeadm v1beta4 中提供的 encryptionAlgorithm 功能。

RootlessControlPlane

設定此標誌會將 kubeadm 部署的控制平面元件靜態 Pod 容器配置為以非 root 使用者身分執行 kube-apiserver、kube-controller-manager、kube-scheduler 和 etcd。如果未設定此標誌，這些元件將以 root 身分執行。您可以在升級到較新版本的 Kubernetes 之前變更此功能閘道的值。

已移除的功能閘道列表

功能閘道說明

IPv6DualStack

當功能正在進行中時，此標誌有助於配置元件雙堆疊。有關 Kubernetes 雙堆疊支援的更多詳細資訊，請參閱 使用 kubeadm 的雙堆疊支援。

UnversionedKubeletConfigMap

此標誌控制 kubeadm 儲存 kubelet 組態資料的 ConfigMap 的名稱。如果未指定此標誌或設定為 true，則 ConfigMap 名稱為 kubelet-config。如果您將此標誌設定為 false，則 ConfigMap 的名稱將包含 Kubernetes 的主要和次要版本 (例如：kubelet-config-1.32)。kubeadm 確保讀取和寫入該 ConfigMap 的 RBAC 規則適用於您設定的值。當 kubeadm 寫入此 ConfigMap 時 (在 kubeadm init 或 kubeadm upgrade apply 期間)，kubeadm 會遵循 UnversionedKubeletConfigMap 的值。當 kubeadm 讀取該 ConfigMap 時 (在 kubeadm join、kubeadm reset、kubeadm upgrade... 期間)，kubeadm 會嘗試先使用未版本化的 ConfigMap 名稱。如果失敗，kubeadm 會退回到使用該 ConfigMap 的舊版 (已版本化) 名稱。

UpgradeAddonsBeforeControlPlane

此功能閘道已移除。它在 v1.28 中作為已棄用的功能引入，然後在 v1.31 中移除。有關舊版本的文檔，請切換到相應的網站版本。

新增 kube-proxy 參數

有關 kubeadm 組態中 kube-proxy 參數的資訊，請參閱

• kube-proxy 參考

有關使用 kubeadm 啟用 IPVS 模式的資訊，請參閱

• IPVS

將自訂標誌傳遞到控制平面元件

有關將標誌傳遞到控制平面元件的資訊，請參閱

• control-plane-flags

在沒有網際網路連線的情況下執行 kubeadm

為了在沒有網際網路連線的情況下執行 kubeadm，您必須預先提取所需的控制平面映像。

您可以使用 kubeadm config images 子命令列出和提取映像

kubeadm config images list
kubeadm config images pull

您可以將 --config 與上述命令一起傳遞，並使用 kubeadm 組態檔 來控制 kubernetesVersion 和 imageRepository 欄位。

kubeadm 需要的所有預設 registry.k8s.io 映像都支援多種架構。

使用自訂映像

預設情況下，kubeadm 從 registry.k8s.io 提取映像。如果請求的 Kubernetes 版本是 CI 標籤 (例如 ci/latest)，則會使用 gcr.io/k8s-staging-ci-images。

您可以使用含有設定檔的 kubeadm 來覆寫此行為。允許的自訂項目如下：

• 提供 kubernetesVersion，其會影響映像檔的版本。
• 提供替代的 imageRepository 以取代 registry.k8s.io。
• 為 etcd 或 CoreDNS 提供特定的 imageRepository 和 imageTag。

基於回溯相容性的考量，預設的 registry.k8s.io 和使用 imageRepository 指定的自訂儲存庫之間的映像檔路徑可能會有所不同。例如，一個映像檔的路徑可能在 registry.k8s.io/subpath/image，但當使用自訂儲存庫時，預設路徑可能會變成 my.customrepository.io/image。

為了確保您將映像檔推送至 kubeadm 可以使用的自訂儲存庫路徑，您必須

• 使用 kubeadm config images {list|pull} 從 registry.k8s.io 的預設路徑提取映像檔。
• 將映像檔推送至 kubeadm config images list --config=config.yaml 輸出的路徑，其中 config.yaml 包含自訂的 imageRepository，和/或 etcd 及 CoreDNS 的 imageTag。
• 將相同的 config.yaml 傳遞給 kubeadm init。

自訂沙箱 (pause) 映像檔

若要為這些項目設定自訂映像檔，您需要在您的容器執行期中設定以使用該映像檔。請查閱您的容器執行期的文件，以了解如何變更此設定；對於選定的容器執行期，您也可以在容器執行期主題中找到建議。

將控制平面憑證上傳到叢集

透過將 --upload-certs 標記新增到 kubeadm init，您可以暫時將控制平面憑證上傳到叢集中的 Secret。請注意，此 Secret 將在 2 小時後自動過期。憑證使用 32 位元組金鑰加密，該金鑰可以使用 --certificate-key 指定。當額外的控制平面節點加入時，可以透過將 --control-plane 和 --certificate-key 傳遞給 kubeadm join 來使用相同的金鑰下載憑證。

以下階段命令可用於在過期後重新上傳憑證

kubeadm init phase upload-certs --upload-certs --config=SOME_YAML_FILE

如果沒有將預定義的憑證金鑰傳遞給 kubeadm init 和 kubeadm init phase upload-certs，則會自動產生新的金鑰。

以下命令可用於按需產生新的金鑰

kubeadm certs certificate-key

使用 kubeadm 進行憑證管理

有關使用 kubeadm 進行憑證管理的詳細資訊，請參閱使用 kubeadm 進行憑證管理。該文件包含有關使用外部 CA、自訂憑證和憑證續訂的資訊。

管理 kubelet 的 kubeadm 放置檔案

kubeadm 套件附帶一個設定檔，用於透過 systemd 執行 kubelet。請注意，kubeadm CLI 永遠不會接觸此放置檔案。此放置檔案是 kubeadm DEB/RPM 套件的一部分。

如需更多資訊，請參閱管理 systemd 的 kubelet 放置檔案。

搭配 CRI 執行期使用 kubeadm

預設情況下，kubeadm 會嘗試偵測您的容器執行期。有關此偵測的更多詳細資訊，請參閱kubeadm CRI 安裝指南。

設定節點名稱

預設情況下，kubeadm 會根據機器的主機位址指派節點名稱。您可以使用 --node-name 標記覆寫此設定。該標記會將適當的 --hostname-override 值傳遞給 kubelet。

請注意，覆寫主機名稱可能會干擾雲端供應商。

自動化 kubeadm

您可以並行處理權杖分發以簡化自動化，而不是像基本的 kubeadm 教學中那樣，將從 kubeadm init 取得的權杖複製到每個節點。為了實作此自動化，您必須知道控制平面節點啟動後將擁有的 IP 位址，或者使用 DNS 名稱或負載平衡器的位址。

1. 產生權杖。此權杖的格式必須為 <6 個字元的字串>.<16 個字元的字串>。更正式地說，它必須符合 regex：[a-z0-9]{6}\.[a-z0-9]{16}。

   kubeadm 可以為您產生權杖

   kubeadm token generate
   

2. 同時啟動控制平面節點和工作節點，並使用此權杖。當它們啟動時，它們應該會找到彼此並形成叢集。相同的 --token 引數可以用於 kubeadm init 和 kubeadm join。

3. 對於加入額外控制平面節點時的 --certificate-key，也可以執行類似的操作。可以使用以下命令產生金鑰

   kubeadm certs certificate-key
   

叢集啟動後，您可以使用控制平面節點中的 /etc/kubernetes/admin.conf 檔案，以管理員身分與叢集通訊，或參閱為其他使用者產生 kubeconfig 檔案。

請注意，這種啟動樣式具有較寬鬆的安全性保證，因為它不允許使用 --discovery-token-ca-cert-hash 驗證根 CA 雜湊值（因為它在節點佈建時未產生）。有關詳細資訊，請參閱kubeadm join。

下一步

• kubeadm init phase 以更了解 kubeadm init 階段
• kubeadm join 以啟動 Kubernetes 工作節點並將其加入叢集
• kubeadm upgrade 以將 Kubernetes 叢集升級到較新版本
• kubeadm reset 以還原 kubeadm init 或 kubeadm join 對此主機所做的任何變更