部署Kubernetes應用容易忽略的細節有哪些

這篇文章主要介紹“部署Kubernetes應用容易忽略的細節有哪些”，在日常操作中，相信很多人在部署Kubernetes應用容易忽略的細節有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”部署Kubernetes應用容易忽略的細節有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

1. 配置 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，這無疑會令啟動時間有所增加。總之，請務必在資源請求與限制之間找到最小“邊界”，保證快速、平衡實現擴展。

2. 配置 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 啟動或者故障恢復之后）

3. 設置默認 Pod 網絡策略

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

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

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

4. 通過 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 容器能夠安全運行實用程序或自定義代碼，避免其破壞應用程序容器鏡像的安全性。通過剝離這些不必要的工具，您可以限制應用程序容器鏡像的攻擊面。

5. 內核調優

最后，我們來聊聊一項最先進的技術。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應用容易忽略的細節有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！