【51CTO.com原創(chuàng)稿件】本文討論在多種云服務(wù)的模式下，成功部署和運(yùn)行 Kubernetes 群集的關(guān)鍵操作難點(diǎn)與最佳實(shí)踐。

根據(jù) 2018 年云計(jì)算狀況報(bào)告顯示：如今 81% 的企業(yè)都使用了多種云服務(wù)的模式，他們通過(guò)采用公有云服務(wù)、現(xiàn)代基礎(chǔ)構(gòu)造平臺(tái)、以及公/私有云的持續(xù)混合，在快速、靈活地調(diào)整自身規(guī)模和容量的同時(shí)，能夠更快地給客戶(hù)提供價(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)。

[[236964]]

另一個(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ì)也帶來(lái)了一定的復(fù)雜性。容器雖然解決了 DevOps 的相關(guān)問(wèn)題，但同時(shí)也引入了一個(gè)新的、需要管理的抽象層。

由于 Kubernetes 本身就是一個(gè)需要管理的分布式應(yīng)用，因此它只能解決運(yùn)營(yíng)上的部分問(wèn)題，而非全部。

我們將在本文中討論多種云服務(wù)的模式下，成功部署和運(yùn)行 Kubernetes 群集的關(guān)鍵操作難點(diǎn)與最佳實(shí)踐。

總的說(shuō)來(lái)，我們所持的觀點(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 整體策略。

使用最佳的基礎(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í)別與訪(fǎng)問(wèn)管理，Identity and Access Management）等其他服務(wù)。

管理自己的Kubernetes版本

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

凡事都有利弊兩面值得考慮。如果您使用供應(yīng)商去管理 Kubernetes，那么他們會(huì)帶來(lái)額外的測(cè)試和驗(yàn)證方面的幫助。

當(dāng)然，云原生計(jì)算基金會(huì)（Cloud Native Computing Foundation，CNCF )的 Kubernetes 社區(qū)本身就具有成熟的開(kāi)發(fā)、測(cè)試與發(fā)布流程。

Kubernetes 項(xiàng)目是由一個(gè)特殊興趣小組（Special Interest Groups，SIGs）所管理， Release SIG （https://github.com/kubernetes/sig-release#mission）負(fù)責(zé)通過(guò)各種流程，來(lái)確保每個(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)過(guò)驗(yàn)證的 Upstream 版本，或者讓他們根據(jù)需要去嘗試新的版本，但是需要風(fēng)險(xiǎn)自擔(dān)。

根據(jù)策略來(lái)規(guī)范群集的部署

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

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

雖然我們可以對(duì)每一次群集的安裝執(zhí)行上述決策，但是如果能將它們作為群集安裝的模板或策略錄入下來(lái)的話(huà)，對(duì)于我們之后的重用來(lái)說(shuō)則會(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)求。

提供端對(duì)端的安全

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

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

我們可以通過(guò)使用諸如 AquaSec、Twistlock 等安全解決方案，以及其他與 Nirmata、OpenShift 等平臺(tái)相結(jié)合的措施來(lái)實(shí)現(xiàn)。

集中應(yīng)用管理

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

由于確實(shí)具有一些應(yīng)用程序的內(nèi)置理念，因此它能夠靈活地支持不同的應(yīng)用類(lèi)型，并允許在 Kubernetes 上以不同的方式構(gòu)建出不同的應(yīng)用平臺(tái)。

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

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

用戶(hù)需要通過(guò)定義其應(yīng)用的組件，從而在現(xiàn)有組件的基礎(chǔ)上撰寫(xiě)出新的應(yīng)用。用戶(hù)可以通過(guò) Kubernetes 的聲明性，來(lái)定義系統(tǒng)的目標(biāo)狀態(tài)。

Kubernetes 的工作負(fù)載 API 提供了幾種構(gòu)造，來(lái)定義所需的資源狀態(tài)。

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

開(kāi)發(fā)人員只需定義和管理應(yīng)用清單中的一些部分，而其他部分則可以由運(yùn)營(yíng)團(tuán)隊(duì)來(lái)指定操作的策略和特定的運(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)必須分別從開(kāi)發(fā)和運(yùn)營(yíng)的不同關(guān)注點(diǎn)出發(fā)，提供簡(jiǎn)單的方法來(lái)建模、組織和構(gòu)造應(yīng)用清單、以及 Helm Charts。

