# Kubernetes資源管理
###### tags: kubernetes 10.4

運算資源管理(Compute Resources)
服務品質管制(QoS)
資源配額管理(LimitRange,ResourceQuota)

運算資源主要包括(CPU, GPU, Memory) —> 主要介紹CPU and Memory

當定義POD時沒有限制POD所佔用的CPU and Memory 數量，此時Kubernetes會認為該Pod所需要的資源很少，相對的可以安排到任何可以使用的Node上，因此當某個節點資源不充足時，例如POD負載突然加大，會使節點的資源嚴重不足情況下，避免系統掛掉，該Node會選擇『殺掉』某些使用者處理程序來釋放資源，來避免作業系統崩潰。

所以我們在設定Pod的時候需要有一套完整的資源配額限制及對應的POD服務等級機制

### 全面限制一個應用及其中的POD所能佔用的資源配額
1. 定義每一個Pod上的資源配額相關參數，比如CPU / Memory Request / Limit
2. 自動為每個沒有定義資源配額的POD增加資源配額範本(Limit Runge)
3. 從總量上限制一個租戶(應用)所能使用的資源配額的ResourceQuota.

### 定義各個POD相應的服務保證等級(QoS)
當系統資源不足時，低等級的Pod會被作業系統自動清理，以確保高等級的Pod穩定執行

一個Node所使用的CPU and Memory是一個動態的量，所以我們可以透過以下參數來設定

`spec.container[].resources.requests.cpu #容器初始要求的CPU數量`
`spec.container[].resources.limits.cpu #容器所能使用的最大CPU數量`
`spec.container[].resources.requests.memory #容器初始要求的記憶體數量`
`spec.container[].resources.limit.memory #容器所能使用的最大記憶體數量`

CPU資源是*可壓縮的*，處理程序勿論如何也不可能突破上限
Memory是*不可壓縮*的資源，因此如果設置小了，則處理程序在業務繁忙期試圖請求超過*Limit*限制的Memory時會被作業系統『殺掉』

何謂可壓縮/不可壓縮
:::info
可壓縮的，換句話說它本身無狀態，申請資源很快，也能快速正常回收；而記憶體大小是不可壓縮的，因為他是有狀態的(記憶體裡面保存著資料)，申請資源很慢(需要計算和分配記憶體區塊的空間)，並且回收可能失敗(被佔用的記憶體一般來說不可回收)。
:::
> 有哪些壓縮格式?
記憶體清理 是把它清理了 不在記憶體裡了
記憶體壓縮 是把他壓縮在記憶體裡 主要它還在記憶體裡
[記憶體壓縮是什麼？有什麼用？](https://www.796t.com/content/1550318947.html)

# 運算資源管理

### 詳解Request和Limit參數
以下圖片顯示了未設置Limit與設置request和Limit的CPU使用率區別

對於CPU或Memory而言，Pod的Request或Limit指該Pod中所以有容器(Container)的Request或Limit的總和(對於Pod中沒有設置Request和Limit的容器，該項的值被當作0或者按照叢集設定的預設值來計算)

以下針對兩種資源的特點進行說明(CPU & Memory)

1. CPU
CPU的request和Limit是透過CPU數(cpus)來計算的
2. Memory
記憶體的Request和Limit計量單位是位元組數，EX:

1KB(KiloByte) =1000 Bytes = 8000 Bits
1KiB(KibiByte) = 2^10 bytes = 1024 bytes = 8192 bits

:::info
Kubernetes的運算資源單位有大小寫之分，例如：
M可以代表十進位的1000
m代表千分之一單位 (milli unit)
所以小寫的k就不算是一個合法的資源單位
:::

### 以Request和Limit為基礎的Pod排程機制

### Request和Limit的背後機制

### 運算資源使用情況監控

### 運算資源常見問題分析