前言
想象一下這個場景：多個系統執行在同一套 K8s 叢集上，有重要系統，也有不太重要的系統。但是某一天，某個不重要的系統突然佔用了該 K8s 叢集的所有資源，導致該叢集上的其他系統的正常執行受到影響。本文介紹了 Kubernetes 平臺如何管理容量，以及作者對管理員的注意事項和建議。
Kubernetes 資源限制概述
我們壽險瞭解 Kubernetes 平臺如何在容器和節點級別應用資源約束。 為了討論合理規模，我們將專門關注 CPU 和記憶體，儘管還有其他因素需要考慮。
可以為每個容器和 Pod 指定 resource requests 和 limits。 Requests 是為 pod 預留的有保證的資源，而 limits 則是旨在保護叢集整體架構的安全措施。 在 Kubernetes 中，pod 的 requests 和 limits 之間的關係被配置為服務質量（QoS）。 在節點上，kubelet（可以監控資源的代理）將此資訊傳遞給容器執行時，容器執行時使用核心 cgroups 來應用資源約束。
要排程新的 pod，Kubernetes 排程程式將確定可用節點上的有效位置，並考慮現有 pod 資源限制。 Kubernetes 會預配置一些系統預留，以留出資源供作業系統和 Kubernetes 系統元件使用（具體如下圖）。 剩餘量被定義為可分配的，排程程式將其視為節點的容量。 排程器可以基於所有單元的合計資源請求來排程單元到節點的容量。 請注意，所有單元的聚合資源限制可以大於節點容量，這種做法稱為超額使用（超配 or 超賣）。
在管理節點容量時，我們要儘量避免兩種情況。 在第一種情況下，實際記憶體利用率達到容量，並且 kubelet 基於驅逐訊號觸發節點壓力驅逐。 如果節點在 kubelet 可以回收記憶體之前用完記憶體，則節點 oom-killer 將做出響應，根據從每個 pod 的 QoS 計算的 oom_score_adj 值選擇要刪除的 pod。 因此，構成這些 pod 的應用程式會受到影響。
在 CPU 上過量使用的底層機制與記憶體的行為不同，因為它將 CPU 時間分配給各個容器。 高 CPU 利用率會導致 CPU 節流 (CPU throttling)，但不會觸發節點壓力驅逐，也不會自動導致 Kubernetes 終止 Pod。 但是也請注意，CPU 耗盡仍可能導致應用程式 pod 降級、活動探測失敗並重新啟動。
我們還希望避免另一種情況。 在節點級別，requests 是有保證的資源，並且必須小於容量，因為 Kubernetes 排程程式不會超額預訂。 如果 requests 明顯且始終大於實際使用的資源，則多餘的容量基本上未被使用。 雖然可能需要為高峰處理時間保留資源，但管理員應在這一點與執行可能不需要的過剩容量的重複成本之間進行平衡。 根據實際使用情況配置請求是一種平衡行為，應考慮應用程式的風險管理（平衡可用性和成本）.
Kubernetes 管理員能做啥
Kubernetes 管理員的一個主要關注點是管理和合理調整叢集容量，我們可以在 Web 上利用 Prometheus + Grafana 儀表盤和命令列捕獲叢集利用率指標，供管理員使用。
但是 Kubernetes 管理員還面臨一個棘手的大問題：正在執行的應用程式（的資源管理）。 解決特定問題的應用程式可以由不同的開發人員以不同的方式編寫，從而導致不同的效能（比如 java 編寫的可能消耗記憶體較多，golang 消耗記憶體相對較少）。 每個應用程式都是獨特的，沒有一種適合所有應用程式的方法。 管理員對開發人員的應用程式的控制能力較弱，在大型企業中，單個管理團隊可能很難接觸到眾多的開發團隊。 因此，管理員的重點應該是設定護欄，以允許開發人員（在護欄內）調整自己的應用程式。
配置 LimitRange
繞了這麼久，終於進入正題了。
為此，管理員可以為每個 NameSpace 配置不同的 LimitRanges，為開發人員提供針對各個容器和 pod 的建議大小限制。 以下是 LimitRange 的示例。 由於每個叢集和應用程式都有不同的業務和風險要求，因此各位讀者實際應用時數字會有所不同。
apiVersion: v1
kind: LimitRange
metadata:
name: "resource-limits"
spec:
limits:
- max:
cpu: "2"
memory: 4Gi
min:
cpu: 125m
memory: 128Mi
type: Pod
- default:
cpu: "0.5"
memory: 1Gi
defaultRequest:
cpu: 250m
memory: 256Mi
max:
cpu: "2"
memory: 4Gi
maxLimitRequestRatio:
cpu: "25"
memory: "4"
min:
cpu: 125m
memory: 128Mi
type: Container在 Kubernetes 中進行開發的良好實踐是建立微服務應用程式，而不是大型的巨石應用程式。 為了鼓勵微服務的開發，應該應用 limits 來約束 pod 的最大大小。 節點的物理容量可能會決定此最大大小，因為它應該可以輕鬆地容納幾個最大的 pod。 還是類似這個圖：
讓我們繼續上面的 LimitRange 示例。 最小 pod 和容器大小可能由正在執行的應用程式的需求確定，管理員不必強制執行。 為了簡單起見，我們還鼓勵開發人員在每個 pod 上執行一個容器（一個典型的例外是使用 sidecar 容器，如 Istio 的 sidecar）。 因此，上面的示例對 pod 和 container 使用相同的資源值。
預設 requests 和 limits 作為開發人員的建議值。 未顯式宣告容器大小的工作負載資源（即 pod）將繼承預設值。 作為一種好的做法，開發人員應明確定義工作負載資源中的資源請求和限制，而不採用預設值。
CPU 和記憶體的 maxLimitRequestRatio 是開發人員的突發準則。 在開發環境中，當原型應用程式經常空閒執行，但在使用時需要合理的按需資源時，高 CPU maxLimitRequestRatio 會很好地工作。 開發人員可能只在工作時間工作，在自己的 IDE 中離線編碼，偶爾測試單個微服務，或者測試 CI/CD 管道的不同階段。 相比之下，如果許多終端使用者在一天中同時訪問應用程式，您將看到更高的基準利用率。 這可能更接近您的生產環境，並可能降低 maxLimitRequestRatio（可能是事件 1：1 的請求限制）。 由於管道各階段的不同利用率模式將導致不同的請求和限制，因此在生產之前使用模擬工作負載進行測試以確定適當的單元大小非常重要。
開發人員將使用 maxLimitRequestRatio 作為適當調整大小的準則。 Kubernetes 排程程式基於資源請求做出排程決策，因此開發人員應配置資源 requests 以反映實際使用情況。 然後，基於應用程式的風險狀況，開發人員將配置 limits 以遵守 maxLimitRequestRatio。 將 maxLimitRequestRatio 設定為 1 的管理員強制開發人員將 requests 配置為等於限制，這在生產中可能是理想的，以降低風險並優先考慮穩定性。
在本文前面，我們比較了記憶體和 CPU，並描述了這兩種資源在負載下的不同行為，高記憶體可能導致 pod 逐出或從記憶體不足的情況重新啟動。 因此，最好是謹慎行事，併為不同環境的記憶體配置較低的 maxLimitRequestRatio，以防止應用程式 pod 重新啟動。 為 OpenJDK pod 配置記憶體時還應注意其他事項。 （如果沒配置相應動態調整的引數）, 容器和 pod 內部的 JVM heap 對容器的請求和限制一無所知，但應用於前者的資源約束將影響後者。
配置 ResourceQuota
管理員還可以配置 ResourceQuotas，它為 NameSpace 提供基於容量的限制，以指導開發人員根據預測的估計值來調整應用程式的規模。 下面是一個 ResourceQuota 示例。
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
limits.memory: 20Gi
requests.cpu: "4"
requests.memory: 20Gi在應用程式 NameSpace 的初始建立過程中，開發團隊應與管理員一起預測其應用程式大小並應用適當的配額。 管理員應根據服務、副本的數量和 pod 的估計大小來預測應用程式大小。 為了簡化對眾多 NameSpace 的管理，管理員可考慮類似 AWS 的方法作為起始準則，其中 small、medium、large、xlarge 應用程式被給予對應的預定配額。
應用程式跨 CI/CD 管道的各個階段進行執行，每個階段都位於不同的叢集或 NameSpace 中，並具有自己的配置配額。 在不考慮效能和高可用性的開發和測試 NameSpace 中，應用程式應配置最小的 pod，併為每個服務配置 1 個 pod 副本，以減少資源使用。 另一方面，在生產叢集或 NameSpace 中，應使用更大的 pod 和每個服務至少 2 個單元副本，以處理更高的業務量並提供高可用性。 透過使用 CI/CD 管道中的模擬工作負載進行壓力和效能測試，開發人員可以在生產釋出之前確定適當的生產 pod 大小、副本數量和配額。
管理員應針對未來的擴充套件制定配額預算，並考慮應用程式的使用模式、峰值容量和已配置的 pod 或節點的 autoscaler（如果有）。 例如，可在快速新增新微服務的開發 NameSpace、用於確定適當生產 pod 大小的效能測試 NameSpace、或使用 HPA 來調整峰值容量的生產 NameSpace 中分配附加配額。 管理員應針對上述各種情況和其他情況提供足夠的配額開銷，同時平衡基礎架構容量的風險並保護架構容量。
管理員和開發人員都應該預期會隨著時間的推移調整配額。 開發人員無需管理員的幫助即可收回配額，方法是檢視每項服務並減少 Pod requests 或 limits 以匹配實際使用量。 如果開發人員已經採取了這些步驟，但仍然需要額外的配額，那麼他們應該聯絡管理員。 管理員應將開發人員的定期配額請求作為一個機會，根據以前預測的估計值分析實際消耗量，並相應地確認或調整配額大小和新的預測估計值。
另外再介紹在調整配額大小時的一些次要注意事項。 在確定 CPU 和記憶體的配額比率時，應考慮節點容量，以便有效地利用兩者。 例如，m5.2xlarge 型別的 AWS EC2 例項為 8 個 vCPU、32 GiB RAM。 由 m5.2xlarge 節點組成的叢集可以按照每 4 GB RAM 對應 1 個 vCPU 的比例分配應用配額（不考慮節點的系統保留空間），從而高效地使用 CPU 和記憶體。 如果應用程式工作負載（即 CPU 或記憶體密集型）與節點大小不匹配，則可以考慮使用不同的節點大小。
管理員對何時應用和不應用配額的 CPU limits 一直存在爭議，這裡我們將提供一些考慮事項，而不是正式的指導。 正如我們前面所討論的，pod 的 CPU 不足會導致節流，但不一定會導致 pod 終止。 如果管理員傾向於過量使用並利用節點上的所有可用 CPU，則不應設定配額的 CPU limits。 相反，應設定配額 (resource quota) 的 CPU limits，以減少過度使用和應用程式效能風險，這可能是一個業務和成本決策，而不是技術決策。 與生產環境相比，開發環境可以容忍更高的風險和不可預測的效能，因此管理員可以考慮將 CPU limits 應用於生產而不是開發。
最後，在某些特殊情況下，不建議應用配額。 應用配額的目的是讓管理員能夠對自定義開發的應用程式的容量規劃進行一定程度的控制。 配額不應應用於 Kubernetes 自身的元件，因為這些專案需要預先配置的資源量。 出於類似的原因，配額也不應適用於第三方供應商提供的企業版應用程式。
總結
在本文中，我們介紹了 Kubernetes 平臺如何透過資源約束保護架構，包括：
- Pod 的 requests 和 limits
- Node 的資源分配
- NameSpace 級別的針對 Pod 和容器的 LimitRange
- NameSpace 級別的 ResourceQuota
並提供了在應用程式 NameSpace 中應用 limits 和 quota 的保護措施時的合理調整注意事項。 每個應用的風險偏好和 Kubernetes 叢集的容量各不相同，需要綜合考量再實施。