首次部署 Kubernetes 應(yīng)用程序需注意的“陷阱”

根據(jù)我的個(gè)人經(jīng)驗(yàn)，大多數(shù)人似乎傾向于通過 Helm 或者手動(dòng)方式將應(yīng)用程序甩給 Kubernetes，之后就坐等每天輕松調(diào)用的美好生活。但在 GumGum 公司的實(shí)踐當(dāng)中，我們體會(huì)到 Kubernetes 應(yīng)用的一系列“陷阱”，也希望把這些陷阱與大家分享，給您的 Kubernetes 探索之旅帶來一點(diǎn)啟發(fā)。

1. 配置 Pod 請(qǐng)求與限制

我們從配置一套可以運(yùn)行 Pod 的簡(jiǎn)單環(huán)境開始。Kubernetes 在處理 Pod 調(diào)度與故障狀態(tài)方面確實(shí)表現(xiàn)出色，但我們也意識(shí)到，如果 Kubernetes 調(diào)度程序無法衡量 Pod 的成功運(yùn)行究竟需要多少資源，那么有時(shí)候部署工作可能面臨挑戰(zhàn)。而這一挑戰(zhàn)，也正是資源請(qǐng)求與限制機(jī)制的設(shè)計(jì)根源。目前，設(shè)置應(yīng)用程序請(qǐng)求與限制方面的最佳實(shí)踐仍然存在不少爭(zhēng)議。實(shí)際上，這項(xiàng)工作更像是一門藝術(shù)，而非單純的科學(xué)。下面，我們聊聊 GumGum 公司內(nèi)部對(duì)這個(gè)問題的看法：

Pod 請(qǐng)求： 這是調(diào)度程序用于衡量 Pod 最佳部署方法的主要指標(biāo)。

下面來看 Kubernetes 說明文檔中的相關(guān)描述：

過濾步驟會(huì)在可行的情況下找到一組 Pod。例如，PodFitsResources 過濾器會(huì)檢查候選節(jié)點(diǎn)是否具備充足的可用資源，以滿足 Pod 提出的特定資源請(qǐng)求。

在內(nèi)部，我們通過這樣一種方式使用應(yīng)用程序請(qǐng)求：通過設(shè)置，我們對(duì)應(yīng)用程序正常運(yùn)行實(shí)際工作負(fù)載時(shí)的資源需求做出估計(jì)。以此為基礎(chǔ)，調(diào)度程序即可更合理地放置節(jié)點(diǎn)。最初，我們希望將請(qǐng)求設(shè)置得更高一些，保證各個(gè) Pod 都擁有充足的資源。但我們很快發(fā)現(xiàn)，這種方式會(huì)大大增加調(diào)度時(shí)間，并導(dǎo)致部分 Pod 無法完全調(diào)度。這樣的結(jié)果實(shí)際上與我們完全不指定資源請(qǐng)求時(shí)看到的情況類似：在后一種情況下，由于控制平面并不清楚應(yīng)用程序需要多少資源，因此調(diào)度程序經(jīng)常會(huì)“逐出”Pod 且不再重新加以調(diào)度。正是這一調(diào)度算法中的關(guān)鍵組成部分，導(dǎo)致我們無法得到符合預(yù)期的調(diào)度效果。

Pod 限制： 即對(duì)于 Pod 的直接限制，代表著集群允許各容器所使用的最大資源量。

同樣來看官方說明文檔中的描述：

如果您為容器設(shè)置了 4GiB 的內(nèi)存限制，則 kubelet（與容器運(yùn)行時(shí)）將強(qiáng)制執(zhí)行此限制。運(yùn)行時(shí)將防止容器使用超出所配置上限的資源容量。例如，當(dāng)容器中的進(jìn)程所消耗的內(nèi)存量超過獲準(zhǔn)數(shù)量時(shí)，系統(tǒng)內(nèi)核將終止該資源分配嘗試，并提示內(nèi)存不足（OOM）錯(cuò)誤。

容器所使用的實(shí)際資源量可以高于其請(qǐng)求，但永遠(yuǎn)不能高于配置上限。很明顯，對(duì)限制指標(biāo)的正確設(shè)置相當(dāng)困難，但也非常重要。在理想情況下，我們希望讓 Pod 的資源需求在整個(gè)流程生命周期內(nèi)發(fā)生變化，而又不致干擾到系統(tǒng)上的其他流程——這也正是限制機(jī)制的意義所在。遺憾的是，我們無法明確給出最合適的設(shè)置值，只能遵循以下過程進(jìn)行調(diào)整：

