[[319759]]

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

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

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

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

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

1. 現代化的思維方式

如果今天我們要建造新房子，那么采用的風格和方法，和 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）的普及，語言和框架已經發展成為相適應的新范式了。”

2. CI/CD 和自動化

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

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

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

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

3. 容器鏡像盡可能保持輕量

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

確保刪除掉應用程序不需要的所有其他軟件包，包括 shell 實用程序。

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

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

4. 不要盲目地輕信鏡像

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

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

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

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

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

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

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

“缺乏代碼可見性意味著應用程序隨時可能拋出錯誤，即使是在健康指標顯示一切正常的時候，”Zbikowski 表示：“因此，監控應用程序以及容器和后端系統是非常重要的。全面的監控方法能提高問題和事件的可見性，以便在造成重大影響之前，及時識別和糾正錯誤。”

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

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

6. 從無狀態應用程序開始

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

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

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

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

7. 構建 Kubernetes 環境很難

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