這篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

更強大的基礎，用於建立和管理 Kubernetes 叢集

作者：Lucas Käldström (獨立) |

上次聽到我們的消息是在 9 月，當時我們宣布了 kubeadm。使 kubeadm 成為 Kubernetes 生態系統中一流成員的工作仍在繼續和發展。我們中的一些人在 KubeCon 之前也見面了，並舉行了一次非常富有成效的會議，我們討論了我們的 SIG、kubeadm 和 kops 的範圍。 

繼續定義 SIG-Cluster-Lifecycle

kubeadm 的範圍是什麼？
我們希望 kubeadm 成為所有 Kubernetes 部署的通用建構區塊；提供安全且建議的 Kubernetes 啟動方式的組件。由於沒有一種適用於所有情況的 Kubernetes 設定方式，kubeadm 將為每個階段支援多種方法。我們希望識別 Kubernetes 的每個部署中常見的階段，並為這些階段建立可設定且易於使用的 kubeadm 命令。例如，如果您的組織要求您以手動或自訂方式在叢集中分發憑證，請僅針對該階段跳過使用 kubeadm。我們的目標是在這種情況下保持 kubeadm 對所有其他階段都可用。我們希望您可以選擇要 kubeadm 執行的操作，並讓您自行完成其餘操作。

因此，kubeadm 的範圍是易於擴展、模組化且非常易於使用。目前，在此 v1.5 版本中，kubeadm 只能為您執行「全套服務」。在未來的版本中，隨著 kubeadm 變得更加組件化，這種情況將會改變，同時仍然保留為您完成所有事情的機會。但 kubeadm 仍然只會處理 Kubernetes 的啟動；它永遠不會為您處理機器的佈建，因為佈建可以透過更多方式完成。此外，我們希望 kubeadm 在任何地方都能運作，甚至在多種架構上也能運作，因此我們從一開始就內建了 多架構支援。

kops 的範圍是什麼？
kops 的範圍是自動化完整的叢集操作：安裝、重新設定叢集、升級 Kubernetes 以及最終的叢集刪除。kops 具有基於 Kubernetes API Machinery 的豐富組態模型，因此您可以輕鬆地自訂一些參數以滿足您的需求。kops（與 kubeadm 不同）為您處理資源的佈建。kops 的目標是在 AWS 上（以及未來可能在其他提供商上）提供極致的開箱即用體驗。未來，kops 將採用越來越多的 kubeadm 來處理存在的啟動階段。這會將 kops 內部的一些複雜性轉移到 kubeadm 形式的中心位置。

SIG-Cluster-Lifecycle 的範圍是什麼？
SIG-Cluster-Lifecycle 積極嘗試簡化 Kubernetes 的安裝和管理故事。這通常是透過修改 Kubernetes 本身並分解常見任務來完成的。我們也試圖解決叢集生命週期中的常見問題（就像名稱所說的那樣！）。我們維護 kubeadm 和 kops 並對其負責。我們討論目前在 AWS（及其他地方）啟動叢集的方式所存在的問題，並努力使其更輕鬆。我們在 Slack 的 #sig-cluster-lifecycle 和 #kubeadm 頻道中閒逛。 我們會每週在 Zoom 上聚會並討論目前的主題。隨時來打聲招呼！此外，不要害羞 貢獻；我們很樂意聽取您的意見和見解！

展望 v1.6

我們 v1.6 的目標圍繞重構、穩定性和安全性。 

首先，我們希望將 kubeadm 及其可組合的組態體驗提升到 Beta 版。我們將重構 kubeadm，以便可以單獨調用啟動程序中的每個階段。我們希望將 TLS Bootstrap API、Certificates API 和 ComponentConfig API 提升到 Beta 版，並讓 kops（和其他工具）使用它們。 

我們也將把我們現在使用的令牌發現（又名 gcr.io/google_containers/kube-discovery:1.0 映像）透過在控制器管理器中新增一個新的控制器：BootstrapSigner 來提升到 Beta 版。該控制器使用作為 Secrets 管理的令牌，將簽署新的 kube-public 命名空間中眾所周知的 ConfigMap 的內容（kubeconfig 檔案）。此物件將可供未經身份驗證的使用者使用，以便透過簡單且簡短的共享令牌啟用安全啟動。您可以在此處閱讀完整的提案。

除了可以單獨調用階段之外，我們還將新增一個新階段，用於以自託管模式啟動控制平面（相對於目前的靜態 Pod 技術）。自託管技術由 CoreOS 以 bootkube 的形式開發，現在將作為替代方案納入官方 Kubernetes 產品中。感謝 CoreOS 推進了這種模式！這將透過首先使用靜態 Pod 設定臨時控制平面，注入必要的 Deployment、ConfigMap 和 DaemonSet，最後關閉臨時控制平面來完成。目前，etcd 預設仍將在靜態 Pod 中。 

我們最初支援自託管，因為我們希望支援使用 kubeadm 進行修補程式版本升級。例如，從 v1.6.2 升級到 v1.6.4 應該很容易。我們認為內建的升級支援是真正的叢集生命週期工具的關鍵功能。仍然可以不進行自託管升級，但這需要更多手動操作。