使用負(fù)載測(cè)試工具，我們可以模擬基準(zhǔn)流量水平，并觀察 Pod 的資源使用情況（包括內(nèi)存與 CPU）。

我們將 Pod 請(qǐng)求設(shè)置在極低水平，同時(shí)將 Pod 資源限制保持在請(qǐng)求值的約 5 倍，而后觀察其行為。當(dāng)請(qǐng)求過低時(shí)，進(jìn)程將無法啟動(dòng)，并時(shí)常引發(fā)神秘的 Go 運(yùn)行時(shí)錯(cuò)誤。

這里需要強(qiáng)調(diào)的一點(diǎn)在于，資源限制越嚴(yán)格，Pod 的調(diào)度難度也就越大。這是因?yàn)?Pod 調(diào)度要求目標(biāo)節(jié)點(diǎn)擁有充足的資源。例如，如果您的資源非常有限（內(nèi)存只有 4GB），那么即使是運(yùn)行輕量級(jí) Web 服務(wù)器進(jìn)程都很可能非常困難。在這種情況下，大家需要進(jìn)行橫向擴(kuò)展，而且各個(gè)新容器也應(yīng)運(yùn)行在同樣擁有至少 4GB 可用內(nèi)存的節(jié)點(diǎn)之上。如果不存在這樣的節(jié)點(diǎn)，您需要在集群中引入新節(jié)點(diǎn)以處理該 Pod，這無疑會(huì)令啟動(dòng)時(shí)間有所增加?？傊?，請(qǐng)務(wù)必在資源請(qǐng)求與限制之間找到最小“邊界”，保證快速、平衡實(shí)現(xiàn)擴(kuò)展。

2. 配置 Liveness 與 Readiness 探針

Kubernetes 社區(qū)中經(jīng)常討論的另一個(gè)有趣話題，就是如何配置 Linvess 與 Readiness 探針。合理使用這兩種探針，能夠?yàn)槲覀儙硪环N運(yùn)行容錯(cuò)軟件、并最大程度減少停機(jī)時(shí)間的機(jī)制。但如果配置不正確，它們也可能對(duì)應(yīng)用程序造成嚴(yán)重的性能影響。下面來看這兩種探針的基本情況，以及如何進(jìn)行使用判斷：

Liveness 探針：“用于指示容器是否正在運(yùn)行。如果 Liveness 探針失敗，則 kubelet 將關(guān)閉容器，且容器將開始執(zhí)行重新啟動(dòng)策略。如果容器并不提供 Liveness 探針，則其默認(rèn)狀態(tài)被視為成功?！薄狵ubernetes說明文檔

Liveness 探針的資源需求必須很低，因?yàn)樗鼈冃枰l繁運(yùn)行，并需要在應(yīng)用程序運(yùn)行時(shí)向 Kubernetes 發(fā)出通知。請(qǐng)注意，如果將其設(shè)置為每秒運(yùn)行一次，則系統(tǒng)將需要承擔(dān)每秒 1 次的額外請(qǐng)求處理量。因此，請(qǐng)務(wù)必認(rèn)真考慮如何處理這些額外請(qǐng)求及相應(yīng)資源。在 GumGum，我們將 Liveness 探針設(shè)置為在應(yīng)用程序主組件運(yùn)行時(shí)進(jìn)行響應(yīng)，且不考慮數(shù)據(jù)是否已經(jīng)完全可用（例如來自遠(yuǎn)程數(shù)據(jù)庫或緩存的數(shù)據(jù)）。舉例來說，我們會(huì)在應(yīng)用當(dāng)中設(shè)置一個(gè)特定的“health”端點(diǎn)，單純負(fù)責(zé)返回 200 響應(yīng)代碼。只要仍在返回響應(yīng)，就表明該進(jìn)程已經(jīng)啟動(dòng)并可以處理請(qǐng)求（但尚未正式產(chǎn)生流量）。

Readiness 探針：“指示容器是否準(zhǔn)備好處理請(qǐng)求。如果 Readiness 探針失敗，則端點(diǎn)控制器將從與該 Pod 相匹配的所有服務(wù)端點(diǎn)中，刪除該 Pod 的 IP 地址。”

