摘要:本文介紹幾種在中限制資源使用的幾種方法。其位置在舉例方法二在中限定方法一雖然很好,但是其不是強(qiáng)制性的,因此很容易出現(xiàn)因忘記設(shè)定,導(dǎo)致資源使用過度的情形,因此我們需要一種全局性的資源限制設(shè)定,以防止這種情況發(fā)生。
本文介紹幾種在K8S中限制資源使用的幾種方法。
資源類型在K8S中可以對兩類資源進(jìn)行限制:cpu和內(nèi)存。
CPU的單位有:
正實(shí)數(shù),代表分配幾顆CPU,可以是小數(shù)點(diǎn),比如0.5代表0.5顆CPU,意思是一顆CPU的一半時(shí)間。2代表兩顆CPU。
正整數(shù)m,也代表1000m=1,所以500m等價(jià)于0.5。
內(nèi)存的單位:
正整數(shù),直接的數(shù)字代表Byte
k、K、Ki,Kilobyte
m、M、Mi,Megabyte
g、G、Gi,Gigabyte
t、T、Ti,Terabyte
p、P、Pi,Petabyte
方法一:在Pod Container Spec中設(shè)定資源限制在K8S中,對于資源的設(shè)定是落在Pod里的Container上的,主要有兩類,limits控制上限,requests控制下限。其位置在:
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
舉例:
</>復(fù)制代碼
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: ...
image: ...
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
方法二:在Namespace中限定
方法一雖然很好,但是其不是強(qiáng)制性的,因此很容易出現(xiàn)因忘記設(shè)定limits/request,導(dǎo)致Host資源使用過度的情形,因此我們需要一種全局性的資源限制設(shè)定,以防止這種情況發(fā)生。K8S通過在Namespace設(shè)定LimitRange來達(dá)成這一目的。
配置默認(rèn)request/limit:如果配置里默認(rèn)的request/limit,那么當(dāng)Pod Spec沒有設(shè)定request/limit的時(shí)候,會(huì)使用這個(gè)配置,有效避免無限使用資源的情況。
配置位置在:
spec.limits[].default.cpu,default limit
spec.limits[].default.memory,同上
spec.limits[].defaultRequest.cpu,default request
spec.limits[].defaultRequest.memory,同上
例子:
</>復(fù)制代碼
apiVersion: v1
kind: LimitRange
metadata:
name:
spec:
limits:
- default:
memory: 512Mi
cpu: 1
defaultRequest:
memory: 256Mi
cpu: 0.5
type: Container
配置request/limit的約束
我們還可以在K8S里對request/limit進(jìn)行以下限定:
某資源的request必須>=某值
某資源的limit必須<=某值
這樣的話就能有效避免Pod Spec中亂設(shè)limit導(dǎo)致資源耗盡的情況,或者亂設(shè)request導(dǎo)致Pod無法得到足夠資源的情況。
配置位置在:
spec.limits[].max.cpu,limit必須<=某值
spec.limits[].max.memory,同上
spec.limits[].min.cpu,request必須>=某值
spec.limits[].min.memory,同上
例子:
</>復(fù)制代碼
apiVersion: v1
kind: LimitRange
metadata:
name:
spec:
limits:
- max:
memory: 1Gi
cpu: 800m
min:
memory: 500Mi
cpu: 200m
type: Container
參考資料
Managing Compute Resources for Containers
Configure Default Memory Requests and Limits for a Namespace
Configure Default CPU Requests and Limits for a Namespace
Configure Minimum and Maximum Memory Constraints for a Namespace
Configure Minimum and Maximum CPU Constraints for a Namespace
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/32732.html
摘要:本文介紹幾種在中限制資源使用的幾種方法。其位置在舉例方法二在中限定方法一雖然很好,但是其不是強(qiáng)制性的,因此很容易出現(xiàn)因忘記設(shè)定,導(dǎo)致資源使用過度的情形,因此我們需要一種全局性的資源限制設(shè)定,以防止這種情況發(fā)生。 本文介紹幾種在K8S中限制資源使用的幾種方法。 資源類型 在K8S中可以對兩類資源進(jìn)行限制:cpu和內(nèi)存。 CPU的單位有: 正實(shí)數(shù),代表分配幾顆CPU,可以是小數(shù)點(diǎn),比如...
摘要:簡介社區(qū)中常見的做法是利用來提供容器中的資源可見性。從而使得應(yīng)用獲得正確的資源約束設(shè)定。阿里云服務(wù)全球首批通過一致性認(rèn)證,簡化了集群生命周期管理,內(nèi)置了與阿里云產(chǎn)品集成,也將進(jìn)一步簡化的開發(fā)者體驗(yàn),幫助用戶關(guān)注云端應(yīng)用價(jià)值創(chuàng)新。 摘要: 這是本系列的第2篇內(nèi)容,將介紹在Docker和Kubernetes環(huán)境中解決遺留應(yīng)用無法識(shí)別容器資源限制的問題。 showImg(https://se...
摘要:為了實(shí)現(xiàn)資源被有效調(diào)度和分配時(shí)同時(shí)提高資源的利用率,采用和兩種限制類型對資源進(jìn)行分配。限制類型介紹容器使用的最小資源需求作為容器調(diào)度時(shí)資源分配的判斷依賴。 概述 kubernetes 是一個(gè)集群管理平臺(tái), kubernetes需要統(tǒng)計(jì)整體平臺(tái)的資源使用情況, 合理的將資源分配給容器使用, 并保證容器生命周期內(nèi)有足夠的資源來保證其運(yùn)行. 同時(shí), 如果資源發(fā)放是獨(dú)占的, 對于空閑的容器來說...
摘要:為了實(shí)現(xiàn)資源被有效調(diào)度和分配時(shí)同時(shí)提高資源的利用率,采用和兩種限制類型對資源進(jìn)行分配。限制類型介紹容器使用的最小資源需求作為容器調(diào)度時(shí)資源分配的判斷依賴。 概述 kubernetes 是一個(gè)集群管理平臺(tái), kubernetes需要統(tǒng)計(jì)整體平臺(tái)的資源使用情況, 合理的將資源分配給容器使用, 并保證容器生命周期內(nèi)有足夠的資源來保證其運(yùn)行. 同時(shí), 如果資源發(fā)放是獨(dú)占的, 對于空閑的容器來說...
摘要:通過監(jiān)視資源的變化,并根據(jù)的信息生成記錄寫入到中。是唯一保留的容器,依然提供健康檢查。操作會(huì)獲取最新的全量資源與本地狀態(tài)進(jìn)行比較來產(chǎn)生通知,可以避免網(wǎng)絡(luò)原因?qū)е碌膩G失通知的情況。最后一個(gè)參數(shù)用來設(shè)置處理事件的回調(diào)。 上一期我們以1.2版本為背景,介紹了K8S的服務(wù)發(fā)現(xiàn)和kube-dns插件的相關(guān)內(nèi)容。有了上一期內(nèi)容作為基礎(chǔ),這期了解最新版本的kube-dns就會(huì)容易很多。 本文主要對比...
閱讀 3196·2023-04-26 01:39
閱讀 3350·2023-04-25 18:09
閱讀 1618·2021-10-08 10:05
閱讀 3235·2021-09-22 15:45
閱讀 2780·2019-08-30 15:55
閱讀 2397·2019-08-30 15:54
閱讀 3171·2019-08-30 15:53
閱讀 1330·2019-08-29 12:32