Categories
程式開發

首次部署Kubernetes 應用,總會忽略這些事


根據我的個人經驗,大多數人似乎傾向於通過Helm 或者手動方式將應用程序甩給Kubernetes,之後就坐等每天輕鬆調用的美好生活。但在GumGum 公司的實踐當中,我們體會到Kubernetes 應用的一系列“陷阱”,也希望把這些陷阱與大家分享,給您的Kubernetes 探索之旅帶來一點啟發。

配置Pod 請求與限制

我們從配置一套可以運行Pod 的簡單環境開始。 Kubernetes 在處理Pod 調度與故障狀態方面確實表現出色,但我們也意​​識到,如果Kubernetes 調度程序無法衡量Pod 的成功運行究竟需要多少資源,那麼有時候部署工作可能面臨挑戰。而這一挑戰,也正是資源請求與限制機制的設計根源。目前,設置應用程序請求與限制方面的最佳實踐仍然存在不少爭議。實際上,這項工作更像是一門藝術,而非單純的科學。下面,我們聊聊GumGum 公司內部對這個問題的看法:

Pod 請求: 這是調度程序用於衡量Pod 最佳部署方法的主要指標。

下面來看Kubernetes 說明文檔中的相關描述:

過濾步驟會在可行的情況下找到一組Pod。例如,PodFitsResources 過濾器會檢查候選節點是否具備充足的可用資源,以滿足Pod 提出的特定資源請求。

在內部,我們通過這樣一種方式使用應用程序請求:通過設置,我們對應用程序正常運行實際工作負載時的資源需求做出估計。以此為基礎,調度程序即可更合理地放置節點。最初,我們希望將請求設置得更高一些,保證各個Pod 都擁有充足的資源。但我們很快發現,這種方式會大大增加調度時間,並導致部分Pod 無法完全調度。這樣的結果實際上與我們完全不指定資源請求時看到的情況類似:在後一種情況下,由於控制平面並不清楚應用程序需要多少資源,因此調度程序經常會“逐出”Pod 且不再重新加以調度。正是這一調度算法中的關鍵組成部分,導致我們無法得到符合預期的調度效果。

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

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

如果您為容器設置了4GiB 的內存限制,則kubelet(與容器運行時)將強制執行此限制。運行時將防止容器使用超出所配置上限的資源容量。例如,當容器中的進程所消耗的內存量超過獲准數量時,系統內核將終止該資源分配嘗試,並提示內存不足(OOM)錯誤。

容器所使用的實際資源量可以高於其請求,但永遠不能高於配置上限。很明顯,對限制指標的正確設置相當困難,但也非常重要。在理想情況下,我們希望讓Pod 的資源需求在整個流程生命週期內發生變化,而又不致干擾到系統上的其他流程——這也正是限制機制的意義所在。遺憾的是,我們無法明確給出最合適的設置值,只能遵循以下過程進行調整:

  1. 使用負載測試工具,我們可以模擬基準流量水平,並觀察Pod 的資源使用情況(包括內存與CPU)。
  2. 我們將Pod 請求設置在極低水平,同時將Pod 資源限制保持在請求值的約5 倍,而後觀察其行為。當請求過低時,進程將無法啟動,並時常引發神秘的Go 運行時錯誤。

這裡需要強調的一點在於,資源限制越嚴格,Pod 的調度難度也就越大。這是因為Pod 調度要求目標節點擁有充足的資源。例如,如果您的資源非常有限(內存只有4GB),那麼即使是運行輕量級Web 服務器進程都很可能非常困難。在這種情況下,大家需要進行橫向擴展,而且各個新容器也應運行在同樣擁有至少4GB 可用內存的節點之上。如果不存在這樣的節點,您需要在集群中引入新節點以處理該Pod,這無疑會令啟動時間有所增加。總之,請務必在資源請求與限制之間找到最小“邊界”,保證快速、平衡實現擴展。

配置Liveness 與Readiness 探針

Kubernetes 社區中經常討論的另一個有趣話題,就是如何配置Linvess 與Readiness 探針。合理使用這兩種探針,能夠為我們帶來一種運行容錯軟件、並最大程度減少停機時間的機制。但如果配置不正確,它們也可能對應用程序造成嚴重的性能影響。下面來看這兩種探針的基本情況,以及如何進行使用判斷:

Liveness 探針:“用於指示容器是否正在運行。如果Liveness 探針失敗,則kubelet 將關閉容器,且容器將開始執行重新啟動策略。如果容器並不提供Liveness 探針,則其默認狀態被視為成功。”—Kubernetes說明文檔

Liveness 探針的資源需求必須很低,因為它們需要頻繁運行,並需要在應用程序運行時向Kubernetes 發出通知。請注意,如果將其設置為每秒運行一次,則係統將需要承擔每秒1 次的額外請求處理量。因此,請務必認真考慮如何處理這些額外請求及相應資源。在GumGum,我們將Liveness 探針設置為在應用程序主組件運行時進行響應,且不考慮數據是否已經完全可用(例如來自遠程數據庫或緩存的數據)。舉例來說,我們會在應用當中設置一個特定的“health”端點,單純負責返回200 響應代碼。只要仍在返迴響應,就表明該進程已經啟動並可以處理請求(但尚未正式產生流量)。

Readiness 探針:“指示容器是否準備好處理請求。如果Readiness 探針失敗,則端點控制器將從與該Pod 相匹配的所有服務端點中,刪除該Pod 的IP 地址。”

