[[319759]]

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

“可以”和“應(yīng)該”是有很大區(qū)別的，這在容器和 Kubernetes 的應(yīng)用中也是如此：構(gòu)建一個專門在容器中運(yùn)行并使用 Kubernetes 對其進(jìn)行操作的應(yīng)用程序（有些人將其稱為云原生開發(fā)）與將這些容器和編排用于現(xiàn)有的單體應(yīng)用程序之間是有區(qū)別的。

對于剛開始使用容器工作的團(tuán)隊來說，構(gòu)建專門用于容器和 Kubernetes 的新應(yīng)用程序可能是最好的起點(diǎn)。

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

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

1. 現(xiàn)代化的思維方式

如果今天我們要建造新房子，那么采用的風(fēng)格和方法，和 50 年前的肯定不一樣。同理，現(xiàn)在構(gòu)建軟件也需要嘗試新的工具和方法。

SADA 首席技術(shù)官（CTO）Miles Ward 說過：“如果你要構(gòu)建應(yīng)用程序，請以現(xiàn)代的方式構(gòu)建它！” 。同時，Ward 指出 微服務(wù) 和 12 要素（12-factor）方法論 是現(xiàn)代應(yīng)用程序開發(fā)的主要方法。

Ward 指出，盡管微服務(wù)和容器可以很好地協(xié)同工作，但實(shí)際上，在某些情況下，沒有必要這樣做。同樣，微服務(wù)也經(jīng)常會和 Kubernetes 放在一起，但這也不是絕對的硬性要求，單體（monolithic）方法也是可以工作的，只有它可以水平擴(kuò)展就行。12-factor 方法論也是如此。”

如果你是從頭開始構(gòu)建應(yīng)用程序，請優(yōu)先考慮微服務(wù)的方法。

Osnat 建議：“為了最大限度地利用容器，可以把我們的應(yīng)用程序設(shè)計成微服務(wù)應(yīng)用程序，這樣，即使是刷新單個容器，它也可以正常運(yùn)行。同時，還應(yīng)該對其進(jìn)行結(jié)構(gòu)化，以便容器鏡像可以表示獨(dú)立發(fā)布的單元，從而實(shí)現(xiàn)高效的 CI/CD。”

“現(xiàn)代化”開發(fā)可以通過多種方式來定義。如果要為容器和 Kubernetes 構(gòu)建應(yīng)用程序，那么就要做出適合它們的技術(shù)選型。

• 將容器鏡像定義為能夠獨(dú)立伸縮的邏輯單元：將數(shù)據(jù)庫、日志記錄、監(jiān)控、負(fù)載均衡和用戶會話組件分別設(shè)置為可獨(dú)立實(shí)現(xiàn)的容器或容器組。
• 考慮云原生 API：“Kubernetes 具有強(qiáng)大的 API 擴(kuò)展機(jī)制，通過與這些工具集成，我們可以即時利用生態(tài)系統(tǒng)中現(xiàn)有的工具，比如命令行實(shí)用工具、身份驗(yàn)證等等。

“大多數(shù)現(xiàn)代語言和框架都對容器非常友好，” Harness 的 DevOps 倡導(dǎo)者 Ravi Lachhman 說。“如果追溯到幾年前，像 Java 這樣的運(yùn)行時都很難遵守容器邊界，并且可怕的內(nèi)存泄露“殺手”可以任意運(yùn)行。而現(xiàn)在，由于容器和編排系統(tǒng)（尤其是 Kubernetes）的普及，語言和框架已經(jīng)發(fā)展成為相適應(yīng)的新范式了。”

2. CI/CD 和自動化

自動化是容器編排的一個關(guān)鍵特征。如果我們構(gòu)建了一個在 Kubernetes 上的容器中的應(yīng)用程序，那么實(shí)現(xiàn)自動化是必要的，否則，操作可能會不堪重負(fù)。

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

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

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

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

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

確保刪除掉應(yīng)用程序不需要的所有其他軟件包，包括 shell 實(shí)用程序。

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

CloudBolt 產(chǎn)品營銷總監(jiān) Nilesh Deo 也贊同了這一觀點(diǎn)：“鏡像越小，加載速度就越快，應(yīng)用程序也更快。”

4. 不要盲目地輕信鏡像

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

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

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

5. 一開始就應(yīng)計劃可觀察性、遙測和監(jiān)控

Kubernetes 的自愈能力是其具有吸引力的原因之一，但同時 Kubernetes 也強(qiáng)調(diào)了使應(yīng)用程序和環(huán)境具有適當(dāng)可見性的必要性。

“故障”本質(zhì)上是容器和微服務(wù)的一部分，當(dāng)然這里的指的是故障管理，而不是故障規(guī)避。這也是體現(xiàn)可觀察性、遙測和監(jiān)控的關(guān)鍵部分。

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

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

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

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

6. 從無狀態(tài)應(yīng)用程序開始

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

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

Parmer 指出，可伸縮性是在 Kubernetes 上運(yùn)行容器的主要優(yōu)勢之一，而使用無狀態(tài)應(yīng)用程序能更容易地實(shí)現(xiàn)該優(yōu)勢。

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

7. 構(gòu)建 Kubernetes 環(huán)境很難

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