【51CTO.com快譯】根據(jù)2018年云計算狀況報告顯示：如今81%的企業(yè)都使用了多種云服務(wù)的模式，他們通過采用公有云服務(wù)、現(xiàn)代基礎(chǔ)構(gòu)造平臺、以及公/私有云的持續(xù)混合，在快速、靈活地調(diào)整自身規(guī)模和容量的同時，能夠更快地給客戶提供價值。實際上，根據(jù)IDC的最新數(shù)據(jù)，2018年第一季度，全球服務(wù)器出貨量同比增加了20.7%，高達270萬臺，整體收入則增長了38.6%，這是連續(xù)第三個季度達到兩位數(shù)的增長。

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

當(dāng)然，上述優(yōu)勢也帶來了一定的復(fù)雜性。容器雖然解決了DevOps的相關(guān)問題，但同時也引入了一個新的、需要管理的抽象層。由于Kubernetes本身就是一個需要管理的分布式應(yīng)用，因此它只能解決運營上的部分問題，而非全部。

我們將在本文中討論多種云服務(wù)的模式下，成功部署和運行Kubernetes群集的關(guān)鍵操作難點與優(yōu)秀實踐?？偟恼f來，我們所持的觀點是：IT運營團隊?wèi)?yīng)當(dāng)為多個內(nèi)部其他團隊構(gòu)建出一套企業(yè)級的Kubernetes整體策略。

1. 使用最佳的基礎(chǔ)設(shè)施

與傳統(tǒng)的內(nèi)部基礎(chǔ)設(shè)施供應(yīng)商相同，所有云服務(wù)供應(yīng)商都能夠提供存儲和網(wǎng)絡(luò)等方面的服務(wù)。在考慮多種云服務(wù)模式的策略時，我們值得注意的是：到底是使用各個供應(yīng)商所提供的現(xiàn)有功能?或是要用到一個抽象層。雖然這兩種方法都可行，但是您應(yīng)當(dāng)謹慎地盡量最小化抽象層、且使用供應(yīng)商自己提供的方案。

例如：不要在AWS中運行覆蓋網(wǎng)絡(luò)(overlay network，譯者注：是一種面向應(yīng)用層，而不必或減少考慮網(wǎng)絡(luò)層與物理層的網(wǎng)絡(luò)協(xié)議)，而最好去使用AWS提供的Kubernetes CNI(容器網(wǎng)絡(luò)接口，Container Network Interface)插件，為Kubernetes提供原生的網(wǎng)絡(luò)功能。此方法還可以使用諸如安全組和IAM(譯者注：身份識別與訪問管理，Identity and Access Management)等其他服務(wù)。

2. 管理自己的Kubernetes版本

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

凡事都有利弊兩面值得考慮。如果您使用供應(yīng)商去管理Kubernetes，那么他們會帶來額外的測試和驗證方面的幫助。當(dāng)然，云原生計算基金會(Cloud Native Computing Foundation，CNCF)的Kubernetes社區(qū)本身就具有成熟的開發(fā)、測試與發(fā)布流程。

