前兩天介紹完了 Request/Limit
以及 Namespace
,聰明的小朋友很快就會對這兩個觀念有所連結,一個能聲明單一服務的資源限制而另一個可以以資源規範在其之內的資源。
在默認情況下, Kubernetes
在容器的運行上使用的資源是沒有受到限制的,而身為管理者的我們可以利用 Namespace
為單位限制資源的使用以及創建,接下來我們就要繼續深入關於資源的進階觀念 LimitRange
。
LimitRange
?
依附在 Namespace
下的 LimitRange
可以使管理員限制該 Namespace
下一個 Pod
或資源最多能夠使用資源配額所定義的 CPU 或內存用量。畢竟如果當一個 Pod
沒有被限制時,是有機會壟斷整個節點的可用資源的,而 LimitRange
即是在 Namespace
內限制資源分配的的策略對象(Policy)。
一個 LimitRange
提供的限制能夠做到:
Namespace
中實施對每個Pod 或Container 最小和最大的資源使用量的限制。Namespace
中實施對每個PersistentVolumeClaim 能申請的最小和最大的存儲空間大小的限制。Namespace
中實施對一種資源的申請值和限制值的比值的控制。Namespace
中對計算資源的默認申請/限制值,並且自動的在運行時注入到多個Container 中。說那麼多接下來就來實際操作看看吧~
kubectl create ns demo-namespace
將先建立好的 Namespace
設定為預設:
kubectl config set-context --current --namespace=demo-namespace
--------
Context "docker-desktop" modified
# limit-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: limit-range
spec:
limits:
- max:
cpu: 1000m
memory: 500Mi
min:
cpu: 500m
memory: 200Mi
type: Container
查看一下剛剛建立的 LimitRange
:
kubectl get limitrange limit-range --output=yaml
-------
.....
limits:
- default:
cpu: "1"
memory: 500Mi
defaultRequest:
cpu: 500m
memory: 200Mi
type: Container
建立了 LimitRange
後,在此 Namespace
下創建出 Pod
時,如果沒有特別聲明自己的資源配置, Kubernetes
就會依照 LimitRange
替該資源配額提供默認配置。如果該資源已有設定資源配額,而 Kubernetes
將會阻止超出規範的資源建立。
Pod
內的任何容器沒有聲明自己的請求以及限制,即為該容器設置默認的 CPU 和內存請求或限制。Pod
中的容器聲明的請求至少大於等於 limits.defaultReqeust
Pod
中的容器聲明的請求至少小於等於 limits.default
# limit-range-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: limit-range-pod
spec:
containers:
- name: default-limit-range-pod
image: nginx
建立起資源:
kubectl apply -f ./limit-range-pod.yaml
-------
pod/limit-range-pod created
查看 LimitRange
是否替我們配置了請求與限制:
kubectl get pod limit-range-pod --output=yaml
--------
....
containers:
- image: nginx
imagePullPolicy: Always
name: limit-range-pod
resources:
limits:
cpu: "1"
memory: 500Mi
requests:
cpu: 500m
memory: 200Mi
....
成功看到相關配置~
當我們嘗試著建立一個超過 LimitRange
CPU limit 的資源時, Kubernetes
將會直接返回以下類似錯誤訊息,因為其中定義了過高的 CPU limit :
Error from server (Forbidden): error when creating "examples/admin/resource/limit-range-pod.yaml":
pods "limit-range-pod" is forbidden: maximum cpu usage per Container is 800m, but limit is 1500m.
反之當我們在嘗試著建立一個不滿足 LimitRange
CPU request 的資源時,也會看到建立失敗的錯誤訊息:
Error from server (Forbidden): error when creating "examples/admin/resource/limit-range-pod.yaml":
pods "limit-range-pod" is forbidden: minimum cpu usage per Container is 200m, but request is 100m.
Namespace
使我們容易的做資源作分配,在加上 LimitRange
以及 RequestQaota
等以命名空間為單位的資源配置對象,讓我們可以靈活的位不同的部門規劃對應的資源配置。關於後者 RequestQaota
的使用方法一樣也是圍繞在 Limit/Request
上,相信這方面的觀念是一通百通,就稍微節省了一些篇幅讓各位細細的品嚐吧~ XD
千呼萬喚始出來!鐵人賽系列「從異世界歸來發現只剩自己不會 Kubernetes」同名改編作品出版了!
感謝所有交流指教的各路英雄,也感謝願意點閱文章的各位,如果能幫助到任何人都將會是我的榮幸。
本書內容改編自第 14 屆 iThome 鐵人賽 DevOps 組的優選系列文章《從異世界歸來發現只剩自己不會 Kubernetes》。此書是一本綜合性的指南,針對想要探索認識 Kubernetes 的技術人員而生。無論是初涉此領域的新手,還是已有深厚經驗的資深工程師,本書都能提供你所需的知識和技能。
「這本書不僅提供了豐富的範例程式碼和操作指南,讓身為工程師的我們能實際操作來加深認知;更重要的是,它教會我如何從後端工程師的角度去思考和應用 Kubernetes。從容器的生命週期、資源管理到部署管理,每一章都與我們的日常開發工作息息相關。」
──── 雷N │ 後端工程師 / iThome 鐵人賽戰友
天瓏連結: 從異世界歸來發現只剩自己不會 Kubernetes:初心者進入雲端世界的實戰攻略!
相關文章:
相關程式碼同時收錄在:
https://github.com/MikeHsu0618/2022-ithelp/tree/master/Day23
Reference