為容器和 Kubernetes 建構應用程式的 7 個最佳實踐

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

當容器和 Kubernetes 變得日益普及時，我們更需要做的是保持清醒，不要被欺騙，誤認為應該使用它們來運作任何類型的應用程式。

“可以”和“應該”是有很大差別的，這在容器和 Kubernetes 的應用中也是如此：建構一個專門在容器中運作并使用 Kubernetes 對其進行操作的應用程式（有些人将其稱為雲原生開發）與将這些容器和編排用于現有的單體應用程式之間是有差別的。

對于剛開始使用容器工作的團隊來說，建構專門用于容器和 Kubernetes 的新應用程式可能是最好的起點。

Aqua Security 的戰略副總裁 Rani Osnat 說：“容器（和編排）是用于建構、部署和運作雲原生應用程式的技術工具，我通常建議那些剛開始使用容器的人使用一個全新的、簡單未開發的（greenfield）應用程式作為測試用例。”

如何開發利用 Kubernetes 在容器中運作的應用程式 ，我們請教了幾位雲原生專家，他們給出了以下七個最佳建議。

現代化的思維方式

如果今天我們要建造新房子，那麼采用的風格和方法，和 50 年前的肯定不一樣。同理，現在建構軟體也需要嘗試新的工具和方法。

SADA 首席技術官（CTO）Miles Ward 說過：“如果你要建構應用程式，請以現代的方式建構它！” 。同時，Ward 指出 微服務 和 12 要素（12-factor）方法論 是現代應用程式開發的主要方法。

Ward 指出，盡管微服務和容器可以很好地協同工作，但實際上，在某些情況下，沒有必要這樣做。同樣，微服務也經常會和 Kubernetes 放在一起，但這也不是絕對的硬性要求，單體（monolithic）方法也是可以工作的，隻有它可以水準擴充就行。12-factor 方法論也是如此。”

如果你是從頭開始建構應用程式，請優先考慮微服務的方法。

Osnat 建議：“為了最大限度地利用容器，可以把我們的應用程式設計成微服務應用程式，這樣，即使是重新整理單個容器，它也可以正常運作。同時，還應該對其進行結構化，以便容器鏡像可以表示獨立釋出的單元，進而實作高效的 CI/CD。”

“現代化”開發可以通過多種方式來定義。如果要為容器和 Kubernetes 建構應用程式，那麼就要做出适合它們的技術選型。

• 将容器鏡像定義為能夠獨立伸縮的邏輯單元：将資料庫、日志記錄、監控、負載均衡和使用者會話元件分别設定為可獨立實作的容器或容器組。
• 考慮雲原生 API：“Kubernetes 具有強大的 API 擴充機制，通過與這些工具內建，我們可以即時利用生态系統中現有的工具，比如指令行實用工具、身份驗證等等。

“大多數現代語言和架構都對容器非常友好，” Harness 的 DevOps 倡導者 Ravi Lachhman 說。“如果追溯到幾年前，像 Java 這樣的運作時都很難遵守容器邊界，并且可怕的記憶體洩露“殺手”可以任意運作。而現在，由于容器和編排系統（尤其是 Kubernetes）的普及，語言和架構已經發展成為相适應的新範式了。”

CI/CD 和自動化

自動化是容器編排的一個關鍵特征。如果我們建構了一個在 Kubernetes 上的容器中的應用程式，那麼實作自動化是必要的，否則，操作可能會不堪重負。

Brillio 的首席架構師 Chander Damodaran 表示：“如果在一開始建構自動化程度低的應用程式和服務，那麼随着服務群組件的激增，自動化可能會成為一個瓶頸。”

精心設計的 CI/CD 管道可以将自動化引入到開發和部署過程的各個階段。

“使用任何一個新的平台都需要進行大量的反複試驗和試錯。雖然使用 Kubernetes 有很多便利性，但是也會有風險。” Harness 的 Lachhman 說， “擁有一個魯棒性強的持續傳遞管道可以確定測試、安全性、變更管理政策等都是遵循建信标準的，進而確定應用程式的有效運作。”

容器鏡像盡可能保持輕量

為容器和 Kubernetes 開發應用程式的另一個關鍵原則是：為了性能、安全性及其他原因，容器鏡像越小越好。

確定删除掉應用程式不需要的所有其他軟體包，包括 shell 實用程式。

ThoughtWorks CTO 辦公室的首席技術專家 Ken Mugrage 說：“鏡像中通常會包含一些應用程式運作不需要的程式包，删除這些軟體包，隻保留我們需要的東西，不僅能夠使得鏡像更小，還可以減少安全性問題的攻擊面。”