Readiness 探針的運行成本要高得多,因為其作用在於持續告知後端,整個應用程序正處於運行狀態且準備好接收請求。關於此探針是否應該訪問數據庫,社區中存在諸多爭論。考慮到Readiness 探針造成的開銷(需要經常運行,但頻繁可以靈活調整),我們決定在某些應用程序中只在從數據庫返回記錄後,才開始“提供流量”。通過對Readiness 探針的精心設計,我們已經能夠實現更高的可用性水平以及零停機時間部署。

但如果大家確實有必要通過應用程序的Readiness 探針隨時檢查數據庫請求的就緒狀態,請盡可能控制查詢操作的資源用量,例如……

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- 需要經過多少秒,才能判定某一Pod 處於故障狀態。相當於傳統意義上的超時指標
  • failureThreshold- 探針失敗多少次後,才向Pod 發出重啟信號
  • successThreshold- 探針成功多少次後,才能判定Pod 進入就緒狀態(通常使用在Pod 啟動或者故障恢復之後)

設置默認Pod

網絡策略Kubernetes 使用一種“扁平”網絡拓撲;在默認情況下,所有Pod 之間都可以直接相互通信。但結合實際用例,這種通信能力往往不必要甚至不可接受。由此帶來的一大潛在安全隱患在於,如果某一易受攻擊的應用程序遭到利用,則攻擊者即可由此獲取完全訪問權限,進而將流量發送至網絡上的所有Pod 當中。因此我們也有必要在Pod 網絡中應用最低訪問原則,在理想情況下通過網絡策略明確指定哪些容器之間允許建立相互連接。

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

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

通過Hooks 與Init 容器執行自定義行為

我們希望在Kubernetes 系統中實現的核心目標之一,在於嘗試為現有開發人員提供近乎零停機時間的部署支持。但不同應用程序往往擁有不同的關閉方式與資源清理過程,因此整體零停機目標很難實現。首先橫亙在我們面前的,就是Nginx 這道難關。我們注意到在啟動Pod 的滾動部署時,活動連接在成功終止之前就會被丟棄。經過廣泛的在線研究,事實證明Kubernetes 在終止Pod 之前,並不會等待Nginx 用盡其連接資源。使用預停止hook,我們得以注入此項功能,並由此實現了零停機時間。

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

notginx-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 容器處理特定應用程序的啟動任務。部分高人氣Kubernetes 項目還會使用Istio 等init-containers 將Envoy 處理代碼注入Pod 當中。如果您在應用程序啟動之前,需要首先完成繁重的數據庫遷移過程,那麼Init 容器特別適用。您也可以為此過程設定更高的資源上限,保證其不受主應用程序的限制設定影響。

另一種常見模式是向init-conatiner 提供secrets 訪問權,並由該容器將這些憑證公佈給主Pod,從而防止通過主應用Pod 本體對secret 發出示授權訪問。同樣來看說明文檔中的表述:

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

內核調優

最後,我們來聊聊一項最先進的技術。 Kubernetes 本身是一套高度靈活的平台,可幫助您以最適合的方式運行工作負載。在GumGum,我們擁有多種高性能應用程序,其對運行資源有著極為苛刻的要求。在進行了廣泛的負載測試之後,我們發現有某一款應用程序難以在使用Kubernetes 默認設置的前提下處理必要的流量負載。但Kubernetes 允許我們運行一個高權限容器,通過修改為其配置適用於特定Pod 的內核運行參數。通過以下示例代碼,我們修改了Pod 中的最大開啟連接數量:

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

這是一種使用頻率較低的高級技術。如果您的應用程序難以在高負載場景下健康運行,大家可能需要調整其中的部分參數。這裡建議各位在官方說明文檔中參閱參數調優與可選值的相關細節信息。

總結

雖然Kubernetes 已經算是一種幾乎“開箱即用”的解決方案,但大家仍然需要採取一系列關鍵步驟以保證應用程序的平衡運行。在將應用程序遷移至Kubernetes 之上的整個過程中,請務必重視負載測試“循環”——運行應用程序,對其進行負載測試,觀察指標與擴展行為,基於結果調整您的配置,而後重複。請盡量客觀地設定預期流量,並嘗試將流量增加至超限水平,藉此查看哪些組件會最先陷入癱瘓。通過這種迭代方法,大家也許只需要採取本文中介紹的部分步驟即可獲得理想的應用程序運行效果。總之,請永遠關注以下幾個核心問題:

  • 我的應用程序的資源佔用量是多少?佔用量會如何變化?
  • 服務的實際擴展要求是什麼?預計需要處理怎樣的平均流量?峰值流量處於怎樣的水平?
  • 服務可能多久需要進行一次橫向擴展?新的Pod 要過多久才能正式開始接收流量?
  • 我們的Pod 終止過程優雅可控嗎?是否需要這種優雅性與可控性?我們能否實現零停機時間部署?
  • 該如何盡可能降低安全風險,並限制Pod 入侵狀況的“爆炸半徑”(影響範圍)?服務中是否存在某些不必要的權限或訪問能力?

Kubernetes 是一套令人印象深刻的強大平台,您可以在這裡運用最佳實踐為整個集群部署數千項服務。但不同的軟件之間總是有所差別,有時候您的應用程序可能需要進一步調整,好在Kubernetes 為我們提供不少調整“旋鈕”,盡可能讓用戶輕鬆達成與預期相符的技術目標。將資源請求與限制、Livenss 與Readiness 檢查、init-containers、網絡策略以及自定義內核調優等方法相結合,相信大家能夠在Kubernetes 平台之上實現更出色的基準性能、彈性與快速規模擴展能力。

原文鏈接:

https://medium.com/gumgum-tech/5-things-we-overlooked-when-putting-our-first-app-on-kubernetes-58583c1783e4