遠端管理、地端部署、裸機 Kubernetes 叢集的挑戰

簡介

最近發布的 Platform9 Managed Kubernetes (PMK) 是一種地端部署企業 Kubernetes 解決方案，具有不尋常的特色：雖然叢集在使用者內部硬體上執行，但其佈建、監控、故障排除和整體生命週期是從 Platform9 SaaS 應用程式遠端管理的。雖然使用者喜歡這種部署模型的直覺式體驗和易用性，但這種方法帶來了有趣的技術挑戰。在本文中，我們將首先描述 PMK 的動機和部署架構，然後概述我們面臨的技術挑戰以及我們的工程團隊如何解決這些挑戰。

多作業系統引導模型

與其前身 Managed OpenStack 一樣，PMK 旨在讓企業客戶盡可能輕鬆地部署和運作「私有雲」，在目前的背景下，這意味著一個或多個 Kubernetes 叢集。為了適應標準化使用特定 Linux 發行版的客戶，我們的安裝過程使用「裸機作業系統」或「自備作業系統」模型，這表示管理員透過在其喜愛的作業系統 (Ubuntu-14、CentOS-7 或 RHEL-7) 上安裝簡單的 RPM 或 Deb 套件，將 PMK 部署到現有的 Linux 節點。管理員從其 Platform9 SaaS 入口網站下載的套件，會啟動一個代理程式，該代理程式已預先配置所有資訊和憑證，以安全地連線到並註冊到客戶在 WAN 上執行的 Platform9 SaaS 控制器。

節點管理

第一個挑戰是在沒有裸機雲端 API 和 SSH 存取節點的情況下配置 Kubernetes 節點。我們使用節點池概念和組態管理技術解決了這個問題。每個執行代理程式的節點都會自動顯示在 SaaS 入口網站中，使用者可以授權該節點用於 Kubernetes。新授權的節點會自動進入節點池，表示該節點可用但未在任何叢集中使用。管理員可以獨立建立一個或多個 Kubernetes 叢集，這些叢集一開始是空的。在稍後的任何時間，他或她都可以要求將一個或多個節點附加到任何叢集。PMK 透過將指定數量的節點從池中轉移到叢集來滿足請求。當節點獲得授權時，其代理程式會變成組態管理代理程式，輪詢在 SaaS 應用程式中執行的 CM 伺服器的指令，並能夠下載和配置軟體。

叢集建立和節點附加/分離操作透過 REST API、名為 qb 的 CLI 公用程式和基於 SaaS 的 Web UI 公開給管理員。以下螢幕截圖顯示 Web UI 顯示一個名為 clus100 的 3 節點叢集、一個空的叢集 clus101 和三個節點。

叢集初始化

第一次將一個或多個節點附加到叢集時，PMK 會配置節點以形成完整的 Kubernetes 叢集。目前，PMK 自動決定 Master 和 Worker 節點的數量和位置。未來，PMK 將為管理員提供「進階模式」選項，允許他們覆寫和自訂這些決策。然後，PMK 透過 CM 伺服器向每個節點傳送組態和一組腳本，以根據組態初始化每個節點。這包括安裝或升級 Docker 到所需版本；啟動 2 個 docker daemon（bootstrap 和 main）、建立 etcd K/V 儲存、建立 flannel 網路層、啟動 kubelet，以及執行適用於節點角色的 Kubernetes（master 與 worker）。下圖顯示完整形成的叢集的組件佈局。

容器化的 kubelet？

我們遇到的另一個障礙源於我們最初決定按照多節點 Docker 部署指南的建議執行 kubelet。我們發現這種方法引入了複雜性，導致許多難以排除故障的錯誤，這些錯誤對 Kubernetes、Docker 和節點作業系統的組合版本很敏感。範例：kubelet 需要將包含密碼的目錄掛載到容器中，以支援 服務帳戶機制。事實證明，從容器內部執行此操作很棘手，並且需要複雜的步驟順序，結果證明這很脆弱。在修復持續不斷的問題後，我們最終決定在主機作業系統上以原生程式執行 kubelet，從而顯著提高了穩定性。

克服網路障礙

PMK 的 Beta 版本目前使用具有 UDP 後端的 flannel 作為網路層。在 Kubernetes 叢集中，許多基礎架構服務需要使用各種連接埠 (443、4001 等) 和協定 (TCP 和 UDP) 跨節點進行通訊。通常，客戶節點有意或無意地封鎖部分或全部流量，或執行與所需連接埠衝突的現有服務，從而導致不明顯的故障。為了解決這個問題，我們嘗試儘早偵測組態問題並立即通知管理員。PMK 在安裝 Kubernetes 軟體之前，對參與叢集的所有節點執行「預檢」檢查。這表示在每個節點上執行小型測試程式，以驗證 (1) 所需的連接埠可用於繫結和接聽；以及 (2) 節點可以使用所有所需的連接埠和協定相互連線。這些檢查並行執行，並且在叢集初始化之前花費不到幾秒鐘。

監控

SaaS 管理的私有雲的價值之一是 SaaS 團隊的持續監控和早期問題偵測。無需客戶介入即可解決的問題會自動處理，而其他問題會透過 UI 警報、電子郵件或即時通道觸發與客戶的主動溝通。Kubernetes 監控是一個非常大的主題，值得單獨撰寫部落格文章，因此我們僅簡要介紹一下。我們大致將問題分為幾層：(1) 硬體和作業系統，(2) Kubernetes 核心（例如 API 伺服器、控制器和 kubelet），(3) 附加元件（例如 SkyDNS 和 ServiceLoadbalancer）和 (4) 應用程式。我們目前專注於第 1-3 層。我們看到的主要問題來源之一是附加元件故障。如果 DNS 或 ServiceLoadbalancer 反向 http 代理（即將升級到 Ingress Controller）發生故障，應用程式服務將開始失敗。我們偵測此類故障的一種方法是使用 Kubernetes API 本身監控組件，該 API 會代理到 SaaS 控制器中，讓 PMK 支援團隊可以監控任何叢集資源。為了偵測服務故障，我們關注的一個指標是 pod 重新啟動。高重新啟動計數表示服務持續失敗。

未來主題

我們在其他領域也面臨複雜的挑戰，這些挑戰值得單獨撰寫文章：(1) 使用 Keystone 進行身分驗證和授權，Keystone 是 Platform9 產品使用的身分管理員；(2) 軟體升級，即如何使升級簡短且不中斷應用程式；以及 (3) 與客戶的外部負載平衡器整合（在沒有良好自動化 API 的情況下）。

結論

Platform9 Managed Kubernetes 使用 SaaS 管理模型，試圖隱藏在客戶資料中心部署、運作和維護裸機 Kubernetes 叢集的複雜性。這些需求導致開發了獨特的叢集部署和管理架構，進而帶來了獨特的技術挑戰。本文概述了其中一些挑戰以及我們如何解決這些挑戰。如需有關 PMK 背後動機的更多資訊，請隨時查看 Madhura Maskasky 的部落格文章。

• ←上一篇
下一篇→