【51CTO.com原創稿件】本文討論在多種云服務的模式下，成功部署和運行 Kubernetes 群集的關鍵操作難點與最佳實踐。

根據 2018 年云計算狀況報告顯示：如今 81% 的企業都使用了多種云服務的模式，他們通過采用公有云服務、現代基礎構造平臺、以及公/私有云的持續混合，在快速、靈活地調整自身規模和容量的同時，能夠更快地給客戶提供價值。

實際上，根據 IDC 的最新數據， 2018 年第一季度，全球服務器出貨量同比增加了 20.7%，高達 270 萬臺，整體收入則增長了 38.6% ，這是連續第三個季度達到兩位數的增長。

[[236964]]

另一個令人振奮的趨勢是：容器的出現為應用組件的打包和管理提供了最佳的實現方式。Kubernetes 也已被廣泛地接受為部署和操作容器化應用的最佳方案。而且，Kubernetes 的關鍵價值就在于它能夠協助標準化多種云供應商所提供的服務功能。

當然，上述優勢也帶來了一定的復雜性。容器雖然解決了 DevOps 的相關問題，但同時也引入了一個新的、需要管理的抽象層。

由于 Kubernetes 本身就是一個需要管理的分布式應用，因此它只能解決運營上的部分問題，而非全部。

我們將在本文中討論多種云服務的模式下，成功部署和運行 Kubernetes 群集的關鍵操作難點與最佳實踐。

總的說來，我們所持的觀點是：IT運營團隊應當為多個內部其他團隊構建出一套企業級的 Kubernetes 整體策略。

使用最佳的基礎設施

與傳統的內部基礎設施供應商相同，所有云服務供應商都能夠提供存儲和網絡等方面的服務。

在考慮多種云服務模式的策略時，我們值得注意的是：到底是使用各個供應商所提供的現有功能？或是要用到一個抽象層。

雖然這兩種方法都可行，但是您應當謹慎地盡量最小化抽象層、且使用供應商自己提供的方案。

例如：不要在AWS中運行覆蓋網絡（overlay network，譯者注：是一種面向應用層，而不必或減少考慮網絡層與物理層的網絡協議），而最好去使用 AWS 提供的 Kubernetes CNI （容器網絡接口，Container Network Interface）插件，為 Kubernetes 提供原生的網絡功能。

此方法還可以使用諸如安全組和 IAM （譯者注：身份識別與訪問管理，Identity and Access Management）等其他服務。

管理自己的Kubernetes版本

Kubernetes 是一個快速推進的項目，它每三月都有一個更新版本的發布。因此您需要決定的是：由供應商為您測試和管理 Kubernetes 的各個發布版本，還是希望允許自己的團隊直接使用那些版本。

凡事都有利弊兩面值得考慮。如果您使用供應商去管理 Kubernetes，那么他們會帶來額外的測試和驗證方面的幫助。

當然，云原生計算基金會（Cloud Native Computing Foundation，CNCF )的 Kubernetes 社區本身就具有成熟的開發、測試與發布流程。

Kubernetes 項目是由一個特殊興趣小組（Special Interest Groups，SIGs）所管理， Release SIG （https://github.com/kubernetes/sig-release#mission）負責通過各種流程，來確保每個新版本的質量和穩定性。

CNCF還為各個供應商提供了 Kubernetes 軟件一致性（https://www.cncf.io/certification/software-conformance/）計劃，以證明他們的軟件能與 Kubernetes 的各個 API 實現 100% 兼容。

對于企業內部而言，我們最好將穩定的版本使用到生產環境之中。但是，有些團隊可能需要具有 pre-GA （譯者注：pre-General Availability, 發布正式版本之前）功能的群集。

因此，最好的辦法就是：讓團隊靈活地選擇多種經過驗證的 Upstream 版本，或者讓他們根據需要去嘗試新的版本，但是需要風險自擔。

根據策略來規范群集的部署

安裝 Kubernetes 群集時，我們需要做出如下重要的決定：

• 版本：要使用的 Kubernetes 組件版本。
• 網絡：要使用的網絡技術，通過 CNI （Container Networking Interface ，容器網絡接口， https://github.com/containernetworking/cni）插件來配置。
• 存儲：要使用的存儲技術，通過  CSI （Container Storage Interface ，容器存儲接口，https://github.com/container-storage-interface/spec）插件來配置。
• 入口：入口控制器（Ingress Controller）可被用于負載平衡器，以及將各種外部請求反向代理到您的不同應用服務上。
• 監控：可用于監控群集中 Kubernetes 組件和工作負載的加載項。
• 日志記錄：一種集中式日志方案，可用于從群集的 Kubernetes 組件和應用負載中收集、聚合并轉發日志到集中式日志記錄系統中。
• 其他加載項：其他需要作為群集的一部分運行的服務，如 DNS 和安全組件。

