2018 年雲服務現狀調查顯示，81％ 的企業會使用混合雲，公有雲計算服務和現代基礎架構平台更具靈活性。隨著企業為客戶提供價值速度的加快，公有雲和私有雲的採用率繼續以健康的速度增長也就不足為奇了。 事實上，根據 IDC 的最新數據，2018 年第一季度全球伺服器出貨量同比增長 20.7％ 至 270 萬台，收入增長 38.6％，連續第三個季度實現兩位數增長！

另一個令人興奮的大趨勢是，容器成為了打包和管理應用程序組件的最佳方式。Kubernetes 是部署和操作容器化應用的最佳方式，這一點已被廣泛認同。另外重要的一點是，Kubernetes 可以助力跨雲供應商提供標準化功能。

但這些進步也引進了新的複雜性。容器解決了一些 DevOps 面臨的挑戰，但也引入了新的需要管理的抽象層。Kubernetes 解決了運維面臨的部分挑戰，並非全部。而且，Kubernetes 是一個分散式應用，本身也需要管理。

在不同雲供應商之間部署和運營 Kubernetes 集群時會面臨一些關鍵挑戰，本文將就此討論解決這些挑戰的最佳實踐和指南。我們將以 IT 運維團隊為多個內部團隊構建企業級 Kubernetes 解決方案的視角展開。

1. 利用好基礎設施

與本地基礎架構供應商一樣，所有雲供應商都提供存儲和網路服務。在考慮 multi-cloud 策略時要關注的一個問題是，是依賴每個供應商的能力還是自己去抽象一層。雖然這兩種方法都可行，但嘗試最小化抽象層並利用供應商的原生方法始終是明智的做法。例如，不要在 AWS 中運行Overlay Network，而最好使用 AWS 的 Kubernetes CNI（容器網路介面）插件，該插件為Kubernetes 提供本機網路功能。此方法還允許使用其他服務，如安全組和 IAM。

2. 管理自己的（上游）Kubernetes 版本

Kubernetes 是一個快速發展的項目，每三個月發布一次新版本。一個關鍵的決定是，是否希望供應商為你測試新版的 Kubernetes，或者是否允許團隊直接使用上游版本。

當然，這需要衡量利弊。使用供應商管理的 Kubernetes，供應商可以提供額外測試和驗證。但是，Cloud Native Computing Foundation（CNCF）的 Kubernetes 社區本身擁有成熟的開發、測試和發布流程。Kubernetes 項目由一些特殊興趣小組（SIG）組織，Release SIG 負責確保每個新版本的質量和穩定性。CNCF 還為供應商提供 Kubernetes 軟體一致性計劃，以確保他們的軟體與 Kubernetes API 100％ 兼容。

企業在生產環境中最好使用穩定版本。但是，某些團隊可能需要具有 pre-GA 功能的集群。最好的辦法是，團隊可靈活選擇多個校驗過的上游版本，或者按需嘗試更新的版本，但風險自負。

3. 通過策略標準化集群部署

安裝 Kubernetes 集群時需要考慮的幾個點。 如下：

版本：要使用的 Kubernetes 組件的版本。

網路：通過 CNI（容器網路介面）插件配置要使用的網路技術。

存儲：通過 CSI（容器存儲介面）插件配置要使用的存儲技術。

Ingress：Ingress Controller 用於負載均衡和反向代理外部請求到應用程序服務。

監控：用於監控集群中 Kubernetes 組件和工作負載的附加組件。

日誌記錄：一種集中式日誌記錄解決方案，用於從 Kubernetes 組件以及集群中的應用程序工作負載收集、聚合和轉發日誌到集中式日誌記錄系統。

其他附加組件：需要作為集群的一部分運行的其他服務，如 DNS 和安全組件。

雖然可以針對每個集群應用這些設置，但將集群安裝採樣為模板或策略會更加高效，可以輕鬆復用。這方面的一些示例可以是 Terraform 腳本或 Nirmata 集群策略。集群安裝自動化後，也可以作為更高級別工作流的一部分調用，例如從服務目錄中完成自助服務配置請求。

4. 提供端到端安全性

容器和 Kubernetes 的安全性需要考慮下面幾個點：

鏡像掃描：需要在運行之前掃描容器鏡像以查找漏洞。在允許鏡像進入企業的私有註冊表之前，可以將此步驟作為 Continuous Delivery 管道的一部分來實現。

鏡像來源：鏡像掃描檢查漏洞時，明確鏡像出處，確保只允許「可信」鏡像進入正在運行的集群或環境。

主機和集群掃描：除了確保鏡像安全外，集群節點及主機也需要掃描。此外，定期運行互聯網安全中心（CIS）基準以確保 Kubernetes 安全是最佳做法。

分段和隔離：即使多租戶可能不是一項硬性要求，最好還是計劃在多個異構工作負載之間共享集群，以提高效率並節省更多成本。Kubernetes 提供用於隔離（例如，命名空間和網路策略）以及用於管理資源消耗（資源配額）的構造。

身份管理：在典型的企業部署中，用戶身份由中心目錄提供。無論在何處部署集群，都必須聯合用戶身份許可權，以便以一致的方式輕鬆控制和應用集群。

訪問控制：雖然 Kubernetes 沒有用戶的概念，但它提供了豐富的控制項來指定角色和許可權。集群可以利用默認角色或使用指定許可權集定製角色。企業中的所有集群都具有這些角色的通用定義以及跨集群管理它們的方法，這一點很重要。

雖然這些安全實踐中的每一個都可以單獨應用，但從整體上看，打造一套適用於多個雲供應商的安全策略是有意義的。可以使用 AquaSec，Twistlock 等安全解決方案以及 Nirmata，OpenShift 等平台實現。

