雖然容器與Kubernetes正在快速普及，但首先我們需要明確一點——它們并不適合構(gòu)建所有的應(yīng)用程序類型。在“可以”與“應(yīng)該”之間，大家需要建立起明確的區(qū)分。舉例來說，構(gòu)建專門在容器當(dāng)中運行、并使用Kubernetes加以編排的應(yīng)用程序(也被稱為「云原生」開發(fā))就與利用這些技術(shù)管理現(xiàn)有單體式應(yīng)用程序是有著顯著區(qū)別的。

事實上，對于剛剛邁入容器領(lǐng)域的團(tuán)隊來說，構(gòu)建專門用于容器及Kubernetes的全新應(yīng)用程序往往是比較理想的起點。Aqua Security公司戰(zhàn)略副總裁Rani Osnat表示，“容器以及編排技術(shù)屬于用于構(gòu)建、部署及運行云原生應(yīng)用程序的重要工具。我個人建議剛剛開始接觸容器技術(shù)的朋友們使用新的、比較簡單的應(yīng)用程序作為測試用例。”

關(guān)于如何運用容器與Kubernetes開發(fā)應(yīng)用，我們請教了Osnat以及其他多位云原生技術(shù)專家的觀點，整理出以下六項最佳實踐。

思考并建立現(xiàn)代架構(gòu)

正如50年前蓋房子的方法和風(fēng)格，與現(xiàn)代建筑有著顯著不同，構(gòu)建軟件也是如此，應(yīng)當(dāng)盡可能使用新的工具及方法。

SADA公司CTO Miles Ward說過，“如果您打算構(gòu)建一款應(yīng)用，請務(wù)必采用現(xiàn)代方式!”Ward還指出，微服務(wù)與十二要素方法論(12-factor) 應(yīng)該成為現(xiàn)代應(yīng)用程序開發(fā)中的核心原則。

Ward提到，盡管微服務(wù)與容器技術(shù)可以良好協(xié)同，但大多數(shù)開發(fā)場景其實并不硬性需要這種匹配。“微服務(wù)也經(jīng)常與Kubernetes被視為一體，但這絕非必要。單體式開發(fā)同樣適用，只要保證其既可以作為單體進(jìn)行部署，又可以作為同一代碼庫之上的不同端點進(jìn)行橫向擴(kuò)展即可。”Ward還強(qiáng)調(diào)，“十二要素方法論也是如此，它當(dāng)然是個良好的起點，但卻不是什么不可或缺的教條。”

Osnat建議道，“為了最大程度利用容器技術(shù)，可以把我們的應(yīng)用程序設(shè)計為微服務(wù)架構(gòu)，確保其中單一容器進(jìn)行刷新時仍可正常運行。同時，還應(yīng)該進(jìn)行結(jié)構(gòu)化設(shè)計，以便容器鏡像只代表獨立發(fā)布的單元，從而實現(xiàn)有效的CI/CD機(jī)制。”

“現(xiàn)代”開發(fā)往往通過多種方式進(jìn)行定義。如果要為容器及Kubernetes構(gòu)建應(yīng)用程序，那么就要選擇合適的打包與技術(shù)部署選型。下面來看另外兩個示例：

• 將容器鏡像定義為可以獨立擴(kuò)展的邏輯單元: 將數(shù)據(jù)庫、日志記錄、監(jiān)控、負(fù)載均衡以及用戶會話組件實現(xiàn)為容器或者容器組。
• 考慮使用云原生API：Kubernetes擁有強(qiáng)大的API擴(kuò)展機(jī)制。把其與容器工具相集成，可以立即使用生態(tài)系統(tǒng)中的現(xiàn)有解決方案選項，例如命令行實用程序以及身份驗證等。

從軟件開發(fā)的角度來看，“現(xiàn)代”同樣是件好事。Harness公司DevOps倡導(dǎo)者Ravi Lachhman表示，“對于大多數(shù)現(xiàn)代語言及框架來說，它們最佳的特性就是可以與容器順暢對接。就在幾年之前，像Java這樣還很難體現(xiàn)容器邊界。如今，隨著容器以及Kubernetes等編排工具的流行，語言及框架已經(jīng)迎來了新的發(fā)展范式。”