雖然我們可以對每一次群集的安裝執行上述決策，但是如果能將它們作為群集安裝的模板或策略錄入下來的話，對于我們之后的重用來說則會更為高效。

例如，我們可以用到 Terraform 腳本（https://www.terraform.io/docs/providers/kubernetes/index.html）或 Nirmata 集群策略（http://nirmata-documentation.readthedocs.io/en/latest/Clusters.html）。

一旦群集安裝被予以自動化，它就可以作為高級工作流的一部分進行調用。例如：根據服務目錄，執行自助服務的調配請求。

提供端對端的安全

對于容器和 Kubernetes 的安全性，我們需要考慮如下方面：

• 鏡像掃描：在容器鏡像運行之前，我們必須進行各種漏洞的掃描。因此，在允許鏡像進入企業的專用存儲表之前，該步驟可以作為持續交付（Continuous Delivery）管道的一部分予以實施。
• 鏡像來源：除了對鏡像進行漏洞掃描之外，我們還應當只允許那些“受信任”的鏡像進入正在運行的群集環境之中。
• 主機與群集掃描：除了對鏡像實施安全控制，我們也應對群集節點執行掃描。通過運用 CIS（Center for Internet Security）的各種安全基線（ https://www.cisecurity.org/benchmark/kubernetes/），對 Kubernetes 進行例行安全加固就是一種最佳的實踐。
• 分割與隔離：雖說多租戶環境并非是硬性要求，但是通過在多個異構的工作負載之間共享群集，著實能夠提高效率并節省成本。Kubernetes 為隔離（如：命名空間和網絡策略）和管理資源的開銷（如：資源配額）提供了相應的構造。
• 身份管理：在典型的企業部署中，用戶標識由一個集中式目錄所提供。因此，無論我們在何處部署群集，都應當通過聯合用戶標識的控制，以方便實現一致性的管控與應用。
• 訪問控制：雖然 Kubernetes 并沒有用戶的概念，但是它對指定的角色和權限能夠提供豐富的控制。群集可以用到各種默認的角色、以及指定了權限集的自定義角色。重要的是：同一個企業內部的所有群集都應當使用通用的角色定義，和跨集群的管理方法。

雖然上述每一項安全實踐都可以被單獨地使用，但是我們還是應該全面地審查和規劃那些跨多種云供應商時的安全策略。

我們可以通過使用諸如 AquaSec、Twistlock 等安全解決方案，以及其他與 Nirmata、OpenShift 等平臺相結合的措施來實現。

集中應用管理

與安全性相同，在 Kubernetes 的群集上管理各種應用也需要具有集中且一致性的方案。Kubernetes 提供了一整套可用于定義和操作不同應用程序的構造。

由于確實具有一些應用程序的內置理念，因此它能夠靈活地支持不同的應用類型，并允許在 Kubernetes 上以不同的方式構建出不同的應用平臺。

當然，Kubernetes 的應用管理平臺也提供了一些通用的屬性和功能。下面列舉了對 Kubernetes 工作負載予以集中式應用管理所需要考慮的方面：

應用程序建模與定義

用戶需要通過定義其應用的組件，從而在現有組件的基礎上撰寫出新的應用。用戶可以通過 Kubernetes 的聲明性，來定義系統的目標狀態。

Kubernetes 的工作負載 API 提供了幾種構造，來定義所需的資源狀態。

例如：我們可以使用部署來建模出無狀態的工作負載組件。這些定義通常被寫成一組 YAML 或 JSON 的清單。當然，開發人員也可以運用諸如 Git 之類的版本控制系統（Version Control System，VCS）來組織和管理這些清單。

開發人員只需定義和管理應用清單中的一些部分，而其他部分則可以由運營團隊來指定操作的策略和特定的運行環境。因此，我們可以將應用清單理解為在部署和更新之前所動態地生成的一個管道。

Helm 是一款輔助 Kubernetes 進行包管理的工具。它能夠方便地對應用進行分組、版本控制、部署和更新。

Kubernetes 應用平臺必須分別從開發和運營的不同關注點出發，提供簡單的方法來建模、組織和構造應用清單、以及 Helm Charts。

