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

遠端管理、本地部署、裸機 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以及三個節點。

clusters_and_containervisors_view.png

叢集初始化

首次將一個或多個節點連線到叢集時,PMK會配置這些節點以形成完整的Kubernetes叢集。目前,PMK會自動決定主節點和工作節點的數量和位置。未來,PMK將為管理員提供“高階模式”選項,允許他們覆蓋和自定義這些決策。然後,透過CM伺服器,PMK會向每個節點發送配置和一組指令碼,以根據配置初始化每個節點。這包括安裝或升級Docker到所需版本;啟動兩個Docker守護程式(引導和主程式),建立etcd K/V儲存,建立flannel網路層,啟動kubelet,以及執行適合節點角色(主節點或工作節點)的Kubernetes元件。下圖顯示了完全形成的叢集的元件佈局。

architecture.png

容器化的kubelet?

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

克服網路障礙

PMK 的 Beta 版本目前使用 flannel 與 UDP 後端作為網路層。在 Kubernetes 叢集中,許多基礎設施服務需要使用各種埠(443、4001 等)和協議(TCP 和 UDP)跨節點通訊。通常,客戶節點有意或無意地阻止部分或所有流量,或者執行與所需埠衝突的現有服務,從而導致不明顯的故障。為了解決這個問題,我們嘗試及早檢測配置問題並立即通知管理員。PMK 在安裝 Kubernetes 軟體之前,會對參與叢集的所有節點執行“預檢”檢查。這意味著在每個節點上執行小型測試程式,以驗證 (1) 所需埠可用於繫結和偵聽;(2) 節點可以使用所有必需的埠和協議相互連線。這些檢查並行執行,並在叢集初始化前不到幾秒鐘完成。

監控

SaaS 管理的私有云的價值之一是 SaaS 團隊持續監控和早期發現問題。無需客戶干預即可解決的問題會自動處理,而其他問題則透過 UI 警報、電子郵件或即時渠道與客戶進行主動溝通。Kubernetes 監控是一個龐大的主題,值得單獨撰寫一篇部落格文章,因此我們只簡要介紹一下。我們將問題大致分為幾層:(1) 硬體和作業系統,(2) Kubernetes 核心(例如 API 伺服器、控制器和 kubelet),(3) 附加元件(例如 SkyDNSServiceLoadbalancer)以及 (4) 應用程式。我們目前專注於第 1-3 層。我們發現的主要問題來源是附加元件故障。如果 DNS 或 ServiceLoadbalancer 反向 HTTP 代理(很快將升級為 Ingress Controller)發生故障,應用程式服務將開始失敗。我們檢測此類故障的一種方法是使用 Kubernetes API 本身監控元件,該 API 被代理到 SaaS 控制器中,允許 PMK 支援團隊監控任何叢集資源。為了檢測服務故障,我們關注的一個指標是“Pod 重啟次數”。高重啟次數表明服務持續失敗。

未來主題

我們在其他領域也面臨著複雜的挑戰,這些挑戰值得單獨撰寫文章:(1) 使用 Platform9 產品使用的身份管理器 Keystone 進行身份驗證和授權;(2) 軟體升級,即如何使它們簡短且不對應用程式造成中斷;以及 (3) 與客戶的外部負載均衡器整合(在缺乏良好自動化 API 的情況下)。

結論

Platform9 Managed Kubernetes 採用 SaaS 管理模型,旨在隱藏在客戶資料中心部署、操作和維護裸金屬 Kubernetes 叢集的複雜性。這些要求促成了獨特的叢集部署和管理架構的開發,進而帶來了獨特的技術挑戰。本文概述了其中一些挑戰以及我們如何解決這些挑戰。有關 PMK 背後動機的更多資訊,請參閱 Madhura Maskasky 的部落格文章