充分發(fā)揮CI/CD與自動化的力量

自動化是容器編排體系中的一大關(guān)鍵特征，也幾乎成為構(gòu)建容器內(nèi)運行的各類應(yīng)用程序的核心要素。如果沒有自動化，現(xiàn)代應(yīng)用的運營負(fù)擔(dān)很可能難以承受。

Brillio公司首席架構(gòu)師Chander Damodaran建議道，“以自動化方式構(gòu)建應(yīng)用程序與服務(wù)能夠顯著降低風(fēng)險水平。隨著服務(wù)與組件數(shù)量的激增，應(yīng)用及服務(wù)運營很可能成為無解的難題。”

精心設(shè)計的CI/CD管道會盡可能將自動化引入開發(fā)及部署流程中的各個階段，這也成為當(dāng)前頗為流行的一股新風(fēng)潮。我們也可以通過另一種方式理解自動化的價值：它能更輕松地消除錯誤，特別是早期開發(fā)過程中難以避免的種種錯誤。

Harness公司的Lachhman指出，“使用任何新平臺都需要大量的反復(fù)試驗，而Kubernetes本身并不足以抵消這些試驗中的潛在錯誤。只有建立起穩(wěn)健的持續(xù)交付管道，才能真正打造出可靠、可信的標(biāo)準(zhǔn)，例如測試、安全性與變更管理策略，借此保證應(yīng)用程序高效運行。”

盡可能保持容器鏡像輕量化

容器及Kubernetes開發(fā)應(yīng)用程序時的另一個關(guān)鍵原則——盡可能保證鏡像輕量化，借此滿足性能、安全性以及其他相關(guān)要求。

THoughtWorks公司CTO辦公室首席技術(shù)專家Ken Mugrage表示，“只保留您絕對需要的東西。鏡像中往往包含主體應(yīng)用程序所不需要的其他程序包。”因此，要移除應(yīng)用程序當(dāng)中不必要的所有其他軟件包——包括shell實用程序。這不僅能夠縮小鏡像體積，同時也能減少其攻擊面。

CloudBolt公司產(chǎn)品營銷負(fù)責(zé)人Nilesh Deo也贊同了這個觀點，“開發(fā)人員需要重新考慮自己的應(yīng)用開發(fā)方法。例如創(chuàng)建較小的容器與基礎(chǔ)鏡像等。鏡像越小，加載速度越快，應(yīng)用程序的運行速度也就越快。”

不要盲目信任鏡像

在軟件開發(fā)當(dāng)中，我們經(jīng)常會重用某些現(xiàn)有組件，避免“重復(fù)造輪子”。對于容器開發(fā)更是如此，不過從安全角度而言，也不能盲目相信鏡像，特別應(yīng)該對其中可能存在的安全缺陷保持警惕。

Mugrage表示，“很多人直接從repo中選擇鏡像，卻沒有注意到其中安裝有某些應(yīng)用棧。這些鏡像往往質(zhì)量不高，甚至存在不容忽視的安全問題。我們使用的任何鏡像，甚至是自有repo的鏡像，都應(yīng)在部署管道內(nèi)的每一次運行前接受掃描，檢查其漏洞與合規(guī)性。”

起步階段就要計劃可觀察性、遙測與監(jiān)控機(jī)制

故障，是容器與微服務(wù)的一部分，當(dāng)然，這里更多強(qiáng)調(diào)的是故障管理，而非徹底避免故障。Kubernetes的自我修復(fù)功能無疑是該其核心吸引力之一，但也要求用戶擁有適當(dāng)?shù)目梢娦浴Ｔ谶@一領(lǐng)域，可觀察性、遙測與監(jiān)控機(jī)制就成了最關(guān)鍵的能力。

Sentry.io公司軟件工程師Andrei Zbikowski指出，“Kubernetes具有內(nèi)置彈性機(jī)制，符合全面監(jiān)控方面的最佳實踐要求。其自我修復(fù)功能可以在某些參數(shù)不滿足健康要求時，重新啟動存在故障的容器、或者終止并替換其他的容器。這項功能雖然可以讓應(yīng)用程序長期保持正常運行，但也掩蓋了一些其他的問題。”

