Multi-Cloud Kubernetes 最佳實踐
【編者的話】本文以 IT 運維團隊為多個內部團隊構建企業級 Kubernetes 解決方案的視角展開，介紹了在制定 multi-cloud 策略時需要考慮的因素及解決辦法，包括基礎設施、版本管理、部署策略及安全性等方面，提供了一套相對完整的最佳實踐方案。
ofollow,noindex" target="_blank">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 叢集，定義公共安全層和應用程式管理。
原文連結： Best Practices for Multi-Cloud Kubernetes （翻譯： 李加慶 ）