Readiness 探針的運(yùn)行成本要高得多，因?yàn)槠渥饔迷谟诔掷m(xù)告知后端，整個(gè)應(yīng)用程序正處于運(yùn)行狀態(tài)且準(zhǔn)備好接收請(qǐng)求。關(guān)于此探針是否應(yīng)該訪問數(shù)據(jù)庫，社區(qū)中存在諸多爭(zhēng)論。考慮到 Readiness 探針造成的開銷（需要經(jīng)常運(yùn)行，但頻繁可以靈活調(diào)整），我們決定在某些應(yīng)用程序中只在從數(shù)據(jù)庫返回記錄后，才開始“提供流量”。通過對(duì) Readiness 探針的精心設(shè)計(jì)，我們已經(jīng)能夠?qū)崿F(xiàn)更高的可用性水平以及零停機(jī)時(shí)間部署。

但如果大家確實(shí)有必要通過應(yīng)用程序的 Readiness 探針隨時(shí)檢查數(shù)據(jù)庫請(qǐng)求的就緒狀態(tài)，請(qǐng)盡可能控制查詢操作的資源用量，例如……

SELECT small_item FROM table LIMIT 1

以下，是我們?cè)?Kubernetes 中為這兩種探針指定的配置值：

您還可以添加其他一些配置選項(xiàng)：

initialDelaySeconds- 容器啟動(dòng)的多少秒后，探針開始實(shí)際運(yùn)行

periodSeconds- 兩次探測(cè)之間的等待間隔

timeoutSeconds- 需要經(jīng)過多少秒，才能判定某一 Pod 處于故障狀態(tài)。相當(dāng)于傳統(tǒng)意義上的超時(shí)指標(biāo)

failureThreshold- 探針失敗多少次后，才向 Pod 發(fā)出重啟信號(hào)

successThreshold- 探針成功多少次后，才能判定 Pod 進(jìn)入就緒狀態(tài)（通常使用在 Pod 啟動(dòng)或者故障恢復(fù)之后）

3. 設(shè)置默認(rèn) Pod 網(wǎng)絡(luò)策略

Kubernetes 使用一種“扁平”網(wǎng)絡(luò)拓?fù)?；在默認(rèn)情況下，所有 Pod 之間都可以直接相互通信。但結(jié)合實(shí)際用例，這種通信能力往往不必要甚至不可接受。由此帶來的一大潛在安全隱患在于，如果某一易受攻擊的應(yīng)用程序遭到利用，則攻擊者即可由此獲取完全訪問權(quán)限，進(jìn)而將流量發(fā)送至網(wǎng)絡(luò)上的所有 Pod 當(dāng)中。因此我們也有必要在 Pod 網(wǎng)絡(luò)中應(yīng)用最低訪問原則，在理想情況下通過網(wǎng)絡(luò)策略明確指定哪些容器之間允許建立相互連接。

以下列簡(jiǎn)單策略為例，可以看到其將拒絕特定命名空間中的所有入口流量：

4. 通過 Hooks 與 Init 容器執(zhí)行自定義行為

我們希望在 Kubernetes 系統(tǒng)中實(shí)現(xiàn)的核心目標(biāo)之一，在于嘗試為現(xiàn)有開發(fā)人員提供近乎零停機(jī)時(shí)間的部署支持。但不同應(yīng)用程序往往擁有不同的關(guān)閉方式與資源清理過程，因此整體零停機(jī)目標(biāo)很難實(shí)現(xiàn)。首先橫亙?cè)谖覀兠媲暗?，就?Nginx 這道難關(guān)。我們注意到在啟動(dòng) Pod 的滾動(dòng)部署時(shí)，活動(dòng)連接在成功終止之前就會(huì)被丟棄。經(jīng)過廣泛的在線研究，事實(shí)證明 Kubernetes 在終止 Pod 之前，并不會(huì)等待 Nginx 用盡其連接資源。使用預(yù)停止 hook，我們得以注入此項(xiàng)功能，并由此實(shí)現(xiàn)了零停機(jī)時(shí)間。

另一個(gè)實(shí)用范例，是通過 Init 容器處理特定應(yīng)用程序的啟動(dòng)任務(wù)。部分高人氣 Kubernetes 項(xiàng)目還會(huì)使用 Istio 等 init-containers 將 Envoy 處理代碼注入 Pod 當(dāng)中。如果您在應(yīng)用程序啟動(dòng)之前，需要首先完成繁重的數(shù)據(jù)庫遷移過程，那么 Init 容器特別適用。您也可以為此過程設(shè)定更高的資源上限，保證其不受主應(yīng)用程序的限制設(shè)定影響。

另一種常見模式是向 init-conatiner 提供 secrets 訪問權(quán)，并由該容器將這些憑證公布給主 Pod，從而防止通過主應(yīng)用 Pod 本體對(duì) secret 發(fā)出示授權(quán)訪問。同樣來看說明文檔中的表述：

