根據我的個人經驗，大多數人似乎傾向於通過 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 的資源需求在整個流程生命週期內發生變化，而又不致干擾到系統上的其他流程——這也正是限制機制的意義所在。遺憾的是，我們無法明確給出最合適的設置值，只能遵循以下過程進行調整：
- 使用負載測試工具，我們可以模擬基準流量水平，並觀察 Pod 的資源使用情況（包括內存與 CPU）。
- 我們將 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"]
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 容器處理特定應用程序的啓動任務。部分高人氣 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 平臺之上實現更出色的基準性能、彈性與快速規模擴展能力。
原文鏈接：