動態 Kubelet 組態

編輯註記：此功能已在 1.22 版本中棄用後，於 1.24 版本中移除。

編輯註記：這篇文章是關於 Kubernetes 1.11 新功能的系列深入文章的一部分

為何需要動態 Kubelet 組態？

Kubernetes 提供以 API 為中心的工具，可顯著改善管理應用程式和基礎架構的工作流程。然而，大多數 Kubernetes 安裝都在每個主機上以原生程序執行 Kubelet，這超出了標準 Kubernetes API 的範圍。

過去，這意味著叢集管理員和服務供應商無法依賴 Kubernetes API 來重新配置即時叢集中的 Kubelet。實際上，這要求操作員要麼 ssh 連線到機器以執行手動重新配置，要麼使用第三方組態管理自動化工具，要麼建立已安裝所需組態的新 VM，然後將工作負載移轉到新機器。這些方法特定於環境，並且可能很昂貴。

動態 Kubelet 組態使叢集管理員和服務供應商能夠透過 Kubernetes API 重新配置即時叢集中的 Kubelet。

什麼是動態 Kubelet 組態？

Kubernetes v1.10 使透過 beta 版組態檔 API 組態 Kubelet 成為可能。Kubernetes 已經提供 ConfigMap 抽象概念，用於在 API 伺服器中儲存任意檔案資料。

動態 Kubelet 組態擴展了 Node 物件，以便 Node 可以參照包含相同類型組態檔的 ConfigMap。當 Node 更新為參照新的 ConfigMap 時，相關聯的 Kubelet 將嘗試使用新的組態。

它是如何運作的？

動態 Kubelet 組態提供以下核心功能

• Kubelet 嘗試使用動態指派的組態。
• Kubelet 將組態「檢查點」到本機磁碟，從而無需 API 伺服器存取即可重新啟動。
• Kubelet 在 Node 狀態中報告指派、作用中和上次已知良好組態來源。
• 當動態指派無效組態時，Kubelet 會自動回復到上次已知良好組態，並在 Node 狀態中報告錯誤。

若要使用動態 Kubelet 組態功能，叢集管理員或服務供應商將首先發布包含所需組態的 ConfigMap，然後設定每個 Node.Spec.ConfigSource.ConfigMap 參照以參照新的 ConfigMap。操作員可以按照他們偏好的速率更新這些參照，使他們能夠執行新組態的受控發布。

每個 Kubelet 都會監看其相關聯的 Node 物件的變更。當 Node.Spec.ConfigSource.ConfigMap 參照更新時，Kubelet 將透過將其包含的檔案寫入本機磁碟來「檢查點」新的 ConfigMap。然後 Kubelet 將退出，並且作業系統層級的程序管理員將重新啟動它。請注意，如果未設定 Node.Spec.ConfigSource.ConfigMap 參照，則 Kubelet 會使用機器本機的旗標和組態檔集。

重新啟動後，Kubelet 將嘗試使用來自新檢查點的組態。如果新組態通過 Kubelet 的內部驗證，Kubelet 將更新 Node.Status.Config 以反映它正在使用新組態。如果新組態無效，Kubelet 將回復到其上次已知良好組態，並在 Node.Status.Config 中報告錯誤。

請注意，預設的上次已知良好組態是 Kubelet 命令列旗標與 Kubelet 的本機組態檔的組合。與組態檔重疊的命令列旗標始終優先於本機組態檔和動態組態，以實現向後相容性。

請參閱以下圖表，以取得單個 Node 組態更新的高階概述

我如何能瞭解更多資訊？

請參閱位於 /docs/tasks/administer-cluster/reconfigure-kubelet/ 的官方教學課程，其中包含有關使用者工作流程、組態如何變成「上次已知良好」、Kubelet 如何「檢查點」組態以及可能的失敗模式的更深入詳細資訊。

• ←上一篇
下一篇→