Zbikowski補(bǔ)充道，缺乏對代碼的可見性，可能導(dǎo)致應(yīng)用程序隨時拋出錯誤，但管理者卻因為運行指標(biāo)的一切正常而誤以為萬事大吉，“監(jiān)控應(yīng)用程序以及容器/后端系統(tǒng)非常重要。全面的監(jiān)控方法必須有能力提高問題的廣泛可見性，以便在重大影響發(fā)生之前，識別并糾正問題。”

Mugrage指出， “在起步階段，大家就應(yīng)該考慮到可觀察性與監(jiān)控需求。對分布式應(yīng)用程序進(jìn)行故障排查往往極為困難，這方面需求必須被包含在應(yīng)用程序設(shè)計當(dāng)中。后續(xù)添加的監(jiān)管解決方案，往往效果不佳。”

紅帽公司技術(shù)專業(yè)布道師Gordon Haff表示，“使用多種云原生技術(shù)工具方案，可以在應(yīng)用程序當(dāng)中建立起復(fù)雜的監(jiān)控、跟蹤、服務(wù)網(wǎng)格以及儀表板。例如Prometheus、Jaeger、Kiali以及Istio等等都在此列，不過，工具種類繁多，這也讓技術(shù)選型成為一項挑戰(zhàn)。”

考慮從無狀態(tài)應(yīng)用程序起步

一般而言，運行無狀態(tài)應(yīng)用程序，往往比運行有狀態(tài)應(yīng)用程序(例如數(shù)據(jù)庫)要容易得多。隨著Kubernetes運營商的增加，情況開始有所不同。不過，對于剛剛上手Kubernetes的團(tuán)隊來說，運行無狀態(tài)應(yīng)用程序可能是更好的選擇。

Plotly公司聯(lián)合創(chuàng)始人Chris Parmer指出，“如果只能挑選一條最佳實踐的話，我建議從無狀態(tài)應(yīng)用程序入手，通過無狀態(tài)后端，開發(fā)團(tuán)隊可以確保沒有需要長期運行的連接，或者可變狀態(tài)，從而極大降低擴(kuò)展的難度。開發(fā)人員還能夠在零停機(jī)時間的前提下，輕松部署應(yīng)用程序，確保最終用戶的請求可以并行被傳遞至不同的容器處。”

Parmer指出，可擴(kuò)展性是在Kubernetes上運行容器的主要優(yōu)勢，而使用無狀態(tài)應(yīng)用程序更有利于發(fā)揮這項優(yōu)勢。

“無狀態(tài)應(yīng)用程序意味著開發(fā)團(tuán)隊能夠更輕松地遷移及擴(kuò)展容器以滿足組織的業(yè)務(wù)需求，包括隨意添加或刪除容器。通過使用基于無狀態(tài)后端的Web應(yīng)用程序框架，我們可以從Kubernetes集群當(dāng)中獲取最大收益。”Parmer說。

構(gòu)建容器化不容易

時至今日，Kubernetes中仍然沒有哪種抽象可以讓其底層系統(tǒng)變得真正易于理解——或者說，目前的方案只能使其更易于使用。紅帽O(jiān)penShift首席技術(shù)營銷經(jīng)理Chris Short指出，“這當(dāng)然不容易，否則每個人都能打造出Kubernetes了。我們在進(jìn)行容器編排的同時，還消除集群狀態(tài)及底層基礎(chǔ)設(shè)施的「存在感」，甚至消除了管理方面的需求。Etcd是一個巨大的Kubernetes依賴項，很多廠商都在想辦法將其隱藏起來。Kubernetes涉及網(wǎng)絡(luò)、安全性以及其他一系列復(fù)雜內(nèi)容。只有做好失敗的準(zhǔn)備，您的團(tuán)隊才能真正邁出探索Kubernetse的腳步，為迎接真正的「現(xiàn)代」架構(gòu)擺正心態(tài)。”