CloudBolt 産品營銷總監 Nilesh Deo 也贊同了這一觀點：“鏡像越小，加載速度就越快，應用程式也更快。”

不要盲目地輕信鏡像

如果我們重用或重新調整現有的元件就可以達到目的，那麼就無需從頭開始建構。同樣的原理也适用于容器，但是從安全的角度來看，也不能對容器鏡像盲目信任。

有太多的人從已經安裝了某種應用程式堆棧的存儲庫中選擇鏡像。

“有太多人從已經安裝了某種應用程式堆棧的存儲庫中選擇鏡像，” Mugrage 說。“通常情況下，這些鏡像的品質不佳，而且往往還會存在不容忽視的安全性風險。我們在使用任何鏡像的時候，即使是我們自己存儲庫中的鏡像，在每次運作時都應在部署管道中對其進行掃描，以檢查漏洞和合規性。”

一開始就應計劃可觀察性、遙測和監控

Kubernetes 的自愈能力是其具有吸引力的原因之一，但同時 Kubernetes 也強調了使應用程式和環境具有适當可見性的必要性。

“故障”本質上是容器和微服務的一部分，當然這裡的指的是故障管理，而不是故障規避。這也是展現可觀察性、遙測和監控的關鍵部分。

Sentry.io 的軟體工程師 Andrei Zbikowski 說：“ Kubernetes 具有内置的彈性機制，這就需要将全面監控作為最佳實踐。它的自愈功能可以重新啟動發生故障的容器，或在不滿足某些健康參數的情況下替換并終止其他容器。雖然這一定程度上保證了應用程式的正常啟動和運作，但是也掩蓋了一些問題。”

“缺乏代碼可見性意味着應用程式随時可能抛出錯誤，即使是在健康名額顯示一切正常的時候，”Zbikowski 表示：“是以，監控應用程式以及容器和後端系統是非常重要的。全面的監控方法能提高問題和事件的可見性，以便在造成重大影響之前，及時識别和糾正錯誤。”

Mugrage 表示：“如果在投入生産之後，再嘗試對容器化應用程式進行監控，那麼結果可能不盡如人意。是以，從一開始，我們就應該考慮可觀察性和監控，尤其是分布式應用程式。”

Red Hat 技術專家 Gordon Haff 表示：“大量的雲原生技術工具箱可用于在應用程式中建構複雜的監控、跟蹤、服務網格和儀表闆，例如我們常聽到的 Prometheus、Jaeger、Kiali 和 Istio 等等。當然工具種類繁多，也會使得技術選型成為一項有挑戰性的工作。”

從無狀态應用程式開始

關于容器和 Kubernetes 的一個早期思路是：運作無狀态應用程式比運作有狀态應用程式（例如資料庫）要容易得多。随着 Kubernetes Operator 的增長，這種情況發生了變化，不過，對于剛剛接觸 Kubernetes 的團隊來說，從無狀态應用程式入手可能是更好的選擇。

Plotly 聯合創始人 Chris Parmer 表示，“從無狀态應用程式入手，通過無狀态的後端，開發團隊可以確定沒有長期運作的連接配接，以及難以擴充的可變狀态，還能在無需停機的情況下輕松部署應用程式，使得最終使用者的請求并行地傳遞到不同的容器中。”

Parmer 指出，可伸縮性是在 Kubernetes 上運作容器的主要優勢之一，而使用無狀态應用程式能更容易地實作該優勢。

“無狀态應用程式使得根據需求進行遷移和擴充變得很容易，為了滿足組織的業務需求，它允許團隊随意添加或删除容器，” Parmer 說。“通過使用建立在無狀态後端上的 Web 應用程式架構，我們可以充分利用 Kubernetes 叢集。”

建構 Kubernetes 環境很難

“如今，Kubernetes 中沒有任何抽象可以使底層系統更容易了解。它們隻會使其更易于使用。” Red Hat OpenShift 首席技術營銷經理 Chris Short 說。“當然，如果這很容易，那麼每個人就都已經做到了，行業也會從對 Kubernetes 的吹捧轉向到下一個大事件。我們在進行容器編排的同時，除了需要抽象叢集的狀态和底層的基礎架構之外，還需要管理很多其他的東西。如果你有完美建構 Kubernetes 環境的實踐經驗，歡迎分享給我們。”

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-03-27

本文作者：Kevin Casey

本文來自：“

InfoQ

”，了解相關資訊可以關注“

”