iT邦幫忙

2024 iThome 鐵人賽

DAY 21
1
Kubernetes

Kubernetes圖解筆記系列 第 21

Day-21 ResourceQuota & LimitRange

  • 分享至 

  • xImage
  •  

Namespace 的資源控管,不測試看看嗎 (´・ω・`)


還是得從 create 開始(欸

kubectl create namespace <namespace-name>

建立測試用的 Namespace:demo-01
https://ithelp.ithome.com.tw/upload/images/20240922/20168437ofjlx5Ki7g.png
demo-02 是下一個 Demo 要用的,先當作沒看到...

限制資源使用量

  • ResourceQuota

    apiVersion: v1  
    kind: ResourceQuota  
    metadata:  
      name: <自定義名稱>
      namespace: <要限制的 namespace>
    spec:  
      hard:  
        requests.cpu: "1"  
       requests.memory: 1Gi  
       limits.cpu: "2"  
       limits.memory: 2Gi
        pods: 10
    
    • CPU單位:m 是指 milliCPU,未指定單位則為 vCPU
    • Memory單位:Mi(Mebibyte)和 Gi(Gibibyte)
    • Kubernetes 中的 Memory 資源使用的是二進制單位(binary units),與平時使用的十進制單位(MB, GB)有些不同。雖說也可以十進制單位設定,但為了避免混淆,較不建議這樣使用。
    • pods:可存在的非終止狀態 (Failed, Succeeded) Pod 總數上限(*註1

    以圖中的設置而言,Namespace 至少會配置 1 vCPU1 Gi 記憶體可用資源,但不可使用超過 2 vCPU2 Gi 記憶體,且不可運行多於 10 個 Pod。

    執行結果:
    https://ithelp.ithome.com.tw/upload/images/20240922/201684378BqQNCSdvR.png

  • LimitRange

    apiVersion: v1
    kind: LimitRange
    metadata:
      name: <自定義名稱>
      namespace: <要限制的 namespace>
    spec:
      limits:
      - default:
          cpu: "500m"
          memory: "512Mi"
        defaultRequest:
          cpu: "100m"
          memory: "128Mi"
        max:
          cpu: "500m"
          memory: 1Gi
        min:
          cpu: "100m"
          memory: 128Mi
        type: Container
    

    defaultdefaultRequest 感覺很容易混淆。
    兩者都是 建立 Container 如果沒有明確設定資源請求時 會帶入的預設值,但意義上不太一樣:

    • default:可用資源上限。
    • defaultRequest:保證配置資源,會影響資源要部署到哪個 node 上的決策。

來測試看看限制有沒有發揮作用吧!

先把設定值建立上去:
https://ithelp.ithome.com.tw/upload/images/20240922/201684373mwwwdtzWl.png
然後建立一個沒有預先設定資源值的 Pod:
https://ithelp.ithome.com.tw/upload/images/20240922/20168437x6FDcTYghF.png

再來確認看看 Pod 裡面的值(記得要下 --namespace 指令):

kubectl describe pod demo-pod --namespace=demo-01

https://ithelp.ithome.com.tw/upload/images/20240922/20168437ul0cWQxr2l.png
可以看到資源預設值自動被配置上去了 ( ´ ▽ ` )ノ

再來試試看建立一個超過資源限制的 Pod:
https://ithelp.ithome.com.tw/upload/images/20240922/20168437QYGm7W6Reu.png

因為自動帶入預設值: cpu limit: 500m 而建立失敗。

既然... 是因為... 有帶入預設值上限才建立失敗,

那如果強制把 limit 往上拉可以建的起來嗎?

試試看不就知道了 (⁎⁍̴̛ᴗ⁍̴̛⁎)
https://ithelp.ithome.com.tw/upload/images/20240922/20168437PWCsOTZPfn.png

建立成功啦!!!

這是因為 defaultdefaultRequest 都只針對未指定資源配置的 Container 做限制,如果自行定義就不受這兩個設定影響囉!
(但還是不能超過 ResourceQuota 的設定用量啦)

如果覺得只控制 Namespace 總量範圍太大,Container 又只有預設好像不太夠,想強行限制 Container 可以嗎?

可以的!

使用 LimitRange 的另外兩個設定值:

  • max:Container 可使用的資源上限
  • min:Container 必須配置的資源下限

調整一下 LimitRange 設定值:

apiVersion: v1
kind: LimitRange
metadata:
  name: <自定義名稱>
  namespace: <要限制的 namespace>
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "500m"
      memory: 1Gi
    min:
      cpu: "100m"
      memory: 128Mi
    type: Container

https://ithelp.ithome.com.tw/upload/images/20240922/20168437VXI0PNsyQC.png

再次建立就會因為 cpu 上限是 500m 而建立失敗了:
https://ithelp.ithome.com.tw/upload/images/20240922/20168437w1tjbikgZr.png

小結

ResourceQuotaLimitRange 都是屬於 Namespace 層級的設定,並各自針 Namespace 和 Pod/Container 做資源限制,彼此相輔相成,同時使用可以更加精確的控管 Kubernetes 的資源使用。

ResourceQuota 只針對 Namespace 總資源做控制, LimitRange 專注於 Namespace 中資源控管,除了文中的 Pod、Container,其實也可以對 PersistentVolumeClaim 做限制喔!


*註1

Pod 的狀態

終止狀態

Status Description
Succeeded Pod 中的所有 Container 都成功終止,且不會重新啟動
Failed Pod 中至少有一個 Container Exit Code 不為 0 或被系統終止
Unknown 由於某些原因無法獲取 Pod 的狀態,通常是與 Pod 所在節點通信出現問題

非終止狀態

Status Description
Pending Pod 已經由 Kubernetes 系統處理中,但 Container(s) 尚未建立完成的狀態
Running Pod 已經綁定到 Node 上,且 Pod 中所有的 Container 都已被建立。至少有一個容器正在運行,或者正處於啟動或重啟狀態。
ContainerCreating Container 正在建立中,通常是在下載 image 或設置環境。
CrashLoopBackOff Container 退出,Kubernetes 正在將它重啟。通常是應用程序錯誤或配置問題導致。

上一篇
Day-20 Namespace
下一篇
Day-22 ExternalName Service
系列文
Kubernetes圖解筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言