App下載

第一次部署 Kubernetes 應(yīng)用,容易忽略的細(xì)節(jié)

猿友 2020-09-28 16:21:06 瀏覽數(shù) (2357)
反饋

文章來(lái)源于公眾號(hào):架構(gòu)頭條 作者:Julian Gindi

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

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

我們從配置一套可以運(yùn)行 Pod 的簡(jiǎn)單環(huán)境開(kāi)始。Kubernetes 在處理 Pod 調(diào)度與故障狀態(tài)方面確實(shí)表現(xiàn)出色,但我們也意識(shí)到,如果 Kubernetes 調(diào)度程序無(wú)法衡量 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è)問(wèn)題的看法:

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

下面來(lái)看 Kubernetes 說(shuō)明文檔中的相關(guān)描述:

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

在內(nèi)部,我們通過(guò)這樣一種方式使用應(yīng)用程序請(qǐng)求:通過(guò)設(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 無(wú)法完全調(diào)度。這樣的結(jié)果實(shí)際上與我們完全不指定資源請(qǐng)求時(shí)看到的情況類似:在后一種情況下,由于控制平面并不清楚應(yīng)用程序需要多少資源,因此調(diào)度程序經(jīng)常會(huì)“逐出”Pod 且不再重新加以調(diào)度。正是這一調(diào)度算法中的關(guān)鍵組成部分,導(dǎo)致我們無(wú)法得到符合預(yù)期的調(diào)度效果。

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

同樣來(lái)看官方說(shuō)明文檔中的描述:

如果您為容器設(shè)置了 4GiB 的內(nèi)存限制,則 kubelet(與容器運(yùn)行時(shí))將強(qiáng)制執(zhí)行此限制。運(yùn)行時(shí)將防止容器使用超出所配置上限的資源容量。例如,當(dāng)容器中的進(jìn)程所消耗的內(nèi)存量超過(guò)獲準(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ī)制的意義所在。遺憾的是,我們無(wú)法明確給出最合適的設(shè)置值,只能遵循以下過(guò)程進(jìn)行調(diào)整:

  1. 使用負(fù)載測(cè)試工具,我們可以模擬基準(zhǔn)流量水平,并觀察 Pod 的資源使用情況(包括內(nèi)存與 CPU)。
  2. 我們將 Pod 請(qǐng)求設(shè)置在極低水平,同時(shí)將 Pod 資源限制保持在請(qǐng)求值的約 5 倍,而后觀察其行為。當(dāng)請(qǐng)求過(guò)低時(shí),進(jìn)程將無(wú)法啟動(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,這無(wú)疑會(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)槲覀儙?lái)一種運(yùn)行容錯(cuò)軟件、并最大程度減少停機(jī)時(shí)間的機(jī)制。但如果配置不正確,它們也可能對(duì)應(yīng)用程序造成嚴(yán)重的性能影響。下面來(lái)看這兩種探針的基本情況,以及如何進(jìn)行使用判斷:

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

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)完全可用(例如來(lái)自遠(yuǎn)程數(shù)據(jù)庫(kù)或緩存的數(shù)據(jù))。舉例來(lái)說(shuō),我們會(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 地址?!?/p>

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

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

SELECT small_item FROM table LIMIT 1

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

livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http  periodSeconds: 2

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

  • initialDelaySeconds- 容器啟動(dòng)的多少秒后,探針開(kāi)始實(shí)際運(yùn)行
  • periodSeconds- 兩次探測(cè)之間的等待間隔
  • timeoutSeconds- 需要經(jīng)過(guò)多少秒,才能判定某一 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ù)洌辉谀J(rèn)情況下,所有 Pod 之間都可以直接相互通信。但結(jié)合實(shí)際用例,這種通信能力往往不必要甚至不可接受。由此帶來(lái)的一大潛在安全隱患在于,如果某一易受攻擊的應(yīng)用程序遭到利用,則攻擊者即可由此獲取完全訪問(wèn)權(quán)限,進(jìn)而將流量發(fā)送至網(wǎng)絡(luò)上的所有 Pod 當(dāng)中。因此我們也有必要在 Pod 網(wǎng)絡(luò)中應(yīng)用最低訪問(wèn)原則,在理想情況下通過(guò)網(wǎng)絡(luò)策略明確指定哪些容器之間允許建立相互連接。

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

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress

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

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

lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]

isnginx-killer.sh:

#!/bin/bashsleep 3
PID=$(cat /run/nginx.pid)
nginx -s quitwhile [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done

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

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

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

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

最后,我們來(lái)聊聊一項(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)限容器,通過(guò)修改為其配置適用于特定 Pod 的內(nèi)核運(yùn)行參數(shù)。通過(guò)以下示例代碼,我們修改了 Pod 中的最大開(kāi)啟連接數(shù)量:

initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

6. 總結(jié)

雖然 Kubernetes 已經(jīng)算是一種幾乎“開(kāi)箱即用”的解決方案,但大家仍然需要采取一系列關(guān)鍵步驟以保證應(yīng)用程序的平衡運(yùn)行。在將應(yīng)用程序遷移至 Kubernetes 之上的整個(gè)過(guò)程中,請(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ì)最先陷入癱瘓。通過(guò)這種迭代方法,大家也許只需要采取本文中介紹的部分步驟即可獲得理想的應(yīng)用程序運(yùn)行效果??傊?,請(qǐng)永遠(yuǎn)關(guān)注以下幾個(gè)核心問(wèn)題:

  • 我的應(yīng)用程序的資源占用量是多少?占用量會(huì)如何變化?
  • 服務(wù)的實(shí)際擴(kuò)展要求是什么?預(yù)計(jì)需要處理怎樣的平均流量?峰值流量處于怎樣的水平?
  • 服務(wù)可能多久需要進(jìn)行一次橫向擴(kuò)展?新的 Pod 要過(guò)多久才能正式開(kāi)始接收流量?
  • 我們的 Pod 終止過(guò)程優(yōu)雅可控嗎?是否需要這種優(yōu)雅性與可控性?我們能否實(shí)現(xiàn)零停機(jī)時(shí)間部署?
  • 該如何盡可能降低安全風(fēng)險(xiǎn),并限制 Pod 入侵狀況的“爆炸半徑”(影響范圍)?服務(wù)中是否存在某些不必要的權(quán)限或訪問(wè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ò)展能力。

以上就是W3Cschool編程獅關(guān)于第一次部署 Kubernetes 應(yīng)用,容易忽略的細(xì)節(jié)的相關(guān)介紹了,希望對(duì)大家有所幫助。

0 人點(diǎn)贊