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

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

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

思考并建立現代架構

正如50年前蓋房子的方法和風格，與現代建筑有著顯著不同，構建軟件也是如此，應當盡可能使用新的工具及方法。

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

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

Osnat建議道，“為了最大程度利用容器技術，可以把我們的應用程序設計為微服務架構，確保其中單一容器進行刷新時仍可正常運行。同時，還應該進行結構化設計，以便容器鏡像只代表獨立發布的單元，從而實現有效的CI/CD機制。”

“現代”開發往往通過多種方式進行定義。如果要為容器及Kubernetes構建應用程序，那么就要選擇合適的打包與技術部署選型。下面來看另外兩個示例：

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

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

充分發揮CI/CD與自動化的力量

自動化是容器編排體系中的一大關鍵特征，也幾乎成為構建容器內運行的各類應用程序的核心要素。如果沒有自動化，現代應用的運營負擔很可能難以承受。

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

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

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

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

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

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

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

不要盲目信任鏡像

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

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

起步階段就要計劃可觀察性、遙測與監控機制

故障，是容器與微服務的一部分，當然，這里更多強調的是故障管理，而非徹底避免故障。Kubernetes的自我修復功能無疑是該其核心吸引力之一，但也要求用戶擁有適當的可見性。在這一領域，可觀察性、遙測與監控機制就成了最關鍵的能力。

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

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

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

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

考慮從無狀態應用程序起步

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

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

Parmer指出，可擴展性是在Kubernetes上運行容器的主要優勢，而使用無狀態應用程序更有利于發揮這項優勢。

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

構建容器化不容易

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