Init 容器能夠安全運(yùn)行實(shí)用程序或自定義代碼，避免其破壞應(yīng)用程序容器鏡像的安全性。通過剝離這些不必要的工具，您可以限制應(yīng)用程序容器鏡像的攻擊面。

5. 內(nèi)核調(diào)優(yōu)

最后，我們來聊聊一項(xiàng)最先進(jìn)的技術(shù)。Kubernetes 本身是一套高度靈活的平臺(tái)，可幫助您以最適合的方式運(yùn)行工作負(fù)載。在 GumGum，我們擁有多種高性能應(yīng)用程序，其對(duì)運(yùn)行資源有著極為苛刻的要求。在進(jìn)行了廣泛的負(fù)載測(cè)試之后，我們發(fā)現(xiàn)有某一款應(yīng)用程序難以在使用 Kubernetes 默認(rèn)設(shè)置的前提下處理必要的流量負(fù)載。但 Kubernetes 允許我們運(yùn)行一個(gè)高權(quán)限容器，通過修改為其配置適用于特定 Pod 的內(nèi)核運(yùn)行參數(shù)。通過以下示例代碼，我們修改了 Pod 中的最大開啟連接數(shù)量：

這是一種使用頻率較低的高級(jí)技術(shù)。如果您的應(yīng)用程序難以在高負(fù)載場(chǎng)景下健康運(yùn)行，大家可能需要調(diào)整其中的部分參數(shù)。這里建議各位在官方說明文檔中參閱參數(shù)調(diào)優(yōu)與可選值的相關(guān)細(xì)節(jié)信息。

6. 總結(jié)

雖然 Kubernetes 已經(jīng)算是一種幾乎“開箱即用”的解決方案，但大家仍然需要采取一系列關(guān)鍵步驟以保證應(yīng)用程序的平衡運(yùn)行。在將應(yīng)用程序遷移至 Kubernetes 之上的整個(gè)過程中，請(qǐng)務(wù)必重視負(fù)載測(cè)試“循環(huán)”——運(yùn)行應(yīng)用程序，對(duì)其進(jìn)行負(fù)載測(cè)試，觀察指標(biāo)與擴(kuò)展行為，基于結(jié)果調(diào)整您的配置，而后重復(fù)。請(qǐng)盡量客觀地設(shè)定預(yù)期流量，并嘗試將流量增加至超限水平，借此查看哪些組件會(huì)最先陷入癱瘓。通過這種迭代方法，大家也許只需要采取本文中介紹的部分步驟即可獲得理想的應(yīng)用程序運(yùn)行效果?？傊?，請(qǐng)永遠(yuǎn)關(guān)注以下幾個(gè)核心問題：

我的應(yīng)用程序的資源占用量是多少？占用量會(huì)如何變化？

服務(wù)的實(shí)際擴(kuò)展要求是什么？預(yù)計(jì)需要處理怎樣的平均流量？峰值流量處于怎樣的水平？

服務(wù)可能多久需要進(jìn)行一次橫向擴(kuò)展？新的 Pod 要過多久才能正式開始接收流量？

我們的 Pod 終止過程優(yōu)雅可控嗎？是否需要這種優(yōu)雅性與可控性？我們能否實(shí)現(xiàn)零停機(jī)時(shí)間部署？

該如何盡可能降低安全風(fēng)險(xiǎn)，并限制 Pod 入侵狀況的“爆炸半徑”（影響范圍）？服務(wù)中是否存在某些不必要的權(quán)限或訪問能力？

Kubernetes 是一套令人印象深刻的強(qiáng)大平臺(tái)，您可以在這里運(yùn)用最佳實(shí)踐為整個(gè)集群部署數(shù)千項(xiàng)服務(wù)。但不同的軟件之間總是有所差別，有時(shí)候您的應(yīng)用程序可能需要進(jìn)一步調(diào)整，好在 Kubernetes 為我們提供不少調(diào)整“旋鈕”，盡可能讓用戶輕松達(dá)成與預(yù)期相符的技術(shù)目標(biāo)。將資源請(qǐng)求與限制、Livenss 與 Readiness 檢查、init-containers、網(wǎng)絡(luò)策略以及自定義內(nèi)核調(diào)優(yōu)等方法相結(jié)合，相信大家能夠在 Kubernetes 平臺(tái)之上實(shí)現(xiàn)更出色的基準(zhǔn)性能、彈性與快速規(guī)模擴(kuò)展能力。
責(zé)編AJX