k8s容器資源限制方式
1. k8s容器資源限制
k8s采用request和limit兩種限制類型來對資源進(jìn)行分配
- request(資源需求):即運行pod的節(jié)點必須滿足運行pod的最基本需求才能運行pod。
- limit(資源限制):即運行pod期間,可能內(nèi)存使用量會增加,那最多能使用多少內(nèi)存,這就是資源限額。
資源類型:
- CPU的單位是核心數(shù),內(nèi)存的單位是字節(jié)。
- 一個容器申請0.5各CPU,就相當(dāng)于申請1各CPU的一半,可以加個后綴m表示千分之一的概念。比如說100m的CPU,100豪的CPU和0.1個CPU都是一樣的。
內(nèi)存單位:
- K,M,G,T,P,E #通常是以1000為換算標(biāo)準(zhǔn)的。
- Ki,Mi,Gi,Ti,Pi,Ei #通常是以1024為換算標(biāo)準(zhǔn)的。
2. 內(nèi)存資源限制
[kubeadm@server2 limit]$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo
image: stress
args:
- --vm
- "1"
- --vm-bytes
- 200M
resources:
requests:
memory: 50Mi
limits:
memory: 100Mi
- 如果容器超過其內(nèi)存限制,則會被終止。如果可重新啟動,則與其他所有類型的運行故障一樣,kubelet將重新啟動它。
- 如果一個容器超過其內(nèi)存要求,那么當(dāng)節(jié)點內(nèi)存不足時,它的pod可能被逐出。

- 當(dāng)資源限制沒沖突的時候正常啟動
[kubeadm@server1 limit]$ vim pod.yaml
[kubeadm@server1 limit]$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo
image: k8s/stress
args:
- --vm
- "1"
- --vm-bytes
- 200M
resources:
requests:
memory: 50Mi
limits:
memory: 300Mi
[kubeadm@server1 limit]$


資源限制內(nèi)部機制使用的是cgroup類型
目錄: /sys/fs/cgroup/systemd
3. cpu資源限制
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
spec:
containers:
- name: cpu-demo
image: stress
args:
- -c
- "2"
resources:
requests:
cpu: "5"
limits:
cpu: "10"
調(diào)度失敗是因為申請的CPU資源超出集群節(jié)點所能提供的資源
但CPU 使用率過高,不會被殺死


滿足要求
[kubeadm@server1 limit]$ vim cpulim.yaml
[kubeadm@server1 limit]$ cat cpulim.yaml
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
spec:
containers:
- name: cpu-demo
image: k8s/stress
args:
- -c
- "2"
resources:
requests:
cpu: "1"
limits:
cpu: "2"
[kubeadm@server1 limit]$

4. namespace設(shè)置資源限制
LimitRange資源限制
apiVersion: v1
kind: LimitRange
metadata:
name: limitrange-memory
spec:
limits:
- default:
cpu: 0.5
memory: 512Mi
defaultRequest:
cpu: 0.1
memory: 256Mi
max:
cpu: 1
memory: 1Gi
min:
cpu: 0.1
memory: 100Mi
type: Container
LimitRange 在 namespace 中施加的最小和最大內(nèi)存限制只有在創(chuàng)建和更新pod時才會被應(yīng)用。改變LimitRange不會對之前創(chuàng)建的pod有影響。
LimitRange - default xx會自動對沒有設(shè)置資源限制的pod自動添加限制

ResourceQuota設(shè)置配額限制
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-cpu-demo
spec:
hard: 硬限制
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi

一旦設(shè)置配額后,后續(xù)的容器必須設(shè)置請求(4種請求都設(shè)置),當(dāng)然,這只是在rq設(shè)置的defult的namespace中
4種請求:每個容器必須設(shè)置內(nèi)存請求(memory request),內(nèi)存限額(memory limit),cpu請求(cpu request)和cpu限額(cpu limit)
資源會統(tǒng)計總的namespace中的資源加以限定,不管是之前創(chuàng)建還是準(zhǔn)備創(chuàng)建
上述創(chuàng)建的ResourceQuota對象將在default名字空間中添加以下限制:
- 所有容器的內(nèi)存請求總額不得超過1 GiB。
- 所有容器的內(nèi)存限額總額不得超過2 GiB。
- 所有容器的CPU請求總額不得超過1 CPU。
- 所有容器的CPU限額總額不得超過2 CPU。
5. namespace中pod的配額
apiVersion: v1
kind: ResourceQuota
metadata:
name: pod-demo
spec:
hard:
pods: "2"
設(shè)置Pod配額以限制可以在namespace中運行的Pod數(shù)量。

當(dāng)然,以上設(shè)定對應(yīng)相對的namespace,其它的namespace沒有影響
為了后續(xù)不受影響,刪除相應(yīng)的設(shè)定


總結(jié)
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關(guān)文章
K8s中Pod處于Pending狀態(tài)的八種原因分析
文章詳細(xì)介紹了Pod處于Pending狀態(tài)的八種常見原因,并提供了相應(yīng)的排查和解決方法,這些原因包括資源不足、調(diào)度約束、存儲依賴、鏡像問題、配額限制、網(wǎng)絡(luò)暗礁、系統(tǒng)級異常以及冷門陷阱,每種原因都附帶了具體的診斷方法和解決建議,感興趣的朋友一起看看吧2025-02-02
k8s部署Pyroscope并分析golang性能瓶頸(最新推薦)
這篇文章主要介紹了k8s部署Pyroscope并分析golang性能瓶頸,Pyroscope支持多種編程語言并提供了豐富的性能數(shù)據(jù),可以幫助我們跟蹤應(yīng)用程序的執(zhí)行情況,并根據(jù)收集到的數(shù)據(jù)來識別性能瓶頸,需要的朋友可以參考下2023-04-04
Kubekey安裝Kubernetes-1.24.8的詳細(xì)過程
這篇文章主要介紹了Kubekey安裝Kubernetes-1.24.8的詳細(xì)過程,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-05-05

