動態 Kubelet 配置

編者注：該功能已在 1.22 版本中棄用，並在 1.24 版本中移除。

編者按：此文章是關於 Kubernetes 1.11 新功能的一系列深度文章之一

為什麼需要動態 Kubelet 配置？

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

過去，這意味著叢集管理員和服務提供商無法依靠 Kubernetes API 在即時叢集中重新配置 Kubelet。實際上，這要求操作員要麼 SSH 進入機器進行手動重新配置，要麼使用第三方配置管理自動化工具，或者建立已安裝所需配置的新虛擬機器，然後將工作遷移到新機器。這些方法都是環境特定的，並且可能代價高昂。

動態 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 本地配置檔案的組合。為了向後相容，與配置檔案重疊的命令列標誌始終優先於本地配置檔案和動態配置。

請參閱以下圖表，瞭解單個節點的配置更新高階概述。

我如何瞭解更多資訊？

請參閱官方教程 /docs/tasks/administer-cluster/reconfigure-kubelet/，其中包含更多關於使用者工作流程、配置如何成為“最後一次已知良好配置”、Kubelet 如何“檢查點”配置以及可能的故障模式的深入細節。

• ←上一篇
• 下一篇→