Kubernetes項目是由一個特殊興趣小組(Special Interest Groups，SIGs)所管理，Release SIG(https://github.com/kubernetes/sig-release#mission)負責(zé)通過各種流程，來確保每個新版本的質(zhì)量和穩(wěn)定性。CNCF還為各個供應(yīng)商提供了Kubernetes軟件一致性(https://www.cncf.io/certification/software-conformance/)計劃，以證明他們的軟件能與Kubernetes的各個API實現(xiàn)100%兼容。

對于企業(yè)內(nèi)部而言，我們最好將穩(wěn)定的版本使用到生產(chǎn)環(huán)境之中。但是，有些團隊可能需要具有pre-GA(譯者注：pre-General Availability, 發(fā)布正式版本之前)功能的群集。因此，最好的辦法就是：讓團隊靈活地選擇多種經(jīng)過驗證的Upstream版本，或者讓他們根據(jù)需要去嘗試新的版本，但是需要風(fēng)險自擔(dān)。

3. 通過策略來規(guī)范群集的部署

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

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

雖然我們可以對每一次群集的安裝執(zhí)行上述決策，但是如果能將它們作為群集安裝的模板或策略錄入下來的話，對于我們之后的重用來說則會更為高效。例如，我們可以用到Terraform腳本(https://www.terraform.io/docs/providers/kubernetes/index.html)或Nirmata 群集策略(http://nirmata-documentation.readthedocs.io/en/latest/Clusters.html)。一旦群集安裝被予以自動化，它就可以作為高級工作流的一部分進行調(diào)用。例如：根據(jù)服務(wù)目錄，執(zhí)行自助服務(wù)的調(diào)配請求。

4. 提供端到端的安全性

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

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

雖然上述每一項安全實踐都可以被單獨地使用，但是我們還是應(yīng)該全面地審查和規(guī)劃那些跨多種云供應(yīng)商時的安全策略。我們可以通過使用諸如AquaSec、Twistlock等安全解決方案，以及其他與Nirmata、OpenShift等平臺相結(jié)合的措施來實現(xiàn)。

5. 集中應(yīng)用管理

與安全性相同，在Kubernetes的群集上管理各種應(yīng)用也需要具有集中且一致性的方案。Kubernetes提供了一整套可用于定義和操作不同應(yīng)用程序的構(gòu)造。由于確實具有一些應(yīng)用程序的內(nèi)置理念，因此它能夠靈活地支持不同的應(yīng)用類型，并允許在Kubernetes上以不同的方式構(gòu)建出不同的應(yīng)用平臺。

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

應(yīng)用程序建模與定義

用戶需要通過定義其應(yīng)用的組件，從而在現(xiàn)有組件的基礎(chǔ)上撰寫出新的應(yīng)用。用戶可以通過Kubernetes的聲明性，來定義系統(tǒng)的目標(biāo)狀態(tài)。Kubernetes的工作負載API提供了幾種構(gòu)造，來定義所需的資源狀態(tài)。

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

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

Helm是一款輔助Kubernetes進行包管理的工具。它能夠方便地對應(yīng)用進行分組、版本控制、部署和更新。Kubernetes應(yīng)用平臺必須分別從開發(fā)和運營的不同關(guān)注點出發(fā)，提供簡單的方法來建模、組織和構(gòu)造應(yīng)用清單、以及Helm Charts。而平臺還必須提供對不同定義的驗證，以便盡早捕獲各種常見的錯誤，同時還能以簡單方法重用那些應(yīng)用的定義。

應(yīng)用程序運行環(huán)境管理

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

由于Kubernetes允許使用命名空間和網(wǎng)絡(luò)策略來創(chuàng)建虛擬群集，因此Kubernetes的應(yīng)用平臺應(yīng)當(dāng)能夠方便地利用這些構(gòu)造，來創(chuàng)建具有邏輯分割與隔離、以及資源控制的環(huán)境。

變更管理

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

Kubernetes應(yīng)用平臺需要為CI/CD(持續(xù)集成和持續(xù)交付)工具提供各種集成，并監(jiān)控外部存儲庫的更改。一旦檢測到變更，它們就應(yīng)當(dāng)根據(jù)不同環(huán)境下變更管理的策略，對其進行驗證和處理。當(dāng)然，用戶也可審查變更、接受更改、或完全依賴自動化的更新進程。

應(yīng)用程序監(jiān)視

不同的應(yīng)用程序會被運行在多個環(huán)境、和多種群集之中。從監(jiān)控的角度而言，我們需要設(shè)法給傳遞的消息去噪，從而能聚焦到應(yīng)用程序的實例之上。因此，我們需要將應(yīng)用程序的指標(biāo)、狀態(tài)和事件關(guān)聯(lián)到運行環(huán)境的構(gòu)造上。同時，Kubernetes應(yīng)用平臺還須將監(jiān)控與自動化的細粒度標(biāo)簽相集成，以便用戶深入地查看到任何環(huán)境中的應(yīng)用實例。

應(yīng)用程序日志記錄

與監(jiān)控類似，日志數(shù)據(jù)也需要將應(yīng)用的定義和運行環(huán)境信息相關(guān)聯(lián)，并且能夠被任何應(yīng)用組件所訪問到。Kubernetes應(yīng)用平臺必須能夠?qū)Σ煌\行組件上的日志進行流轉(zhuǎn)和聚合。如果您用到了集中式日志系統(tǒng)，那么就必須對應(yīng)用予以必要的標(biāo)記，以便將日志從不同的應(yīng)用與環(huán)境中分離出來，同時也能實現(xiàn)跨團隊與用戶的訪問管理。

警報與通知

為了實現(xiàn)服務(wù)級別的管理，我們必須能夠根據(jù)任何指標(biāo)數(shù)值、狀態(tài)變更或不同條件，來自定義警報。同樣，我們可以根據(jù)相關(guān)性來區(qū)分出需要立即采取行動與可以延遲處置的警報。

例如：如果同一應(yīng)用程序被部署運行在多個環(huán)境(如開發(fā)測試、暫存和生產(chǎn)環(huán)境)中，我們就必須能定義只在生產(chǎn)工作負載上被觸發(fā)的警報規(guī)則。Kubernetes應(yīng)用平臺必須具備環(huán)境和應(yīng)用的感知能力，從而提供對細粒度警報規(guī)則的定義和管理。

遠程訪問

由于云服務(wù)環(huán)境是動態(tài)的，而容器又將這種動態(tài)提升到了新的水平。因此，一旦有問題被檢測和報告，我們就必須能夠快速地訪問到系統(tǒng)中那些受到影響的組件。而Kubernetes應(yīng)用平臺則必須提供一種方法，能在運行的容器中啟動shell，訪問容器運行環(huán)境的詳細信息，而不必通過VPN和SSH去訪問各種云服務(wù)的實例。

事件管理

通常在Kubernetes的應(yīng)用中，有可能會出現(xiàn)容器的退出和重啟。這種退出可能是正常工作流(如升級)的一部分，也可能是由于內(nèi)存不足等錯誤所造成的。Kubernetes應(yīng)用平臺必須能夠識別故障，并捕獲故障的所有詳細信息，進而采取離線的分析與排障。

總結(jié)

容器和Kubernetes使得企業(yè)能夠利用一組通用的行業(yè)最佳實踐，來對跨多種云服務(wù)的應(yīng)用程序進行操作和管理。所有主流的云服務(wù)供應(yīng)商和應(yīng)用平臺，都相繼承諾可以支持Kubernetes了。在他們之中，有以“開發(fā)人員提供代碼工件，平臺負責(zé)其余部分”為模式的平臺即服務(wù)(Platform-as-a-Service，PaaS)方案;也有以“開發(fā)人員提供容器鏡像，平臺負責(zé)其余部分”為模式的容器即服務(wù)(Container-as-a-Service，CaaS)方案;還有以“開發(fā)人員只需提供功能函數(shù)，平臺負責(zé)其余部分”為模式的功能即服務(wù)(Functions-as-a-Service，F(xiàn)aaS)方案?？梢哉f，Kubernetes已成為了新的云原生操作系統(tǒng)。

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

原文標(biāo)題：Best Practices for Multi-CloudKubernetes，作者：Jim Bugwadia

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】