而平臺(tái)還必須提供對(duì)不同定義的驗(yàn)證，以便盡早捕獲各種常見(jiàn)的錯(cuò)誤，同時(shí)還能以簡(jiǎn)單方法重用那些應(yīng)用的定義。

應(yīng)用程序運(yùn)營(yíng)環(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ò)策略來(lái)創(chuàng)建虛擬群集，因此 Kubernetes 的應(yīng)用平臺(tái)應(yīng)當(dāng)能夠方便地利用這些構(gòu)造，來(lái)創(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)然，用戶(hù)也可審查變更、接受更改、或完全依賴(lài)自動(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)簽相集成，以便用戶(hù)深入地查看到任何環(huán)境中的應(yīng)用實(shí)例。

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

與監(jiān)控類(lèi)似，日志數(shù)據(jù)也需要將應(yīng)用的定義和運(yùn)行環(huán)境信息相關(guān)聯(lián)，并且能夠被任何應(yīng)用組件所訪(fǎng)問(wèn)到。Kubernetes 應(yīng)用平臺(tái)必須能夠?qū)Σ煌\(yùn)行組件上的日志進(jìn)行流轉(zhuǎn)和聚合。

如果您用到了集中式日志系統(tǒng)，那么就必須對(duì)應(yīng)用予以必要的標(biāo)記，以便將日志從不同的應(yīng)用與環(huán)境中分離出來(lái)，同時(shí)也能實(shí)現(xiàn)跨團(tuán)隊(duì)與用戶(hù)的訪(fǎng)問(wèn)管理。

警報(bào)與通知

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

例如：如果同一應(yīng)用程序被部署運(yùn)行在多個(gè)環(huán)境（如開(kāi)發(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)程訪(fǎng)問(wèn)

由于云服務(wù)環(huán)境是動(dòng)態(tài)的，而容器又將這種動(dòng)態(tài)提升到了新的水平。因此，一旦有問(wèn)題被檢測(cè)和報(bào)告，我們就必須能夠快速地訪(fǎng)問(wèn)到系統(tǒng)中那些受到影響的組件。

而 Kubernetes 應(yīng)用平臺(tái)則必須提供一種方法，能在運(yùn)行的容器中啟動(dòng) shell ，訪(fǎng)問(wèn)容器運(yùn)行環(huán)境的詳細(xì)信息，而不必通過(guò) VPN 和 SSH 去訪(fǎng)問(wèn)各種云服務(wù)的實(shí)例。

事件管理

通常在 Kubernetes 的應(yīng)用中，有可能會(huì)出現(xiàn)容器的退出和重啟。這種退出可能是正常工作流（如升級(jí)）的一部分，也可能是由于內(nèi)存不足等錯(cuò)誤所造成的。

Kubernetes 應(yīng)用平臺(tái)必須能夠識(shí)別故障，并捕獲故障的所有詳細(xì)信息，進(jìn)而采取離線(xiàn)的分析與排障。

總結(jié)

容器和 Kubernetes 使得企業(yè)能夠利用一組通用的行業(yè)最佳實(shí)踐，來(lái)對(duì)跨多種云服務(wù)的應(yīng)用程序進(jìn)行操作和管理。

所有主流的云服務(wù)供應(yīng)商和應(yīng)用平臺(tái)，都相繼承諾可以支持 Kubernetes 了。

在他們之中，有以“開(kāi)發(fā)人員提供代碼工件，平臺(tái)負(fù)責(zé)其余部分”為模式的平臺(tái)即服務(wù)（Platform-as-a-Service，PaaS）方案；也有以“開(kāi)發(fā)人員提供容器鏡像，平臺(tái)負(fù)責(zé)其余部分”為模式的容器即服務(wù)（Container-as-a-Service，CaaS）方案；還有以“開(kāi)發(fā)人員只需提供功能函數(shù)，平臺(tái)負(fù)責(zé)其余部分”為模式的功能即服務(wù)（Functions-as-a-Service，F(xiàn)aaS）方案。可以說(shuō)，Kubernetes 已成為了新的云原生操作系統(tǒng)。

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

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

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