[kubernetes] 资源管理 ---- 资源请求和限制
當Kubernetes調度Pod時，容器是否有足夠的資源來實際運行是很重要的。 如果大型應用程序被調度到資源有限的節點上，則節點可能會耗盡內存或CPU資源，并且可能會停止工作！
?
請求和限制
請求和限制是Kubernetes用于控制CPU和內存等資源的機制。 請求是保證容器能夠得到的資源。 如果容器請求資源，Kubernetes會將其調度到可以為其提供該資源的節點上。 另一方面，限制則是確保容器的資源請求永遠不會超過某個值。 容器只允許達到限制設定的資源值，無法獲得更多資源。
重要的是要記住，限制永遠不會低于請求。 如果你試試這個，Kubernetes將拋出一個錯誤，不會讓你運行容器。
請求和限制基于單個容器。 雖然Pod通常包含一個容器，但通常也會看到Pods包含多個容器。 Pod中的每個容器都有自己的限制和請求，但由于Pod總是被認為是一個組，因此您需要將組內每個容器的限制和請求加在一起以獲取Pod的聚合值。
?
容器設置
有兩種類型的資源：CPU和內存（還有GPU卡的資源請求）
Kubernetes調度程序使用這些來確定運行Pod的位置（即哪個節點）。
如果您是在Google Kubernetes Engine中運行，則默認名稱空間已經為您設置了一些請求和限制。
這些默認設置僅僅適用于Hello World應用，更改成適合您的應用非常重要。
資源的典型Pod spec可能看起來像這樣。 這個Pod有兩個容器：
Pod中的每個容器都可以設置自己的請求和限制，這些都是附加的設置。 因此在上面的示例中，Pod的總請求為500 mCPU，內存為128 MiB，總需求為1 CPU和256MiB。
CPU
CPU資源以毫秒定義。 如果您的容器需要運行兩個完整的核心，那么您將設置值2000m。 如果您的容器只需要1/4的核心，那么您將設置一個250m的值。
關于CPU請求要記住的一件事是，如果您輸入的值大于最大節點的核心數，則永遠不會調度您的Pod。 假設您有一個需要四個核心的Pod，但您的Kubernetes群集由雙核VM組成——您的Pod將永遠不會被調度！
除非您的應用程序專門用于利用多個核心（科學計算和某些數據庫），否則通常最好將CPU請求保持在1或更低，并運行更多副本以擴展它。 這為系統提供了更大的靈活性和可靠性。
就CPU限制而言，事情其實很有趣。 CPU被認為是可壓縮資源。 如果您的應用程序開始達到您的CPU限制，Kubernetes會開始限制您的容器。 這意味著CPU將受到人為限制，使您的應用程序性能可能更差！ 但是，它不會被終止或退出。 您可以使用Liveness探針的運行狀況檢查來確保性能未受影響。
內存
內存資源以字節為單位定義。 通常，你給內存一個mebibyte值（這基本上與兆字節相同），實際上你可以提供從字節到PB的任何單位。
和CPU一樣，如果您輸入的內存請求大于節點上的內存量，則你的Pod永遠不會被調度。
與CPU資源不同，內存無法壓縮。 因為沒有辦法限制內存使用量，如果容器超過其內存限制，它將被終止。 如果您的Pod由Deployment，StatefulSet，DaemonSet或其他類型的控制器管理，則控制器會輪轉替換。
節點
請務必記住，您無法設置大于節點提供的資源的請求。 例如，如果您擁有一個雙核群集，具有2.5核心請求的Pod則永遠不會被調度到這里！
Namepsace 命名空間設置
在一個理想的世界里，Kubernetes的容器設置足以照顧好一切，但這個世界是一個黑暗而可怕的地方。 人們很容易忘記設置資源限制，或者流氓團隊可以設置非常高的請求和限制，并占用超過他們公平份額的群集。
要防止出現這些情況，可以在命名空間級別設置ResourceQuotas和LimitRanges。
ResourceQuotas
創建命名空間后，可以使用ResourceQuotas將其鎖定。ResourceQuotas非常強大，但我們只看看如何使用它們來限制CPU和內存資源的使用。
資源配額可能如下所示：
看一下這個例子，你可以看到有四個部分。 配置每個部分都是可選的。
requests.cpu是命名空間中所有容器的最大組合CPU請求（以毫秒為單位）。 在上面的示例中，您可以擁有50個具有10m請求的容器，5個具有100m請求的容器，甚至一個具有500m請求的容器。 只要命名空間中請求的總CPU和小于500m！
requests.memory是命名空間中所有容器的最大組合內存請求。 在上面的示例中，您可以擁有50個具有2MiB請求的容器，5個具有20MiB請求的容器，甚至是具有100MiB請求的單個容器。 只要命名空間中請求的總內存小于100MiB！
limits.cpu是命名空間中所有容器的最大組合CPU限制。 它就像requests.cpu，但是這里指的是限制。
limits.memory是命名空間中所有容器的最大組合內存限制。 它就像requests.memory，但是同樣地這里指的是限制。
如果您使用的是生產和開發命名空間（與每個團隊或服務的命名空間不同），則常見的模式是在生產命名空間上沒有配額，在開發命名空間上則是沒有嚴格的配額。 這使得生產能夠在流量激增的情況下獲取所需的所有資源。
LimitRange
LimitRange(簡稱limits)基于namespace的資源管理，包括pod和container的最小、最大和default、defaultrequests等。
您還可以在命名空間中創建LimitRange。 與命名空間作為整體查看的配額不同，LimitRange適用于單個容器。 這有助于防止人們在命名空間內創建超小容器或超大容器。
一旦創建limits，以后創建資源時，K8S將該limits資源限制條件默認/強制給pod，創建后發現不符合規則，將暫停創建pod。
在創建資源時，用戶可以為pod自定義資源管理限制，在創建時會去檢查和匹配limits值，發現不匹配將在創建時報錯。創建后，該pod的資源使用遵守自定義規則，而不會遵守namespace的limits限制。
LimitRange可能如下所示：
?
看一下這個例子，你可以看到有四個部分。 同樣，設置每個部分都是可選的。
default section設置容器中容器的默認限制。 如果在limitRange中設置這些值，則任何未明確設置這些值的容器都將被分配默認值。
defaultRequest section設置Pod中容器的默認請求。 如果在limitRange中設置這些值，則任何未明確設置這些值的容器都將被分配默認值。
max section將設置Pod中容器可以設置的最大限制。 默認部分不能高于此值。 同樣，在容器上設置的限制不能高于此值。 請務必注意，如果設置了此值且默認部分未設置，則任何未自行顯式設置這些值的容器都將被指定為最大值作為限制。
min section設置Pod中容器可以設置的最小請求。 defaultRequest部分不能低于此值。 同樣，在容器上設置的請求也不能低于此值。 請務必注意，如果設置了此值且defaultRequest部分未設置，則min值也將成為defaultRequest值。
?
?
每容器（type： container）
??? min：資源緊張時，最低保證可以使用的資源是： CPU 0.005個核，內存8M
??? max：資源空閑時，最大可以使用的資源是：CPU 0.25個核，內存256M
??? default：默認時，限制使用的資源是：CPU 0.2個核，內存200M
??? defaultRequest：默認時，最低保證可以使用的資源是： CPU 0.01個核，內存16M
每pod（type： pod）
??? min：最低保證可以使用的資源是： CPU 0.05個核，內存64M
??? max最大可以使用的資源是：CPU 1個核，內存1G
使用規則
1、每個namespace應該只有一個limits；
2、limits值設置：
??? 每容器（type： container）
??????? max>=default>=defaultRequest>min
??? 每pod（type： pod）
??????? max>=min
??? 整個
??????? 容器的max*容器數<=pod的max
??????? 容器的min*容器數<=pod的min
3、創建資源時，pod自定義資源限制的規則：
??? 自定義的單個request>=limits的容器的defaultrequets
??? 自定義的request的總和>=limits的pod的min
??? 自定義的單個limit<=limits的容器的requets
??? 自定義的limit的總和<=limits的pod的max
使用心得
為了防止出現創建資源失敗的情況，個人建議：
??? 1、只使用limits的pod或者container中的一種，盡量不使用同時使用，特別在pod中有多容器需求的情況下。
??? 2、盡量使用max，盡量不同時使用max和min
??? 3、由于limits會針對該namespace下的所有新建的pods，所以在該namespace下應該運行哪些資源需求相同的業務
??? 4、在復雜的limits配置下，不要在創建資源時使用自定義配置。
?
參考： http://dockone.io/article/8152
總結
以上是生活随笔為你收集整理的[kubernetes] 资源管理 ---- 资源请求和限制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 中国有哪几个证券公司
- 下一篇： [kubernetes] 资源管理 -