而平臺還必須提供對不同定義的驗證，以便盡早捕獲各種常見的錯誤，同時還能以簡單方法重用那些應用的定義。

應用程序運營環境管理

應用程序在完成建模與驗證之后，就需要被部署到群集之中。由于我們的最終目標是在不同的工作負載中重用這些群集，以提高效率和節約成本。因此，我們最好將應用程序的運行環境與群集進行解耦，并將通用的策略和控制應用到環境之中。

由于 Kubernetes 允許使用命名空間和網絡策略來創建虛擬群集，因此 Kubernetes 的應用平臺應當能夠方便地利用這些構造，來創建具有邏輯分割與隔離、以及資源控制的環境。

變更管理

在多數情況下，運行環境具有持久性，因此我們需要以可控方式對其進行變更。而這些變更往往源自編譯系統或交付管道中的上游環境。

Kubernetes 應用平臺需要為 CI/CD（持續集成和持續交付）工具提供各種集成，并監控外部存儲庫的更改。

一旦檢測到變更，它們就應當根據不同環境下變更管理的策略，對其進行驗證和處理。當然，用戶也可審查變更、接受更改、或完全依賴自動化的更新進程。

應用程序監視

不同的應用程序會被運行在多個環境、和多種群集之中。從監控的角度而言，我們需要設法給傳遞的消息去噪，從而能聚焦到應用程序的實例之上。

因此，我們需要將應用程序的指標、狀態和事件關聯到運行環境的構造上。

同時，Kubernetes 應用平臺還須將監控與自動化的細粒度標簽相集成，以便用戶深入地查看到任何環境中的應用實例。

應用程序日志記錄

與監控類似，日志數據也需要將應用的定義和運行環境信息相關聯，并且能夠被任何應用組件所訪問到。Kubernetes 應用平臺必須能夠對不同運行組件上的日志進行流轉和聚合。

如果您用到了集中式日志系統，那么就必須對應用予以必要的標記，以便將日志從不同的應用與環境中分離出來，同時也能實現跨團隊與用戶的訪問管理。

警報與通知

為了實現服務級別的管理，我們必須能夠根據任何指標數值、狀態變更或不同條件，來自定義警報。同樣，我們可以根據相關性來區分出需要立即采取行動與可以延遲處置的警報。

例如：如果同一應用程序被部署運行在多個環境（如開發測試、暫存和生產環境）中，我們就必須能定義只在生產工作負載上被觸發的警報規則。 

Kubernetes 應用平臺必須具備環境和應用的感知能力，從而提供對細粒度警報規則的定義和管理。

遠程訪問

由于云服務環境是動態的，而容器又將這種動態提升到了新的水平。因此，一旦有問題被檢測和報告，我們就必須能夠快速地訪問到系統中那些受到影響的組件。

而 Kubernetes 應用平臺則必須提供一種方法，能在運行的容器中啟動 shell ，訪問容器運行環境的詳細信息，而不必通過 VPN 和 SSH 去訪問各種云服務的實例。

事件管理

通常在 Kubernetes 的應用中，有可能會出現容器的退出和重啟。這種退出可能是正常工作流（如升級）的一部分，也可能是由于內存不足等錯誤所造成的。

Kubernetes 應用平臺必須能夠識別故障，并捕獲故障的所有詳細信息，進而采取離線的分析與排障。

總結

容器和 Kubernetes 使得企業能夠利用一組通用的行業最佳實踐，來對跨多種云服務的應用程序進行操作和管理。

所有主流的云服務供應商和應用平臺，都相繼承諾可以支持 Kubernetes 了。

在他們之中，有以“開發人員提供代碼工件，平臺負責其余部分”為模式的平臺即服務（Platform-as-a-Service，PaaS）方案；也有以“開發人員提供容器鏡像，平臺負責其余部分”為模式的容器即服務（Container-as-a-Service，CaaS）方案；還有以“開發人員只需提供功能函數，平臺負責其余部分”為模式的功能即服務（Functions-as-a-Service，FaaS）方案。可以說，Kubernetes 已成為了新的云原生操作系統。

因此，在開發多種云服務模式的 Kubernetes 策略時，企業必須周全地考慮到：他們希望如何去使用基礎架構服務、如何管理 Kubernetes 的組件版本、如何設計與管理Kubernetes群集、如何定義公共安全層、以及如何管理好應用。

原文標題：Best Practices for Multi-Cloud Kubernetes作者：Jim Bugwadia

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】