5. 集中應用程序管理

與安全性一樣，管理 Kubernetes 集群上的應用程序需要集中且一致的方法。Kubernetes 提供了一組可用於定義和操作應用程序的全面構造，大有應用內置的概念。這實際上是一件好事，因為它可以靈活地支持不同的應用程序類型，並允許在 Kubernetes 上用不同方式構建更多定製化的應用程序平台。

但是，任何 Kubernetes 應用程序管理平台都必須提供幾個常見的屬性和功能。下面主要討論針對Kubernetes 工作負載，中心化應用程序管理的問題。

應用程序建模和定義

用戶需要定義應用程序組件，並從現有組件組成應用程序。Kubernetes 的核心設計理念是其聲明性，用戶可以在其中定義所需的系統狀態。Kubernetes 工作負載 API 提供了幾種構造來定義所需的資源狀態。例如，部署可用於構造無狀態工作負載組件。這些定義通常寫為一組 YAML 或JSON 清單。但是，開發人員需要組織和管理這些清單，通常是在像 Git 這樣的版本控制系統（VCS）中。

雖然開發人員希望定義和管理應用程序的某些部分，但當這部分指定了操作策略，並且可能針對特定的運行時環境時，最好由運營團隊管理。因此，正確理解程序行為的方式是將其視為在部署和更新之前動態組合的管道。

Helm （Kubernetes 包管理工具）解決了其中一些挑戰，它可以輕鬆地將應用程序分組，版本化，部署及更新為 Helm Charts。

Kubernetes 應用程序平台必須提供簡單的方法來建模，組織及構建應用程序清單和 Helm Charts，並恰當分離開發和運維資源之間的關注點。還必須提供定義校驗，以儘早捕獲常見錯誤，以及重用應用程序定義的簡便方法。

環境——應用程序運行時管理

一旦對應用程序進行建模和驗證後，就需要將它們部署到集群。但是，最終目標是在不同工作負載之間重用群集，以提高效率並增加成本節約。因此，最好將應用程序運行時環境與集群分離，並將常用策略和控制應用於這些環境。

Kubernetes 允許使用命名空間和網路策略創建虛擬集群。Kubernetes 應用程序平台應該可以輕鬆利用這些構造，創建具有邏輯分段，隔離和資源控制的環境。

更改管理

在很多情況下，運行時環境壽命會很長，並且需要通過控制器進行更改。這些更改可能源自構建系統或來自傳遞管道中的上游環境。

Kubernetes 應用程序平台需要提供 CI/CD 工具的集成，並監控外部 repository 的變化。檢測到更改後，應對其進行驗證，然後根據每個環境的更改管理策略進行處理。用戶應該查看並接受更改或完全自動化更新過程。

應用監控

應用程序可能在多個環境和不同群集中運行。關於監控，重要的是有能力將信號與雜訊分離並專註於應用實例。因此，度量、狀態和事件需要與應用程序和運行時構造相關聯。Kubernetes 應用程序平台必須提供帶有自動粒度標記的集成監視，以便用戶可以輕鬆地下鑽並專註於任何環境中的應用程序實例。

應用日誌

與監控類似，日誌數據需要與應用程序定義和運行時信息相關聯，並且應該可以訪問任何應用程序組件。Kubernetes 應用程序平台必須能夠流式傳輸並聚合來自不同運行組件的日誌。如果使用集中式日誌記錄系統，則必須應用必要的標記，以便能夠分離來自不同應用程序和環境的日誌，並支持跨團隊和用戶的訪問。

報警和通知

服務管理層面必須能夠根據任意指標，狀態更改或條件定製警報。再強調一點，需要正確區分緊急報警和其他常規報警。例如，如果相同的應用程序部署在 dev-test，staging 和 production 等多個環境中運行，則能夠自定義僅在生產環境才可觸發的警報規則是非常重要的。 Kubernetes 應用程序平台必須具備提供定義和管理環境及應用程序感知的粒度警報規則的能力。

遠程訪問

雲環境往往是動態的，容器將動態性提升到了一個新的水平。 一旦檢測到並報告了問題，就必須快速訪問系統中受影響的組件。Kubernetes 應用程序平台必須提供一種方法，將 shell 啟動到正在運行的容器中，並訪問容器運行時的詳細信息，而無需通過 VPN 和 SSH 訪問雲實例。

事件管理

在 Kubernetes 應用程序中，容器可能會停止運行並快速重新啟動。停止運行可能是正常工作流程的一部分，如升級，或者可能是由於內存不足等情況導致的錯誤。Kubernetes 應用程序平台必須能夠識別故障並捕獲故障的所有詳細信息，以便進行離線故障排除和分析。

總結

容器和 Kubernetes 允許企業利用一組通用的行業最佳實踐來跨雲供應商進行應用程序操作和管理。所有主流雲供應商和應用平台都承諾支持 Kubernetes。這包括平台即服務（PaaS）解決方案，其中開發人員提供代碼工件，平台執行其他工作；容器即服務（CaaS）解決方案，開發人員提供容器映像，平台完成其餘工作；功能即服務（FaaS）解決方案，開發人員只需提供功能，平台完成其餘工作。 Kubernetes 已成為新的雲原生操作系統。

在開發 multi-cloud Kubernetes 策略時，企業必須考慮他們希望如何使用基礎架構服務，管理Kubernetes 組件版本，設計和管理 Kubernetes 集群，定義公共安全層和應用程序管理。

本譯文由 Docker微信號（id:dockerone）首發，譯者 李加慶，查看【譯文鏈接】

原文鏈接：dzone.com/articles/best

推薦閱讀：

相关文章