文章來源于公眾號：架構(gòu)頭條 作者：Julian Gindi
根據(jù)筆者的個人經(jīng)驗，大部分人好像喜歡通過 Helm 或者手動方式將應(yīng)用程序甩給 Kubernetes，然后就可以每天坐等輕松調(diào)用的美好生活。但在 GumGum 公司的實踐當(dāng)中，我們體會到 Kubernetes 應(yīng)用的一系列“陷阱”，也希望把這些陷阱與大家分享，給您的 Kubernetes 探索之旅帶來一點啟發(fā)。
1. 配置 Pod 請求與限制
我們從配置一套可以運行 Pod 的簡單環(huán)境開始。Kubernetes 在處理 Pod 調(diào)度與故障狀態(tài)方面確實表現(xiàn)出色，但我們也意識到，如果 Kubernetes 調(diào)度程序無法衡量 Pod 的成功運行究竟需要多少資源，那么有時候部署工作可能面臨挑戰(zhàn)。而這一挑戰(zhàn)，也正是資源請求與限制機制的設(shè)計根源。目前，設(shè)置應(yīng)用程序請求與限制方面的最佳實踐仍然存在不少爭議。實際上，這項工作更像是一門藝術(shù)，而非單純的科學(xué)。下面，我們聊聊 GumGum 公司內(nèi)部對這個問題的看法：
Pod 請求: 這是調(diào)度程序用于衡量 Pod 最佳部署方法的主要指標(biāo)。
下面來看 Kubernetes 說明文檔中的相關(guān)描述：
過濾步驟會在可行的情況下找到一組 Pod。例如，PodFitsResources 過濾器會檢查候選節(jié)點是否具備充足的可用資源，以滿足 Pod 提出的特定資源請求。
在內(nèi)部，我們通過這樣一種方式使用應(yīng)用程序請求：通過設(shè)置，我們對應(yīng)用程序正常運行實際工作負(fù)載時的資源需求做出估計。以此為基礎(chǔ)，調(diào)度程序即可更合理地放置節(jié)點。最初，我們希望將請求設(shè)置得更高一些，保證各個 Pod 都擁有充足的資源。但我們很快發(fā)現(xiàn)，這種方式會大大增加調(diào)度時間，并導(dǎo)致部分 Pod 無法完全調(diào)度。這樣的結(jié)果實際上與我們完全不指定資源請求時看到的情況類似：在后一種情況下，由于控制平面并不清楚應(yīng)用程序需要多少資源，因此調(diào)度程序經(jīng)常會“逐出”Pod 且不再重新加以調(diào)度。正是這一調(diào)度算法中的關(guān)鍵組成部分，導(dǎo)致我們無法得到符合預(yù)期的調(diào)度效果。
Pod 限制: 即對于 Pod 的直接限制，代表著集群允許各容器所使用的最大資源量。
同樣來看官方說明文檔中的描述:
如果您為容器設(shè)置了 4GiB 的內(nèi)存限制，則 kubelet（與容器運行時）將強制執(zhí)行此限制。運行時將防止容器使用超出所配置上限的資源容量。例如，當(dāng)容器中的進(jìn)程所消耗的內(nèi)存量超過獲準(zhǔn)數(shù)量時，系統(tǒng)內(nèi)核將終止該資源分配嘗試，并提示內(nèi)存不足（OOM）錯誤。
容器所使用的實際資源量可以高于其請求，但永遠(yuǎn)不能高于配置上限。很明顯，對限制指標(biāo)的正確設(shè)置相當(dāng)困難，但也非常重要。在理想情況下，我們希望讓 Pod 的資源需求在整個流程生命周期內(nèi)發(fā)生變化，而又不致干擾到系統(tǒng)上的其他流程——這也正是限制機制的意義所在。遺憾的是，我們無法明確給出最合適的設(shè)置值，只能遵循以下過程進(jìn)行調(diào)整：
- 使用負(fù)載測試工具，我們可以模擬基準(zhǔn)流量水平，并觀察 Pod 的資源使用情況（包括內(nèi)存與 CPU）。
- 我們將 Pod 請求設(shè)置在極低水平，同時將 Pod 資源限制保持在請求值的約 5 倍，而后觀察其行為。當(dāng)請求過低時，進(jìn)程將無法啟動，并時常引發(fā)神秘的 Go 運行時錯誤。
這里需要強調(diào)的一點在于，資源限制越嚴(yán)格，Pod 的調(diào)度難度也就越大。這是因為 Pod 調(diào)度要求目標(biāo)節(jié)點擁有充足的資源。例如，如果您的資源非常有限（內(nèi)存只有 4GB），那么即使是運行輕量級 Web 服務(wù)器進(jìn)程都很可能非常困難。在這種情況下，大家需要進(jìn)行橫向擴展，而且各個新容器也應(yīng)運行在同樣擁有至少 4GB 可用內(nèi)存的節(jié)點之上。如果不存在這樣的節(jié)點，您需要在集群中引入新節(jié)點以處理該 Pod，這無疑會令啟動時間有所增加。總之，請務(wù)必在資源請求與限制之間找到最小“邊界”，保證快速、平衡實現(xiàn)擴展。
2. 配置 Liveness 與 Readiness 探針
Kubernetes 社區(qū)中經(jīng)常討論的另一個有趣話題，就是如何配置 Linvess 與 Readiness 探針。合理使用這兩種探針，能夠為我們帶來一種運行容錯軟件、并最大程度減少停機時間的機制。但如果配置不正確，它們也可能對應(yīng)用程序造成嚴(yán)重的性能影響。下面來看這兩種探針的基本情況，以及如何進(jìn)行使用判斷：
Liveness 探針:“用于指示容器是否正在運行。如果 Liveness 探針失敗，則 kubelet 將關(guān)閉容器，且容器將開始執(zhí)行重新啟動策略。如果容器并不提供 Liveness 探針，則其默認(rèn)狀態(tài)被視為成功。”—Kubernetes說明文檔
Liveness 探針的資源需求必須很低，因為它們需要頻繁運行，并需要在應(yīng)用程序運行時向 Kubernetes 發(fā)出通知。請注意，如果將其設(shè)置為每秒運行一次，則系統(tǒng)將需要承擔(dān)每秒 1 次的額外請求處理量。因此，請務(wù)必認(rèn)真考慮如何處理這些額外請求及相應(yīng)資源。在 GumGum，我們將 Liveness 探針設(shè)置為在應(yīng)用程序主組件運行時進(jìn)行響應(yīng)，且不考慮數(shù)據(jù)是否已經(jīng)完全可用（例如來自遠(yuǎn)程數(shù)據(jù)庫或緩存的數(shù)據(jù)）。舉例來說，我們會在應(yīng)用當(dāng)中設(shè)置一個特定的“health”端點，單純負(fù)責(zé)返回 200 響應(yīng)代碼。只要仍在返回響應(yīng)，就表明該進(jìn)程已經(jīng)啟動并可以處理請求（但尚未正式產(chǎn)生流量）。
Readiness 探針:“指示容器是否準(zhǔn)備好處理請求。如果 Readiness 探針失敗，則端點控制器將從與該 Pod 相匹配的所有服務(wù)端點中，刪除該 Pod 的 IP 地址?！?/p>
Readiness 探針的運行成本要高得多，因為其作用在于持續(xù)告知后端，整個應(yīng)用程序正處于運行狀態(tài)且準(zhǔn)備好接收請求。關(guān)于此探針是否應(yīng)該訪問數(shù)據(jù)庫，社區(qū)中存在諸多爭論。考慮到 Readiness 探針造成的開銷（需要經(jīng)常運行，但頻繁可以靈活調(diào)整），我們決定在某些應(yīng)用程序中只在從數(shù)據(jù)庫返回記錄后，才開始“提供流量”。通過對 Readiness 探針的精心設(shè)計，我們已經(jīng)能夠?qū)崿F(xiàn)更高的可用性水平以及零停機時間部署。
但如果大家確實有必要通過應(yīng)用程序的 Readiness 探針隨時檢查數(shù)據(jù)庫請求的就緒狀態(tài)，請盡可能控制查詢操作的資源用量，例如……
SELECT small_item FROM table LIMIT 1以下，是我們在 Kubernetes 中為這兩種探針指定的配置值：
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2您還可以添加其他一些配置選項：
- initialDelaySeconds- 容器啟動的多少秒后，探針開始實際運行
- periodSeconds- 兩次探測之間的等待間隔
- timeoutSeconds- 需要經(jīng)過多少秒，才能判定某一 Pod 處于故障狀態(tài)。相當(dāng)于傳統(tǒng)意義上的超時指標(biāo)
- failureThreshold- 探針失敗多少次后，才向 Pod 發(fā)出重啟信號
- successThreshold- 探針成功多少次后，才能判定 Pod 進(jìn)入就緒狀態(tài)（通常使用在 Pod 啟動或者故障恢復(fù)之后）
3. 設(shè)置默認(rèn) Pod 網(wǎng)絡(luò)策略
Kubernetes 使用一種“扁平”網(wǎng)絡(luò)拓?fù)?；在默認(rèn)情況下，所有 Pod 之間都可以直接相互通信。但結(jié)合實際用例，這種通信能力往往不必要甚至不可接受。由此帶來的一大潛在安全隱患在于，如果某一易受攻擊的應(yīng)用程序遭到利用，則攻擊者即可由此獲取完全訪問權(quán)限，進(jìn)而將流量發(fā)送至網(wǎng)絡(luò)上的所有 Pod 當(dāng)中。因此我們也有必要在 Pod 網(wǎng)絡(luò)中應(yīng)用最低訪問原則，在理想情況下通過網(wǎng)絡(luò)策略明確指定哪些容器之間允許建立相互連接。
以下列簡單策略為例，可以看到其將拒絕特定命名空間中的所有入口流量：
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress4. 通過 Hooks 與 Init 容器執(zhí)行自定義行為
我們希望在 Kubernetes 系統(tǒng)中實現(xiàn)的核心目標(biāo)之一，在于嘗試為現(xiàn)有開發(fā)人員提供近乎零停機時間的部署支持。但不同應(yīng)用程序往往擁有不同的關(guān)閉方式與資源清理過程，因此整體零停機目標(biāo)很難實現(xiàn)。首先橫亙在我們面前的，就是 Nginx 這道難關(guān)。我們注意到在啟動 Pod 的滾動部署時，活動連接在成功終止之前就會被丟棄。經(jīng)過廣泛的在線研究，事實證明 Kubernetes 在終止 Pod 之前，并不會等待 Nginx 用盡其連接資源。使用預(yù)停止 hook，我們得以注入此項功能，并由此實現(xiàn)了零停機時間。
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另一個實用范例，是通過 Init 容器處理特定應(yīng)用程序的啟動任務(wù)。部分高人氣 Kubernetes 項目還會使用 Istio 等 init-containers 將 Envoy 處理代碼注入 Pod 當(dāng)中。如果您在應(yīng)用程序啟動之前，需要首先完成繁重的數(shù)據(jù)庫遷移過程，那么 Init 容器特別適用。您也可以為此過程設(shè)定更高的資源上限，保證其不受主應(yīng)用程序的限制設(shè)定影響。
另一種常見模式是向 init-conatiner 提供 secrets 訪問權(quán)，并由該容器將這些憑證公布給主 Pod，從而防止通過主應(yīng)用 Pod 本體對 secret 發(fā)出示授權(quán)訪問。同樣來看說明文檔中的表述：
Init 容器能夠安全運行實用程序或自定義代碼，避免其破壞應(yīng)用程序容器鏡像的安全性。通過剝離這些不必要的工具，您可以限制應(yīng)用程序容器鏡像的攻擊面。
5. 內(nèi)核調(diào)優(yōu)
最后，我們來聊聊一項最先進(jìn)的技術(shù)。Kubernetes 本身是一套高度靈活的平臺，可幫助您以最適合的方式運行工作負(fù)載。在 GumGum，我們擁有多種高性能應(yīng)用程序，其對運行資源有著極為苛刻的要求。在進(jìn)行了廣泛的負(fù)載測試之后，我們發(fā)現(xiàn)有某一款應(yīng)用程序難以在使用 Kubernetes 默認(rèn)設(shè)置的前提下處理必要的流量負(fù)載。但 Kubernetes 允許我們運行一個高權(quán)限容器，通過修改為其配置適用于特定 Pod 的內(nèi)核運行參數(shù)。通過以下示例代碼，我們修改了 Pod 中的最大開啟連接數(shù)量：
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]這是一種使用頻率較低的高級技術(shù)。如果您的應(yīng)用程序難以在高負(fù)載場景下健康運行，大家可能需要調(diào)整其中的部分參數(shù)。這里建議各位在官方說明文檔中參閱參數(shù)調(diào)優(yōu)與可選值的相關(guān)細(xì)節(jié)信息。
6. 總結(jié)
雖然 Kubernetes 已經(jīng)算是一種幾乎“開箱即用”的解決方案，但大家仍然需要采取一系列關(guān)鍵步驟以保證應(yīng)用程序的平衡運行。在將應(yīng)用程序遷移至 Kubernetes 之上的整個過程中，請務(wù)必重視負(fù)載測試“循環(huán)”——運行應(yīng)用程序，對其進(jìn)行負(fù)載測試，觀察指標(biāo)與擴展行為，基于結(jié)果調(diào)整您的配置，而后重復(fù)。請盡量客觀地設(shè)定預(yù)期流量，并嘗試將流量增加至超限水平，借此查看哪些組件會最先陷入癱瘓。通過這種迭代方法，大家也許只需要采取本文中介紹的部分步驟即可獲得理想的應(yīng)用程序運行效果。總之，請永遠(yuǎn)關(guān)注以下幾個核心問題：
- 我的應(yīng)用程序的資源占用量是多少？占用量會如何變化？
- 服務(wù)的實際擴展要求是什么？預(yù)計需要處理怎樣的平均流量？峰值流量處于怎樣的水平？
- 服務(wù)可能多久需要進(jìn)行一次橫向擴展？新的 Pod 要過多久才能正式開始接收流量？
- 我們的 Pod 終止過程優(yōu)雅可控嗎？是否需要這種優(yōu)雅性與可控性？我們能否實現(xiàn)零停機時間部署？
- 該如何盡可能降低安全風(fēng)險，并限制 Pod 入侵狀況的“爆炸半徑”（影響范圍）？服務(wù)中是否存在某些不必要的權(quán)限或訪問能力？
Kubernetes 是一套令人印象深刻的強大平臺，您可以在這里運用最佳實踐為整個集群部署數(shù)千項服務(wù)。但不同的軟件之間總是有所差別，有時候您的應(yīng)用程序可能需要進(jìn)一步調(diào)整，好在 Kubernetes 為我們提供不少調(diào)整“旋鈕”，盡可能讓用戶輕松達(dá)成與預(yù)期相符的技術(shù)目標(biāo)。將資源請求與限制、Livenss 與 Readiness 檢查、init-containers、網(wǎng)絡(luò)策略以及自定義內(nèi)核調(diào)優(yōu)等方法相結(jié)合，相信大家能夠在 Kubernetes 平臺之上實現(xiàn)更出色的基準(zhǔn)性能、彈性與快速規(guī)模擴展能力。
以上就是W3Cschool編程獅關(guān)于第一次部署 Kubernetes 應(yīng)用，容易忽略的細(xì)節(jié)的相關(guān)介紹了，希望對大家有所幫助。
