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

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

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

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

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

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

例如：不要在AWS中運(yùn)行覆蓋網(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(譯者注：身份識(shí)別與訪問管理，Identity and Access Management)等其他服務(wù)。

2. 管理自己的Kubernetes版本

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

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

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

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

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

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

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

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

4. 提供端到端的安全性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

變更管理

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

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

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

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

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

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

警報(bào)與通知

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

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

遠(yuǎn)程訪問

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

事件管理

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

總結(jié)

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

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

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

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