在穩定性方面，我們希望開始執行 kubeadm e2e 測試。在此 v1.5 時間範圍內，我們新增了單元測試，我們將繼續增加該覆蓋率。我們希望將其擴展到每個 PR 的 e2e 測試，這些測試使用 kubeadm init 和 kubeadm join 啟動叢集；執行一些 kubeadm 專用測試，並可選擇執行一致性測試套件。

最後，在安全性方面，我們也希望 kubeadm 預設情況下盡可能安全。我們希望為 v1.6 啟用 RBAC，鎖定 kubelet 和內建服務（如 kube-dns 和 kube-proxy）可以執行的操作，並可能建立具有不同權限的特定使用者帳戶。

關於發布，我們希望在 kubernetes v1.6 tarball 中擁有官方 kubeadm v1.6 二進位檔案。這表示我們的發布與官方發布同步。關於我們目前已完成的工作的更多詳細資訊，請參閱此處。隨著條件允許，我們的目標是將 kubeadm 程式碼移出到 kubernetes/kubeadm 儲存庫（這受到一些可能需要一些時間才能解決的 Kubernetes 程式碼專用基礎架構問題的阻礙。）

v1.6 的理想功能將包括官方 CoreOS Container Linux 安裝程式容器，該容器執行 debs/rpms 為 Ubuntu/CentOS 執行的操作。總體而言，擴展發行版支援會很好。我們也希望採用 Kubelet Dynamic Settings，以便傳遞給 kubeadm init 的組態自動向下流動到節點（目前需要手動組態）。我們希望可以使用 kubeadm 從 HEAD 測試 Kubernetes。

2017 年及以後

除了上面提到的所有內容之外，我們希望 kubeadm 成為您可以使用的生產級 (GA) 工具，用於啟動 Kubernetes 叢集。我們希望 HA/多主節點比現在跨平台更容易實現（儘管 kops 今天在 AWS 上可以輕鬆實現！）。我們希望雲端提供商是樹狀結構外的，並且可以單獨安裝。kubectl apply -f my-cloud-provider-here.yaml 應該可以正常運作。文件應該更健全且更深入。容器執行階段介面 (CRI) 和聯邦應該與 kubeadm 良好地協同運作。應該刪除過時的入門指南，以免誤導新使用者。

重構雲端提供商整合外掛程式
目前，雲端提供商整合已建置到控制器管理器、kubelet 和 API 伺服器中。再加上對 Kubernetes 不斷增長的興趣，使得將雲端提供商整合編譯到核心中變得難以維護。明顯特定於供應商的功能不應成為核心 Kubernetes 專案的一部分，而應作為第三方供應商的附加元件提供。所有雲端特定的內容都應該移到一個控制器中，或者如果需要，可以移到幾個控制器中。此控制器將由第三方（通常是整合背後的公司）維護，並將實作雲端特定功能。從核心內到核心外的遷移確實具有破壞性，但它具有非常好的副作用：更精簡的核心，使超過七個現有雲端可以與 Kubernetes 整合，並且安裝更容易。例如，您可以在 Deployment 中執行雲端控制器二進位檔案，並使用 kubectl apply 輕鬆安裝它。

v1.6 的計畫是使其能夠

  • 建立和執行核心外雲端提供商整合控制器
  • 在 Kubernetes 版本中發布新的臨時二進位檔案：cloud-controller-manager。此二進位檔案將包含七個現有的雲端提供商，並將作為驗證、測試和遷移到新流程的方式。在未來的版本（建議為 v1.9）中，--cloud-provider 旗標將停止運作，並且臨時 cloud-controller-manager 二進位檔案將不再發布。相反，名為 kubernetes/cloud-providers 的儲存庫將作為經過官方驗證的雲端提供商發展和存在的場所，但其中的所有提供商都將彼此獨立。（問題 #2770；提案 #128；程式碼 #3473。）

從 v1.4 到 v1.5 的變更日誌

kubeadm  

v1.5 是 kubeadm 的穩定性版本。我們致力於使 kubeadm 更加使用者友善、透明且穩定。新增了一些新功能，使其更具可設定性。

以下是已變更內容的簡短摘錄

  • 使 kubeadm 的主控台輸出更乾淨且更使用者友善 #37568
  • 實作 kubeadm reset 以排空和清理節點 #34807 和 #37831
  • 預檢實作，如果環境無效，則快速失敗 #34341 和 #36334
  • kubectl logs 和 kubectl exec 現在可以與 kubeadm 一起使用 #37568
  • 以及許多其他改進，請閱讀完整的 變更日誌。

kops

以下是已變更內容的簡短摘錄

  • 支援 CNI 網路外掛程式 (Weave、Calico、Kope.io)
  • 完全私有部署，其中節點和主節點沒有公用 IP
  • 改進叢集的滾動更新，特別是 HA 叢集的滾動更新
  • 除了 Debian 之外，還支援 CentOS / RHEL / Ubuntu 的 OS，以及支援 sysdig 和 perf 工具

前往查看 kops 發布頁面，以取得有關最新和最棒的 kops 發布的資訊。

摘要

簡而言之，我們對即將在未來版本中為您帶來許多這些改進的路線圖感到興奮。我們希望這將使入門體驗更加輕鬆，並引導 Kubernetes 的採用率提高。

感謝您的所有意見反應和貢獻。我希望這讓您對我們正在做的事情有所了解，並鼓勵您加入我們的會議並打聲招呼！