W3Cschool
恭喜您成為首批注冊(cè)用戶
獲得88經(jīng)驗(yàn)值獎(jiǎng)勵(lì)
當(dāng)你定義 Pod 時(shí)可以選擇性地為每個(gè) 容器設(shè)定所需要的資源數(shù)量。 最常見的可設(shè)定資源是 CPU 和內(nèi)存(RAM)大??;此外還有其他類型的資源。
當(dāng)你為 Pod 中的 Container 指定了資源 請(qǐng)求 時(shí), kube-scheduler 就利用該信息決定將 Pod 調(diào)度到哪個(gè)節(jié)點(diǎn)上。 當(dāng)你還為 Container 指定了資源 約束 時(shí),kubelet 就可以確保運(yùn)行的容器不會(huì)使用超出所設(shè)約束的資源。 kubelet 還會(huì)為容器預(yù)留所 請(qǐng)求 數(shù)量的系統(tǒng)資源,供其使用。
如果 Pod 運(yùn)行所在的節(jié)點(diǎn)具有足夠的可用資源,容器可能(且可以)使用超出對(duì)應(yīng)資源 ?request
? 屬性所設(shè)置的資源量。不過,容器不可以使用超出其資源 ?limit
?屬性所設(shè)置的資源量。
例如,如果你將容器的 ?memory
?的請(qǐng)求量設(shè)置為 256 MiB,而該容器所處的 Pod 被調(diào)度到一個(gè)具有 8 GiB 內(nèi)存的節(jié)點(diǎn)上,并且該節(jié)點(diǎn)上沒有其他 Pods 運(yùn)行,那么該容器就可以嘗試使用更多的內(nèi)存。
如果你將某容器的 ?memory
?約束設(shè)置為 4 GiB,kubelet (和 容器運(yùn)行時(shí)) 就會(huì)確保該約束生效。 容器運(yùn)行時(shí)會(huì)禁止容器使用超出所設(shè)置資源約束的資源。 例如:當(dāng)容器中進(jìn)程嘗試使用超出所允許內(nèi)存量的資源時(shí),系統(tǒng)內(nèi)核會(huì)將嘗試申請(qǐng)內(nèi)存的進(jìn)程終止, 并引發(fā)內(nèi)存不足(OOM)錯(cuò)誤。
約束值可以以被動(dòng)方式來實(shí)現(xiàn)(系統(tǒng)會(huì)在發(fā)現(xiàn)違例時(shí)進(jìn)行干預(yù)),或者通過強(qiáng)制生效的方式實(shí)現(xiàn) (系統(tǒng)會(huì)避免容器用量超出約束值)。不同的容器運(yùn)行時(shí)采用不同方式來實(shí)現(xiàn)相同的限制。
Note:
如果你為某個(gè)資源指定了限制,但不指定請(qǐng)求, 并且沒有應(yīng)用準(zhǔn)入時(shí)機(jī)制為該資源設(shè)置默認(rèn)請(qǐng)求, 然后 Kubernetes 復(fù)制你所指定的限制值,將其用作資源的請(qǐng)求值。
CPU 和 內(nèi)存 都是 資源類型。每種資源類型具有其基本單位。 CPU 表達(dá)的是計(jì)算處理能力,其單位是 Kubernetes CPUs。 內(nèi)存的單位是字節(jié)。 對(duì)于 Linux 負(fù)載,則可以指定巨頁(yè)(Huge Page)資源。 巨頁(yè)是 Linux 特有的功能,節(jié)點(diǎn)內(nèi)核在其中分配的內(nèi)存塊比默認(rèn)頁(yè)大小大得多。
例如,在默認(rèn)頁(yè)面大小為 4KiB 的系統(tǒng)上,你可以指定約束 ?hugepages-2Mi: 80Mi
?。 如果容器嘗試分配 40 個(gè) 2MiB 大小的巨頁(yè)(總共 80 MiB ),則分配請(qǐng)求會(huì)失敗。
Note:
你不能過量使用 ?hugepages- *
? 資源。 這與 ?memory
?和 ?cpu
?資源不同。
CPU 和內(nèi)存統(tǒng)稱為“計(jì)算資源”,或簡(jiǎn)稱為“資源”。 計(jì)算資源的數(shù)量是可測(cè)量的,可以被請(qǐng)求、被分配、被消耗。 它們與 API 資源 不同。 API 資源(如 Pod 和 Service)是可通過 Kubernetes API 服務(wù)器讀取和修改的對(duì)象。
針對(duì)每個(gè)容器,你都可以指定其資源約束和請(qǐng)求,包括如下選項(xiàng):
spec.containers[].resources.limits.cpu
?spec.containers[].resources.limits.memory
?spec.containers[].resources.limits.hugepages-<size>
?spec.containers[].resources.requests.cpu
?spec.containers[].resources.requests.memory
?spec.containers[].resources.requests.hugepages-<size>
?盡管你只能逐個(gè)容器地指定請(qǐng)求和限制值,考慮 Pod 的總體資源請(qǐng)求和約束也是有用的。 對(duì)特定資源而言,Pod 的資源請(qǐng)求/約束值是 Pod 中各容器對(duì)該類型資源的請(qǐng)求/約束值的總和。
CPU 資源的約束和請(qǐng)求以 “cpu” 為單位。 在 Kubernetes 中,一個(gè) CPU 等于1 個(gè)物理 CPU 核 或者 一個(gè)虛擬核, 取決于節(jié)點(diǎn)是一臺(tái)物理主機(jī)還是運(yùn)行在某物理主機(jī)上的虛擬機(jī)。
你也可以表達(dá)帶小數(shù) CPU 的請(qǐng)求。 當(dāng)你定義一個(gè)容器,將其 ?spec.containers[].resources.requests.cpu
? 設(shè)置為 0.5 時(shí), 你所請(qǐng)求的 CPU 是你請(qǐng)求 ?1.0
? CPU 時(shí)的一半。 對(duì)于 CPU 資源單位,數(shù)量 表達(dá)式 ?0.1
? 等價(jià)于表達(dá)式 ?100m
?,可以看作 “100 millicpu”。 有些人說成是“一百毫核”,其實(shí)說的是同樣的事情。
CPU 資源總是設(shè)置為資源的絕對(duì)數(shù)量而非相對(duì)數(shù)量值。 例如,無論容器運(yùn)行在單核、雙核或者 48-核的機(jī)器上,?500m
? CPU 表示的是大約相同的計(jì)算能力。
Note:
Kubernetes 不允許設(shè)置精度小于 ?1m
? 的 CPU 資源。 因此,當(dāng) CPU 單位小于 ?1
? 或 ?1000m
? 時(shí),使用毫核的形式是有用的; 例如 ?5m
? 而不是 ?0.005
?。
?memory
?的約束和請(qǐng)求以字節(jié)為單位。 你可以使用普通的證書,或者帶有以下 數(shù)量后綴 的定點(diǎn)數(shù)字來表示內(nèi)存:E、P、T、G、M、k。 你也可以使用對(duì)應(yīng)的 2 的冪數(shù):Ei、Pi、Ti、Gi、Mi、Ki。 例如,以下表達(dá)式所代表的是大致相同的值:
128974848、129e6、129M、128974848000m、123Mi
請(qǐng)注意后綴的大小寫。如果你請(qǐng)求 ?400m
? 內(nèi)存,實(shí)際上請(qǐng)求的是 0.4 字節(jié)。 如果有人這樣設(shè)定資源請(qǐng)求或限制,可能他的實(shí)際想法是申請(qǐng) 400 兆字節(jié)(?400Mi
?) 或者 400M 字節(jié)。
以下 Pod 有兩個(gè)容器。每個(gè)容器的請(qǐng)求為 0.25 CPU 和 64MiB(226 字節(jié))內(nèi)存, 每個(gè)容器的資源約束為 0.5 CPU 和 128MiB 內(nèi)存。 你可以認(rèn)為該 Pod 的資源請(qǐng)求為 0.5 CPU 和 128 MiB 內(nèi)存,資源限制為 1 CPU 和 256MiB 內(nèi)存。
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
當(dāng)你創(chuàng)建一個(gè) Pod 時(shí),Kubernetes 調(diào)度程序?qū)?nbsp;Pod 選擇一個(gè)節(jié)點(diǎn)。 每個(gè)節(jié)點(diǎn)對(duì)每種資源類型都有一個(gè)容量上限:可為 Pod 提供的 CPU 和內(nèi)存量。 調(diào)度程序確保對(duì)于每種資源類型,所調(diào)度的容器的資源請(qǐng)求的總和小于節(jié)點(diǎn)的容量。 請(qǐng)注意,盡管節(jié)點(diǎn)上的實(shí)際內(nèi)存或 CPU 資源使用量非常低,如果容量檢查失敗, 調(diào)度程序仍會(huì)拒絕在該節(jié)點(diǎn)上放置 Pod。 當(dāng)稍后節(jié)點(diǎn)上資源用量增加,例如到達(dá)請(qǐng)求率的每日峰值區(qū)間時(shí),節(jié)點(diǎn)上也不會(huì)出現(xiàn)資源不足的問題。
當(dāng) kubelet 啟動(dòng) Pod 中的容器時(shí),它會(huì)將容器的 CPU 和內(nèi)存請(qǐng)求與約束信息傳遞給容器運(yùn)行時(shí)。
在 Linux 系統(tǒng)上,容器運(yùn)行時(shí)通常會(huì)配置內(nèi)核 CGroups,負(fù)責(zé)應(yīng)用并實(shí)施所定義的請(qǐng)求。
memory.min
? 和 ?memory.low
? 的提示值。emptyDir
?卷。 kubelet 會(huì)跟蹤 ?tmpfs
?形式的 emptyDir 卷用量,將其作為容器的內(nèi)存用量, 而不是臨時(shí)存儲(chǔ)用量。如果某容器內(nèi)存用量超過其內(nèi)存請(qǐng)求值并且所在節(jié)點(diǎn)內(nèi)存不足時(shí),容器所處的 Pod 可能被逐出.
每個(gè)容器可能被允許也可能不被允許使用超過其 CPU 約束的處理時(shí)間。 但是,容器運(yùn)行時(shí)不會(huì)由于 CPU 使用率過高而殺死 Pod 或容器。
kubelet 會(huì)將 Pod 的資源使用情況作為 Pod ?status
?的一部分來報(bào)告的。
如果為集群配置了可選的監(jiān)控工具, 則可以直接從指標(biāo) API 或者監(jiān)控工具獲得 Pod 的資源使用情況。
FEATURE STATE: Kubernetes v1.10 [beta]
節(jié)點(diǎn)通常還可以具有本地的臨時(shí)性存儲(chǔ),由本地掛接的可寫入設(shè)備或者有時(shí)也用 RAM 來提供支持。 “臨時(shí)(Ephemeral)”意味著對(duì)所存儲(chǔ)的數(shù)據(jù)不提供長(zhǎng)期可用性的保證。
Pods 通??梢允褂门R時(shí)性本地存儲(chǔ)來實(shí)現(xiàn)緩沖區(qū)、保存日志等功能。 kubelet 可以為使用本地臨時(shí)存儲(chǔ)的 Pods 提供這種存儲(chǔ)空間,允許后者使用 ?emptyDir
?類型的 卷將其掛載到容器中。
kubelet 也使用此類存儲(chǔ)來保存 節(jié)點(diǎn)層面的容器日志, 容器鏡像文件、以及運(yùn)行中容器的可寫入層。
Caution: 如果節(jié)點(diǎn)失效,存儲(chǔ)在臨時(shí)性存儲(chǔ)中的數(shù)據(jù)會(huì)丟失。 你的應(yīng)用不能對(duì)本地臨時(shí)性存儲(chǔ)的性能 SLA(例如磁盤 IOPS)作任何假定。
作為一種 beta 階段功能特性,Kubernetes 允許你跟蹤、預(yù)留和限制 Pod 可消耗的臨時(shí)性本地存儲(chǔ)數(shù)量。
Kubernetes 有兩種方式支持節(jié)點(diǎn)上配置本地臨時(shí)性存儲(chǔ):
采用這種配置時(shí),你會(huì)把所有類型的臨時(shí)性本地?cái)?shù)據(jù)(包括 ?emptyDir
?卷、可寫入容器層、容器鏡像、日志等)放到同一個(gè)文件系統(tǒng)中。 作為最有效的 kubelet 配置方式,這意味著該文件系統(tǒng)是專門提供給 Kubernetes (kubelet)來保存數(shù)據(jù)的。
kubelet 也會(huì)生成 節(jié)點(diǎn)層面的容器日志, 并按臨時(shí)性本地存儲(chǔ)的方式對(duì)待之。
kubelet 會(huì)將日志寫入到所配置的日志目錄(默認(rèn)為 ?/var/log
?)下的文件中; 還會(huì)針對(duì)其他本地存儲(chǔ)的數(shù)據(jù)使用同一個(gè)基礎(chǔ)目錄(默認(rèn)為 ?/var/lib/kubelet
?)。
通常,?/var/lib/kubelet
? 和 ?/var/log
? 都是在系統(tǒng)的根文件系統(tǒng)中。kubelet 的設(shè)計(jì)也考慮到這一點(diǎn)。
你的集群節(jié)點(diǎn)當(dāng)然可以包含其他的、并非用于 Kubernetes 的很多文件系統(tǒng)。
你使用節(jié)點(diǎn)上的某個(gè)文件系統(tǒng)來保存運(yùn)行 Pods 時(shí)產(chǎn)生的臨時(shí)性數(shù)據(jù):日志和 ?emptyDir
?卷等。你可以使用這個(gè)文件系統(tǒng)來保存其他數(shù)據(jù)(例如:與 Kubernetes 無關(guān)的其他系統(tǒng)日志);這個(gè)文件系統(tǒng)還可以是根文件系統(tǒng)。
kubelet 也將 節(jié)點(diǎn)層面的容器日志 寫入到第一個(gè)文件系統(tǒng)中,并按臨時(shí)性本地存儲(chǔ)的方式對(duì)待之。
同時(shí)你使用另一個(gè)由不同邏輯存儲(chǔ)設(shè)備支持的文件系統(tǒng)。在這種配置下,你會(huì)告訴 kubelet 將容器鏡像層和可寫層保存到這第二個(gè)文件系統(tǒng)上的某個(gè)目錄中。
第一個(gè)文件系統(tǒng)中不包含任何鏡像層和可寫層數(shù)據(jù)。
當(dāng)然,你的集群節(jié)點(diǎn)上還可以有很多其他與 Kubernetes 沒有關(guān)聯(lián)的文件系統(tǒng)。
kubelet 能夠度量其本地存儲(chǔ)的用量。實(shí)現(xiàn)度量機(jī)制的前提是:
LocalStorageCapacityIsolation
?特性門控 被啟用(默認(rèn)狀態(tài)),并且如果你的節(jié)點(diǎn)配置不同于以上預(yù)期,kubelet 就無法對(duì)臨時(shí)性本地存儲(chǔ)的資源約束實(shí)施限制。
Note: kubelet 會(huì)將 ?
tmpfs
?emptyDir 卷的用量當(dāng)作容器內(nèi)存用量,而不是本地臨時(shí)性存儲(chǔ)來統(tǒng)計(jì)。
你可以使用 ?ephemeral-storage
? 來管理本地臨時(shí)性存儲(chǔ)。 Pod 中的每個(gè)容器可以設(shè)置以下屬性:
spec.containers[].resources.limits.ephemeral-storage
?spec.containers[].resources.requests.ephemeral-storage
??ephemeral-storage
? 的請(qǐng)求和約束值是按量綱計(jì)量的。你可以使用一般整數(shù)或者定點(diǎn)數(shù)字 加上下面的后綴來表達(dá)存儲(chǔ)量:E、P、T、G、M、K。 你也可以使用對(duì)應(yīng)的 2 的冪級(jí)數(shù)來表達(dá):Ei、Pi、Ti、Gi、Mi、Ki。 例如,下面的表達(dá)式所表達(dá)的大致是同一個(gè)值:
128974848
?129e6
?129M
?123Mi
?在下面的例子中,Pod 包含兩個(gè)容器。每個(gè)容器請(qǐng)求 2 GiB 大小的本地臨時(shí)性存儲(chǔ)。 每個(gè)容器都設(shè)置了 4 GiB 作為其本地臨時(shí)性存儲(chǔ)的約束值。 因此,整個(gè) Pod 的本地臨時(shí)性存儲(chǔ)請(qǐng)求是 4 GiB,且其本地臨時(shí)性存儲(chǔ)的約束為 8 GiB。
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
volumeMounts:
- name: ephemeral
mountPath: "/tmp"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
volumeMounts:
- name: ephemeral
mountPath: "/tmp"
volumes:
- name: ephemeral
emptyDir: {}
當(dāng)你創(chuàng)建一個(gè) Pod 時(shí),Kubernetes 調(diào)度器會(huì)為 Pod 選擇一個(gè)節(jié)點(diǎn)來運(yùn)行之。 每個(gè)節(jié)點(diǎn)都有一個(gè)本地臨時(shí)性存儲(chǔ)的上限,是其可提供給 Pods 使用的總量。
調(diào)度器會(huì)確保所調(diào)度的容器的資源請(qǐng)求總和不會(huì)超出節(jié)點(diǎn)的資源容量。
如果 kubelet 將本地臨時(shí)性存儲(chǔ)作為資源來管理,則 kubelet 會(huì)度量以下各處的存儲(chǔ)用量:
emptyDir
?卷,除了 tmpfs ?emptyDir
?卷如果某 Pod 的臨時(shí)存儲(chǔ)用量超出了你所允許的范圍,kubelet 會(huì)向其發(fā)出逐出(eviction)信號(hào),觸發(fā)該 Pod 被逐出所在節(jié)點(diǎn)。
就容器層面的隔離而言,如果某容器的可寫入鏡像層和日志用量超出其存儲(chǔ)約束, kubelet 也會(huì)將所在的 Pod 標(biāo)記為逐出候選。
就 Pod 層面的隔離而言,kubelet 會(huì)將 Pod 中所有容器的約束值相加,得到 Pod 存儲(chǔ)約束的總值。如果所有容器的本地臨時(shí)性存儲(chǔ)用量總和加上 Pod 的 ?emptyDir
?卷的用量超出 Pod 存儲(chǔ)約束值,kubelet 也會(huì)將該 Pod 標(biāo)記為逐出候選。
Caution:
如果 kubelet 沒有度量本地臨時(shí)性存儲(chǔ)的用量,即使 Pod 的本地存儲(chǔ)用量超出其約束值也不會(huì)被逐出。
不過,如果用于可寫入容器鏡像層、節(jié)點(diǎn)層面日志或者 ?emptyDir
?卷的文件系統(tǒng)中可用空間太少, 節(jié)點(diǎn)會(huì)為自身設(shè)置本地存儲(chǔ)不足的污點(diǎn) 標(biāo)簽。 這一污點(diǎn)會(huì)觸發(fā)對(duì)那些無法容忍該污點(diǎn)的 Pods 的逐出操作。
kubelet 支持使用不同方式來度量 Pod 的存儲(chǔ)用量:
kubelet 按預(yù)定周期執(zhí)行掃描操作,檢查 ?emptyDir
?卷、容器日志目錄以及可寫入容器鏡像層。
這一掃描會(huì)度量存儲(chǔ)空間用量。
Note:
在這種模式下,kubelet 并不檢查已刪除文件所對(duì)應(yīng)的、仍處于打開狀態(tài)的文件描述符。
如果你(或者容器)在 ?emptyDir
?卷中創(chuàng)建了一個(gè)文件,寫入一些內(nèi)容之后再次打開 該文件并執(zhí)行了刪除操作,所刪除文件對(duì)應(yīng)的 inode 仍然存在,直到你關(guān)閉該文件為止。 kubelet 不會(huì)將該文件所占用的空間視為已使用空間。
FEATURE STATE: Kubernetes v1.15 [alpha]
項(xiàng)目配額(Project Quota)是一個(gè)操作系統(tǒng)層的功能特性,用來管理文件系統(tǒng)中的存儲(chǔ)用量。 在 Kubernetes 中,你可以啟用項(xiàng)目配額以監(jiān)視存儲(chǔ)用量。 你需要確保節(jié)點(diǎn)上為 ?emptyDir
?提供存儲(chǔ)的文件系統(tǒng)支持項(xiàng)目配額。 例如,XFS 和 ext4fs 文件系統(tǒng)都支持項(xiàng)目配額。
Note: 項(xiàng)目配額可以幫你監(jiān)視存儲(chǔ)用量,但無法對(duì)存儲(chǔ)約束執(zhí)行限制。
Kubernetes 所使用的項(xiàng)目 ID 始于 ?1048576
?。 所使用的 IDs 會(huì)注冊(cè)在 ?/etc/projects
? 和 ?/etc/projid
? 文件中。 如果該范圍中的項(xiàng)目 ID 已經(jīng)在系統(tǒng)中被用于其他目的,則已占用的項(xiàng)目 IDs 也必須注冊(cè)到 ?/etc/projects
? 和 ?/etc/projid
? 中,這樣 Kubernetes 才不會(huì)使用它們。
配額方式與目錄掃描方式相比速度更快,結(jié)果更精確。當(dāng)某個(gè)目錄被分配給某個(gè)項(xiàng)目時(shí), 該目錄下所創(chuàng)建的所有文件都屬于該項(xiàng)目,內(nèi)核只需要跟蹤該項(xiàng)目中的文件所使用的存儲(chǔ)塊個(gè)數(shù)。 如果某文件被創(chuàng)建后又被刪除,但對(duì)應(yīng)文件描述符仍處于打開狀態(tài), 該文件會(huì)繼續(xù)耗用存儲(chǔ)空間。配額跟蹤技術(shù)能夠精確第記錄對(duì)應(yīng)存儲(chǔ)空間的狀態(tài), 而目錄掃描方式會(huì)忽略被刪除文件所占用的空間。
如果你希望使用項(xiàng)目配額,你需要:
featureGates
?字段 或者使用 ?--feature-gates
? 命令行參數(shù) 啟用 ?LocalStorageCapacityIsolationFSQuotaMonitoring=true
? 特性門控 。# 對(duì) ext4 而言,在 /dev/block-device 尚未被掛載時(shí)執(zhí)行下面操作
sudo tune2fs -O project -Q prjquota /dev/block-device
prjquota
?。擴(kuò)展資源是 ?kubernetes.io
? 域名之外的標(biāo)準(zhǔn)資源名稱。 它們使得集群管理員能夠頒布非 Kubernetes 內(nèi)置資源,而用戶可以使用他們。
使用擴(kuò)展資源需要兩個(gè)步驟。首先,集群管理員必須頒布擴(kuò)展資源。 其次,用戶必須在 Pod 中請(qǐng)求擴(kuò)展資源。
節(jié)點(diǎn)級(jí)擴(kuò)展資源綁定到節(jié)點(diǎn)。
為了頒布新的節(jié)點(diǎn)級(jí)擴(kuò)展資源,集群操作員可以向 API 服務(wù)器提交 ?PATCH
?HTTP 請(qǐng)求, 以在集群中節(jié)點(diǎn)的 ?status.capacity
? 中為其配置可用數(shù)量。 完成此操作后,節(jié)點(diǎn)的 ?status.capacity
? 字段中將包含新資源。 kubelet 會(huì)異步地對(duì) ?status.allocatable
? 字段執(zhí)行自動(dòng)更新操作,使之包含新資源。
由于調(diào)度器在評(píng)估 Pod 是否適合在某節(jié)點(diǎn)上執(zhí)行時(shí)會(huì)使用節(jié)點(diǎn)的 ?status.allocatable
? 值, 調(diào)度器只會(huì)考慮異步更新之后的新值。 在更新節(jié)點(diǎn)容量使之包含新資源之后和請(qǐng)求該資源的第一個(gè) Pod 被調(diào)度到該節(jié)點(diǎn)之間, 可能會(huì)有短暫的延遲。
示例:
這是一個(gè)示例,顯示了如何使用 ?curl
?構(gòu)造 HTTP 請(qǐng)求,公告主節(jié)點(diǎn)為 ?k8s-master
? 的節(jié)點(diǎn) ?k8s-node-1
? 上存在五個(gè) ?example.com/foo
? 資源。
curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
Note: 在前面的請(qǐng)求中,?
~1
? 是在 patch 路徑中對(duì)字符 ?/
? 的編碼。 JSON-Patch 中的操作路徑的值被視為 JSON-Pointer 類型。 有關(guān)更多詳細(xì)信息,請(qǐng)參見 IETF RFC 6901 第 3 節(jié)。
集群層面的擴(kuò)展資源并不綁定到具體節(jié)點(diǎn)。 它們通常由調(diào)度器擴(kuò)展程序(Scheduler Extenders)管理,這些程序處理資源消耗和資源配額。
你可以在調(diào)度器策略配置 中指定由調(diào)度器擴(kuò)展程序處理的擴(kuò)展資源。
示例:
下面的調(diào)度器策略配置標(biāo)明集群層擴(kuò)展資源 "example.com/foo" 由調(diào)度器擴(kuò)展程序處理。
ignoredByScheduler
?字段指定調(diào)度器不要在其 ?PodFitsResources
?斷言中檢查 "example.com/foo" 資源。{
"kind": "Policy",
"apiVersion": "v1",
"extenders": [
{
"urlPrefix":"<extender-endpoint>",
"bindVerb": "bind",
"managedResources": [
{
"name": "example.com/foo",
"ignoredByScheduler": true
}
]
}
]
}
就像 CPU 和內(nèi)存一樣,用戶可以在 Pod 的規(guī)約中使用擴(kuò)展資源。 調(diào)度器負(fù)責(zé)資源的核算,確保同時(shí)分配給 Pod 的資源總量不會(huì)超過可用數(shù)量。
Note: 擴(kuò)展資源取代了非透明整數(shù)資源(Opaque Integer Resources,OIR)。 用戶可以使用 ?
kubernetes.io
? (保留)以外的任何域名前綴。
要在 Pod 中使用擴(kuò)展資源,請(qǐng)?jiān)谌萜饕?guī)范的 ?spec.containers[].resources.limits
? 映射中包含資源名稱作為鍵。
Note: 擴(kuò)展資源不能過量使用,因此如果容器規(guī)范中同時(shí)存在請(qǐng)求和約束,則它們的取值必須相同。
僅當(dāng)所有資源請(qǐng)求(包括 CPU、內(nèi)存和任何擴(kuò)展資源)都被滿足時(shí),Pod 才能被調(diào)度。 在資源請(qǐng)求無法滿足時(shí),Pod 會(huì)保持在 ?PENDING
?狀態(tài)。
示例:
下面的 Pod 請(qǐng)求 2 個(gè) CPU 和 1 個(gè) "example.com/foo"(擴(kuò)展資源)。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: myimage
resources:
requests:
cpu: 2
example.com/foo: 1
limits:
example.com/foo: 1
進(jìn)程 ID(PID)限制允許對(duì) kubelet 進(jìn)行配置,以限制給定 Pod 可以消耗的 PID 數(shù)量。
如果調(diào)度器找不到該 Pod 可以匹配的任何節(jié)點(diǎn),則該 Pod 將保持未被調(diào)度狀態(tài), 直到找到一個(gè)可以被調(diào)度到的位置。每當(dāng)調(diào)度器找不到 Pod 可以調(diào)度的地方時(shí), 會(huì)產(chǎn)生一個(gè) Event。 你可以使用 ?kubectl
?來查看 Pod 的事件;例如:
kubectl describe pod frontend | grep -A 9999999999 Events
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 23s default-scheduler 0/42 nodes available: insufficient cpu
在上述示例中,由于節(jié)點(diǎn)上的 CPU 資源不足,名為 “frontend” 的 Pod 無法被調(diào)度。 由于內(nèi)存不足(PodExceedsFreeMemory)而導(dǎo)致失敗時(shí),也有類似的錯(cuò)誤消息。 一般來說,如果 Pod 處于懸決狀態(tài)且有這種類型的消息時(shí),你可以嘗試如下幾件事情:
cpu:1
?, 那么一個(gè)請(qǐng)求為 ?cpu: 1.1
? 的 Pod 永遠(yuǎn)不會(huì)被調(diào)度。
你可以使用 ?kubectl describe nodes
? 命令檢查節(jié)點(diǎn)容量和已分配的資源數(shù)量。 例如:
kubectl describe nodes e2e-test-node-pool-4lw4
Name: e2e-test-node-pool-4lw4
[ ... 這里忽略了若干行以便閱讀 ...]
Capacity:
cpu: 2
memory: 7679792Ki
pods: 110
Allocatable:
cpu: 1800m
memory: 7474992Ki
pods: 110
[ ... 這里忽略了若干行以便閱讀 ...]
Non-terminated Pods: (5 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%)
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%)
在上面的輸出中,你可以看到如果 Pod 請(qǐng)求超過 1120m CPU 或者 6.23Gi 內(nèi)存,節(jié)點(diǎn)將無法滿足。
通過查看 "Pods" 部分,你將看到哪些 Pod 占用了節(jié)點(diǎn)上的資源。
Pods 可用的資源量低于節(jié)點(diǎn)的資源總量,因?yàn)橄到y(tǒng)守護(hù)進(jìn)程也會(huì)使用一部分可用資源。 在 Kubernetes API 中,每個(gè) Node 都有一個(gè) ?.status.allocatable
? 字段。
字段 ?.status.allocatable
? 描述節(jié)點(diǎn)上可以用于 Pod 的資源總量(例如:15 個(gè)虛擬 CPU、7538 MiB 內(nèi)存)。
你可以配置資源配額功能特性以限制每個(gè)名字空間可以使用的資源總量。 當(dāng)某名字空間中存在 ResourceQuota 時(shí),Kubernetes 會(huì)在該名字空間中的對(duì)象強(qiáng)制實(shí)施配額。 例如,如果你為不同的團(tuán)隊(duì)分配名字空間,你可以為這些名字空間添加 ResourceQuota。 設(shè)置資源配額有助于防止一個(gè)團(tuán)隊(duì)占用太多資源,以至于這種占用會(huì)影響其他團(tuán)隊(duì)。
你還需要考慮為這些名字空間設(shè)置授權(quán)訪問: 為名字空間提供 全部 的寫權(quán)限時(shí),具有合適權(quán)限的人可能刪除所有資源, 包括所配置的 ResourceQuota。
你的容器可能因?yàn)橘Y源緊張而被終止。要查看容器是否因?yàn)橛龅劫Y源限制而被殺死, 請(qǐng)針對(duì)相關(guān)的 Pod 執(zhí)行 ?kubectl describe pod
?:
kubectl describe pod simmemleak-hra99
輸出類似于:
Name: simmemleak-hra99
Namespace: default
Image(s): saadali/simmemleak
Node: kubernetes-node-tf0f/10.240.216.66
Labels: name=simmemleak
Status: Running
Reason:
Message:
IP: 10.244.2.75
Containers:
simmemleak:
Image: saadali/simmemleak
Limits:
cpu: 100m
memory: 50Mi
State: Running
Started: Tue, 07 Jul 2015 12:54:41 -0700
Last Termination State: Terminated
Exit Code: 1
Started: Fri, 07 Jul 2015 12:54:30 -0700
Finished: Fri, 07 Jul 2015 12:54:33 -0700
Ready: False
Restart Count: 5
Conditions:
Type Status
Ready False
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 42s default-scheduler Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
Normal Pulled 41s kubelet Container image "saadali/simmemleak:latest" already present on machine
Normal Created 41s kubelet Created container simmemleak
Normal Started 40s kubelet Started container simmemleak
Normal Killing 32s kubelet Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod
在上面的例子中,?Restart Count: 5
? 意味著 Pod 中的 ?simmemleak
?容器被終止并且(到目前為止)重啟了五次。 原因 ?OOMKilled
?顯示容器嘗試使用超出其限制的內(nèi)存量。
你接下來要做的或許是檢查應(yīng)用代碼,看看是否存在內(nèi)存泄露。 如果你發(fā)現(xiàn)應(yīng)用的行為與你所預(yù)期的相同,則可以考慮為該容器設(shè)置一個(gè)更高的內(nèi)存約束 (也可能需要設(shè)置請(qǐng)求值)。
Copyright©2021 w3cschool編程獅|閩ICP備15016281號(hào)-3|閩公網(wǎng)安備35020302033924號(hào)
違法和不良信息舉報(bào)電話:173-0602-2364|舉報(bào)郵箱:jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號(hào)
聯(lián)系方式:
更多建議: