【云原生|Kubernetes】09-Pod的CPU和內(nèi)存的請(qǐng)求與限制

簡(jiǎn)介

在 Kubernetes 中，請(qǐng)求（request）和限制（limit）是用于管理容器資源的兩個(gè)重要概念。

• 請(qǐng)求是指容器所需的資源量，可以視為容器啟動(dòng)時(shí)保證其正常運(yùn)行所需的最小資源量。例如，如果一個(gè)容器需要 1 個(gè) CPU 和 256MB 內(nèi)存才能運(yùn)行，那么可以在 Pod 的容器定義中設(shè)置這些資源的請(qǐng)求。請(qǐng)求資源將確保在 Kubernetes 集群中為該容器分配足夠的資源量，以便可以正常運(yùn)行。

• 限制是指容器能夠使用的最大資源量。 例如，可以設(shè)置 CPU 和內(nèi)存限制，以確保容器不會(huì)使用過(guò)多的資源，從而影響其他容器或宿主機(jī)的性能。如果容器試圖使用超過(guò)其限制的資源量，Kubernetes 將終止該容器并重新啟動(dòng)它。

• 需要注意的是，請(qǐng)求和限制并不是強(qiáng)制性的設(shè)置。如果沒(méi)有設(shè)置請(qǐng)求和限制，Kubernetes 將為容器分配默認(rèn)值。這可能會(huì)導(dǎo)致容器在某些情況下無(wú)法正常工作。因此，建議在定義容器時(shí)為其設(shè)置請(qǐng)求和限制，以確保其在 Kubernetes 集群中可以穩(wěn)定地運(yùn)行，并避免資源爭(zhēng)用和性能問(wèn)題。

• 在設(shè)置請(qǐng)求和限制時(shí)，可以使用 CPU、內(nèi)存等不同類(lèi)型的資源，并為每種資源指定請(qǐng)求和限制。例如，可以設(shè)置一個(gè)容器的 CPU 請(qǐng)求為 0.5 個(gè) CPU，限制為 1 個(gè) CPU，內(nèi)存請(qǐng)求為 256MB，限制為 512MB。這些值將根據(jù)實(shí)際情況而定，可以根據(jù)容器的具體需求和集群的資源情況進(jìn)行調(diào)整。

內(nèi)存的請(qǐng)求（request）和限制（limit）

• 內(nèi)存請(qǐng)求（request）： 當(dāng)節(jié)點(diǎn)擁有足夠的可用內(nèi)存時(shí)，容器可以使用其請(qǐng)求的內(nèi)存，請(qǐng)求的大小會(huì)直接分配給容器，容器也可以不用到請(qǐng)求的這么多；
• 內(nèi)存限制（limit）: 器不允許使用超過(guò)其限制的內(nèi)存。

指定內(nèi)存請(qǐng)求和限制

? 要為容器指定內(nèi)存請(qǐng)求，請(qǐng)?jiān)谌萜髻Y源清單中包含 resources: requests 字段。 同理，要指定內(nèi)存限制，請(qǐng)包含 resources: limits。

1. 創(chuàng)建一個(gè)擁有一個(gè)容器的 Pod。 容器將會(huì)請(qǐng)求 100 MiB 內(nèi)存，并且內(nèi)存會(huì)被限制在 200 MiB 以內(nèi)。

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
### 配置文件的 args 部分提供了容器啟動(dòng)時(shí)的參數(shù)。 "--vm-bytes", "150M" 參數(shù)告知容器嘗試分配 150 MiB 內(nèi)存。

• 創(chuàng)建Pod

[root@master pod]# kubectl apply  -f memory-request-limit.yaml
pod/memory-demo created
[root@master pod]#

• 查看 Pod 相關(guān)的詳細(xì)信息：

[root@master pod]# kubectl describe pods -n mem-example memory-demo

## 輸出結(jié)果顯示：該 Pod 中容器的內(nèi)存請(qǐng)求為 100 MiB，內(nèi)存限制為 200 MiB。
...
resources:
  requests:
    memory: 100Mi
  limits:
    memory: 200Mi
...

• 運(yùn)行 kubectl top 命令，獲取該 Pod 的指標(biāo)數(shù)據(jù)：

使用kubectl top命令需要安裝metrics-server，cpu和內(nèi)存的監(jiān)控服務(wù)

kubectl top pod memory-demo --namespace=mem-example

## 輸出結(jié)果顯示：Pod 正在使用的內(nèi)存大約為 162,900,000 字節(jié)，約為 150 MiB。 這大于 Pod 請(qǐng)求的 100 MiB，但在 Pod 限制的 200 MiB之內(nèi)。
NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

超過(guò)容器限制的內(nèi)存

當(dāng)節(jié)點(diǎn)擁有足夠的可用內(nèi)存時(shí)，容器可以使用其請(qǐng)求的內(nèi)存。 但是，容器不允許使用超過(guò)其限制的內(nèi)存。 如果容器分配的內(nèi)存超過(guò)其限制，該容器會(huì)成為被終止的候選容器。 如果容器繼續(xù)消耗超出其限制的內(nèi)存，則終止容器。 如果終止的容器可以被重啟，則 kubelet 會(huì)重新啟動(dòng)它，就像其他任何類(lèi)型的運(yùn)行時(shí)失敗一樣。

2. 創(chuàng)建一個(gè) Pod，嘗試分配超出其限制的內(nèi)存。 這是一個(gè) Pod 的配置文件，其擁有一個(gè)容器，該容器的內(nèi)存請(qǐng)求為 50 MiB，內(nèi)存限制為 100 MiB

piVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

• 創(chuàng)建Pod

kubectl apply -f memory-request-limit-2.yaml --namespace=mem-example

• 查看 Pod 相關(guān)的詳細(xì)信息：

kubectl get pod memory-demo-2 --namespace=mem-example

此時(shí)，容器可能正在運(yùn)行或被殺死。重復(fù)前面的命令，直到容器被殺掉：
[root@master pod]# kubectl get -n mem-example pods
NAME            READY   STATUS      RESTARTS   AGE
memory-demo     1/1     Running     0          49m
memory-demo-2   0/1     OOMKilled   0          24s
[root@master pod]#

超過(guò)整個(gè)節(jié)點(diǎn)容量的內(nèi)存

? 內(nèi)存請(qǐng)求和限制是與容器關(guān)聯(lián)的，但將 Pod 視為具有內(nèi)存請(qǐng)求和限制，也是很有用的。 Pod 的內(nèi)存請(qǐng)求是 Pod 中所有容器的內(nèi)存請(qǐng)求之和。 同理，Pod 的內(nèi)存限制是 Pod 中所有容器的內(nèi)存限制之和。Pod 的調(diào)度基于請(qǐng)求。只有當(dāng)節(jié)點(diǎn)擁有足夠滿足 Pod 內(nèi)存請(qǐng)求的內(nèi)存時(shí)，才會(huì)將 Pod 調(diào)度至節(jié)點(diǎn)上運(yùn)行。

3. 創(chuàng)建一個(gè) Pod，其內(nèi)存請(qǐng)求超過(guò)了你集群中的任意一個(gè)節(jié)點(diǎn)所擁有的內(nèi)存。 這是該 Pod 的配置文件，其擁有一個(gè)請(qǐng)求 1000 GiB 內(nèi)存的容器，這應(yīng)該超過(guò)了你集群中任何節(jié)點(diǎn)的容量。

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-3-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "1000Gi"
      limits:
        memory: "1000Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

• 創(chuàng)建Pod

[root@master pod]# kubectl apply -f memory-request-limit-3.yaml

• 查看Pod狀態(tài)

[root@master pod]# kubectl get  pods -n mem-example
NAME            READY   STATUS             RESTARTS   AGE
memory-demo-3   0/1     Pending            0          11s
[root@master pod]#

• 查看關(guān)于 Pod 的詳細(xì)信息，包括事件：

kubectl describe pod memory-demo-3 --namespace=mem-example

輸出結(jié)果顯示：由于節(jié)點(diǎn)內(nèi)存不足，該容器無(wú)法被調(diào)度：
Events:
  ...  Reason            Message
       ------            -------
  ...  Warning  FailedScheduling  49s (x3 over 118s)  default-scheduler  0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 Insufficient memory.

內(nèi)存單位

內(nèi)存資源的基本單位是字節(jié)（byte）。你可以使用這些后綴之一，將內(nèi)存表示為 純整數(shù)或定點(diǎn)整數(shù)：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面是一些近似相同的值：

128974848, 129e6, 129M, 123Mi

如果不指定內(nèi)存限制

如果你沒(méi)有為一個(gè)容器指定內(nèi)存限制，則自動(dòng)遵循以下情況之一：

• 容器可無(wú)限制地使用內(nèi)存。容器可以使用其所在節(jié)點(diǎn)所有的可用內(nèi)存， 進(jìn)而可能導(dǎo)致該節(jié)點(diǎn)調(diào)用 OOM Killer。 此外，如果發(fā)生 OOM Kill，沒(méi)有資源限制的容器將被殺掉的可行性更大。
• 運(yùn)行的容器所在命名空間有默認(rèn)的內(nèi)存限制，那么該容器會(huì)被自動(dòng)分配默認(rèn)限制。 集群管理員可用使用 LimitRange 來(lái)指定默認(rèn)的內(nèi)存限制。

如果不知道內(nèi)存請(qǐng)求

如果容器設(shè)置了內(nèi)存限制值但未設(shè)置 內(nèi)存請(qǐng)求值，Kubernetes 也會(huì)為其設(shè)置與內(nèi)存限制值相同的內(nèi)存請(qǐng)求。

內(nèi)存請(qǐng)求和限制的目的

通過(guò)為集群中運(yùn)行的容器配置內(nèi)存請(qǐng)求和限制，你可以有效利用集群節(jié)點(diǎn)上可用的內(nèi)存資源。 通過(guò)將 Pod 的內(nèi)存請(qǐng)求保持在較低水平，你可以更好地安排 Pod 調(diào)度。 通過(guò)讓內(nèi)存限制大于內(nèi)存請(qǐng)求，你可以完成兩件事：

• Pod 可以進(jìn)行一些突發(fā)活動(dòng)，從而更好的利用可用內(nèi)存。
• Pod 在突發(fā)活動(dòng)期間，可使用的內(nèi)存被限制為合理的數(shù)量

CPU的請(qǐng)求（request）和限制（limit）

指定 CPU 請(qǐng)求和 CPU 限制

? 要為容器指定 CPU 請(qǐng)求，請(qǐng)?jiān)谌萜髻Y源清單中包含 resources: requests 字段。 要指定 CPU 限制，請(qǐng)包含 resources:limits。

1. 創(chuàng)建一個(gè)具有一個(gè)容器的 Pod。容器將會(huì)請(qǐng)求 0.5 個(gè) CPU，而且最多限制使用 1 個(gè) CPU。 這是 Pod 的配置文件：

配置文件的 args 部分提供了容器啟動(dòng)時(shí)的參數(shù)。 -cpus "2" 參數(shù)告訴容器嘗試使用 2 個(gè) CPU。

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

• 創(chuàng)建Pod

	kubectl apply -f  cpu-request-limit.yaml

• 查看顯示關(guān)于 Pod 的詳細(xì)信息：

kubectl get pod cpu-demo --output=yaml --namespace=cpu-example

## 輸出顯示 Pod 中的一個(gè)容器的 CPU 請(qǐng)求為 500 milliCPU，并且 CPU 限制為 1 個(gè) CPU。
resources:
  limits:
    cpu: "1"
  requests:
    cpu: 500m

• 使用 kubectl top 命令來(lái)獲取該 Pod 的指標(biāo)：

kubectl top pod cpu-demo --namespace=cpu-example

##此示例輸出顯示 Pod 使用的是 974 milliCPU，即略低于 Pod 配置中指定的 1 個(gè) CPU 的限制。
NAME                        CPU(cores)   MEMORY(bytes)
cpu-demo                    974m         <something>

設(shè)置超過(guò)節(jié)點(diǎn)能力的 CPU 請(qǐng)求

• CPU 請(qǐng)求和限制與都與容器相關(guān)，但是我們可以考慮一下 Pod 具有對(duì)應(yīng)的 CPU 請(qǐng)求和限制這樣的場(chǎng)景。 Pod 對(duì) CPU 用量的請(qǐng)求等于 Pod 中所有容器的請(qǐng)求數(shù)量之和。 同樣，Pod 的 CPU 資源限制等于 Pod 中所有容器 CPU 資源限制數(shù)之和。

• Pod 調(diào)度是基于資源請(qǐng)求值來(lái)進(jìn)行的。 僅在某節(jié)點(diǎn)具有足夠的 CPU 資源來(lái)滿足 Pod CPU 請(qǐng)求時(shí)，Pod 將會(huì)在對(duì)應(yīng)節(jié)點(diǎn)上運(yùn)行。

1. 創(chuàng)建一個(gè) Pod，該 Pod 的 CPU 請(qǐng)求對(duì)于集群中任何節(jié)點(diǎn)的容量而言都會(huì)過(guò)大。 下面是 Pod 的配置文件，其中有一個(gè)容器。容器請(qǐng)求 100 個(gè) CPU，這可能會(huì)超出集群中任何節(jié)點(diǎn)的容量。

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-2
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    resources:
      limits:
        cpu: "100"
      requests:
        cpu: "100"
    args:
    - -cpus
    - "2"

• 創(chuàng)建Pod

kubectl apply -f  cpu-request-limit-2.yaml

• 輸出顯示 Pod 狀態(tài)為 Pending。也就是說(shuō)，Pod 未被調(diào)度到任何節(jié)點(diǎn)上運(yùn)行， 并且 Pod 將無(wú)限期地處于 Pending 狀態(tài)：

NAME         READY     STATUS    RESTARTS   AGE
cpu-demo-2   0/1       Pending   0          7m

• 查看有關(guān) Pod 的詳細(xì)信息，包含事件

kubectl describe pod cpu-demo-2 --namespace=cpu-example

## 輸出顯示由于節(jié)點(diǎn)上的 CPU 資源不足，無(wú)法調(diào)度容器：
Events:
  Reason                        Message
  ------                        -------
  FailedScheduling      No nodes are available that match all of the following predicates:: Insufficient cpu (3).

CPU單位

CPU 資源以 CPU 單位度量。Kubernetes 中的一個(gè) CPU 等同于：

• 1 個(gè) AWS vCPU
• 1 個(gè) GCP核心
• 1 個(gè) Azure vCore
• 裸機(jī)上具有超線程能力的英特爾處理器上的 1 個(gè)超線程

小數(shù)值是可以使用的。一個(gè)請(qǐng)求 0.5 CPU 的容器保證會(huì)獲得請(qǐng)求 1 個(gè) CPU 的容器的 CPU 的一半。 你可以使用后綴 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 精度不能超過(guò) 1m。

CPU 請(qǐng)求只能使用絕對(duì)數(shù)量，而不是相對(duì)數(shù)量。0.1 在單核、雙核或 48 核計(jì)算機(jī)上的 CPU 數(shù)量值是一樣的。

如果不指定 CPU 限制

如果你沒(méi)有為容器指定 CPU 限制，則會(huì)發(fā)生以下情況之一：

• 容器在可以使用的 CPU 資源上沒(méi)有上限。因而可以使用所在節(jié)點(diǎn)上所有的可用 CPU 資源。
• 容器在具有默認(rèn) CPU 限制的名字空間中運(yùn)行，系統(tǒng)會(huì)自動(dòng)為容器設(shè)置默認(rèn)限制。 集群管理員可以使用 LimitRange 指定 CPU 限制的默認(rèn)值。

如果你設(shè)置了 CPU 限制但未設(shè)置 CPU 請(qǐng)求

? 如果你為容器指定了 CPU 限制值但未為其設(shè)置 CPU 請(qǐng)求，Kubernetes 會(huì)自動(dòng)為其 設(shè)置與 CPU 限制相同的 CPU 請(qǐng)求值。類(lèi)似的，如果容器設(shè)置了內(nèi)存限制值但未設(shè)置 內(nèi)存請(qǐng)求值，Kubernetes 也會(huì)為其設(shè)置與內(nèi)存限制值相同的內(nèi)存請(qǐng)求。

設(shè)置CPU 請(qǐng)求和限制的初衷

通過(guò)配置你的集群中運(yùn)行的容器的 CPU 請(qǐng)求和限制，你可以有效利用集群上可用的 CPU 資源。 通過(guò)將 Pod CPU 請(qǐng)求保持在較低水平，可以使 Pod 更有機(jī)會(huì)被調(diào)度。 通過(guò)使 CPU 限制大于 CPU 請(qǐng)求，你可以完成兩件事：

• Pod 可能會(huì)有突發(fā)性的活動(dòng)，它可以利用碰巧可用的 CPU 資源。
• Pod 在突發(fā)負(fù)載期間可以使用的 CPU 資源數(shù)量仍被限制為合理的數(shù)量。

QOS服務(wù)質(zhì)量

? Kubernetes 中的 服務(wù)質(zhì)量（Quality of Service，QoS） 類(lèi)， 闡述 Kubernetes 如何根據(jù)為 Pod 中的容器指定的資源約束為每個(gè) Pod 設(shè)置 QoS 類(lèi)。 Kubernetes 依賴這種分類(lèi)來(lái)決定當(dāng) Node 上沒(méi)有足夠可用資源時(shí)要驅(qū)逐哪些 Pod。

QoS 類(lèi)

Kubernetes 對(duì)你運(yùn)行的 Pod 進(jìn)行分類(lèi)，并將每個(gè) Pod 分配到特定的 QoS 類(lèi)中。 Kubernetes 使用這種分類(lèi)來(lái)影響不同 Pod 被處理的方式。Kubernetes 基于 Pod 中容器的資源請(qǐng)求進(jìn)行分類(lèi)， 同時(shí)確定這些請(qǐng)求如何與資源限制相關(guān)。 這稱為服務(wù)質(zhì)量 (QoS) 類(lèi)。 Kubernetes 基于每個(gè) Pod 中容器的資源請(qǐng)求和限制為 Pod 設(shè)置 QoS 類(lèi)。Kubernetes 使用 QoS 類(lèi)來(lái)決定從遇到節(jié)點(diǎn)壓力的 Node 中驅(qū)逐哪些 Pod。可選的 QoS 類(lèi)有 Guaranteed、Burstable 和 BestEffort。 當(dāng)一個(gè) Node 耗盡資源時(shí)，Kubernetes 將首先驅(qū)逐在該 Node 上運(yùn)行的 BestEffort Pod， 然后是 Burstable Pod，最后是 Guaranteed Pod。當(dāng)這種驅(qū)逐是由于資源壓力時(shí)， 只有超出資源請(qǐng)求的 Pod 才是被驅(qū)逐的候選對(duì)象。

Guaranteed

Guaranteed Pod 具有最嚴(yán)格的資源限制，并且最不可能面臨驅(qū)逐。 在這些 Pod 超過(guò)其自身的限制或者沒(méi)有可以從 Node 搶占的低優(yōu)先級(jí) Pod 之前， 這些 Pod 保證不會(huì)被殺死。這些 Pod 不可以獲得超出其指定 limit 的資源。這些 Pod 也可以使用 static CPU 管理策略來(lái)使用獨(dú)占的 CPU。

Pod 被賦予 Guaranteed QoS 類(lèi)的幾個(gè)判據(jù)：

• Pod 中的每個(gè)容器必須有內(nèi)存 limit 和內(nèi)存 request。
• 對(duì)于 Pod 中的每個(gè)容器，內(nèi)存 limit 必須等于內(nèi)存 request。
• Pod 中的每個(gè)容器必須有 CPU limit 和 CPU request。
• 對(duì)于 Pod 中的每個(gè)容器，CPU limit 必須等于 CPU request。

Burstable

Burstable Pod 有一些基于 request 的資源下限保證，但不需要特定的 limit。 如果未指定 limit，則默認(rèn)為其 limit 等于 Node 容量，這允許 Pod 在資源可用時(shí)靈活地增加其資源。 在由于 Node 資源壓力導(dǎo)致 Pod 被驅(qū)逐的情況下，只有在所有 BestEffort Pod 被驅(qū)逐后 這些 Pod 才會(huì)被驅(qū)逐。因?yàn)?Burstable Pod 可以包括沒(méi)有資源 limit 或資源 request 的容器， 所以 Burstable Pod 可以嘗試使用任意數(shù)量的節(jié)點(diǎn)資源。

Pod 被賦予 Burstable QoS 類(lèi)的幾個(gè)判據(jù)：

• Pod 不滿足針對(duì) QoS 類(lèi) Guaranteed 的判據(jù)。
• Pod 中至少一個(gè)容器有內(nèi)存或 CPU 的 request 或 limit。

BestEffort

BestEffort QoS 類(lèi)中的 Pod 可以使用未專門(mén)分配給其他 QoS 類(lèi)中的 Pod 的節(jié)點(diǎn)資源。 例如若你有一個(gè)節(jié)點(diǎn)有 16 核 CPU 可供 kubelet 使用，并且你將 4 核 CPU 分配給一個(gè) Guaranteed Pod， 那么 BestEffort QoS 類(lèi)中的 Pod 可以嘗試任意使用剩余的 12 核 CPU。

如果 Pod 不滿足 Guaranteed 或 Burstable 的判據(jù)，則它的 QoS 類(lèi)為 BestEffort。 換言之，只有當(dāng) Pod 中的所有容器沒(méi)有內(nèi)存 limit 或內(nèi)存 request，也沒(méi)有 CPU limit 或 CPU request 時(shí)，Pod 才是 BestEffort。Pod 中的容器可以請(qǐng)求（除 CPU 或內(nèi)存之外的） 其他資源并且仍然被歸類(lèi)為 BestEffort

配置 Pod 的服務(wù)質(zhì)量

配置 Pod 以讓其歸屬于特定的 [服務(wù)質(zhì)量類(lèi)（Quality of Service class，QoS class） Kubernetes 在 Node 資源不足時(shí)使用 QoS 類(lèi)來(lái)就驅(qū)逐 Pod 作出決定。

Kubernetes 創(chuàng)建 Pod 時(shí)，會(huì)將如下 QoS 類(lèi)之一設(shè)置到 Pod 上：

• Guaranteed
• Burstable
• BestEffort

創(chuàng)建一個(gè) QoS 類(lèi)為 Guaranteed 的 Pod

對(duì)于 QoS 類(lèi)為 Guaranteed 的 Pod：

• Pod 中的每個(gè)容器都必須指定內(nèi)存限制和內(nèi)存請(qǐng)求。
• 對(duì)于 Pod 中的每個(gè)容器，內(nèi)存限制必須等于內(nèi)存請(qǐng)求。
• Pod 中的每個(gè)容器都必須指定 CPU 限制和 CPU 請(qǐng)求。
• 對(duì)于 Pod 中的每個(gè)容器，CPU 限制必須等于 CPU 請(qǐng)求。

這些限制同樣適用于初始化容器和應(yīng)用程序容器。 臨時(shí)容器（Ephemeral Container） 無(wú)法定義資源，因此不受這些約束限制

1. 下面是包含一個(gè) Container 的 Pod 清單。該 Container 設(shè)置了內(nèi)存請(qǐng)求和內(nèi)存限制，值都是 200 MiB。 該 Container 設(shè)置了 CPU 請(qǐng)求和 CPU 限制，值都是 700 milliCPU

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

• 查看pod詳情

kubectl get pod qos-demo --namespace=qos-example --output=yaml
## 結(jié)果表明 Kubernetes 為 Pod 配置的 QoS 類(lèi)為 Guaranteed。 結(jié)果也確認(rèn)了 Pod 容器設(shè)置了與內(nèi)存限制匹配的內(nèi)存請(qǐng)求，設(shè)置了與 CPU 限制匹配的 CPU 請(qǐng)求
spec:
  containers:
    ...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    ...
status:
  qosClass: Guaranteed

說(shuō)明：

如果某 Container 指定了自己的內(nèi)存限制，但沒(méi)有指定內(nèi)存請(qǐng)求，Kubernetes 會(huì)自動(dòng)為它指定與內(nèi)存限制相等的內(nèi)存請(qǐng)求。同樣，如果容器指定了自己的 CPU 限制， 但沒(méi)有指定 CPU 請(qǐng)求，Kubernetes 會(huì)自動(dòng)為它指定與 CPU 限制相等的 CPU 請(qǐng)求。

創(chuàng)建一個(gè) QoS 類(lèi)為 Burstable 的 Pod

如果滿足下面條件，Kubernetes 將會(huì)指定 Pod 的 QoS 類(lèi)為 Burstable：

• Pod 不符合 Guaranteed QoS 類(lèi)的標(biāo)準(zhǔn)。
• Pod 中至少一個(gè) Container 具有內(nèi)存或 CPU 的請(qǐng)求或限制。

2. 下面是包含一個(gè) Container 的 Pod 清單。該 Container 設(shè)置的內(nèi)存限制為 200 MiB， 內(nèi)存請(qǐng)求為 100 MiB。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

• 查看 Pod 詳情：

kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml

## 結(jié)果表明 Kubernetes 為 Pod 配置的 QoS 類(lèi)為 Burstable。
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: qos-demo-2-ctr
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi
  ...
status:
  qosClass: Burstable

創(chuàng)建一個(gè) QoS 類(lèi)為 BestEffort 的 Pod

對(duì)于 QoS 類(lèi)為 BestEffort 的 Pod，Pod 中的 Container 必須沒(méi)有設(shè)置內(nèi)存和 CPU 限制或請(qǐng)求。

1. 下面是包含一個(gè) Container 的 Pod 清單。該 Container 沒(méi)有設(shè)置內(nèi)存和 CPU 限制或請(qǐng)求。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

• 查看 Pod 詳情：

kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml

### 結(jié)果表明 Kubernetes 為 Pod 配置的 QoS 類(lèi)為 BestEffort。
spec:
  containers:
    ...
    resources: {}
  ...
status:
  qosClass: BestEffort

創(chuàng)建包含兩個(gè)容器的 Pod

4. 下面是包含兩個(gè) Container 的 Pod 清單。一個(gè) Container 指定內(nèi)存請(qǐng)求為 200 MiB。 另外一個(gè) Container 沒(méi)有指定任何請(qǐng)求或限制。

• 注意此 Pod 滿足 Burstable QoS 類(lèi)的標(biāo)準(zhǔn)。也就是說(shuō)它不滿足 Guaranteed QoS 類(lèi)標(biāo)準(zhǔn)， 因?yàn)樗?Container 之一設(shè)有內(nèi)存請(qǐng)求。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-4
  namespace: qos-example
spec:
  containers:

  - name: qos-demo-4-ctr-1
    image: nginx
    resources:
      requests:
        memory: "200Mi"

  - name: qos-demo-4-ctr-2
    image: redis

• 查看 Pod 詳情

kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml

### 結(jié)果表明 Kubernetes 為 Pod 配置的 QoS 類(lèi)為 Burstable：
spec:
  containers:
    ...
    name: qos-demo-4-ctr-1
    resources:
      requests:
        memory: 200Mi
    ...
    name: qos-demo-4-ctr-2
    resources: {}
    ...
status:
  qosClass: Burstable

檢視 Pod 的 QoS 類(lèi)

也可以只查看你所需要的字段，而不是查看所有字段：

kubectl --namespace=qos-example get pod qos-demo-4 -o jsonpath='{ .status.qosClass}{"\n"}'

調(diào)整分配給容器的 CPU 和內(nèi)存資源

此功能要求Kubernetes 服務(wù)器版本必須不低于版本 1.27

? 如何在不重啟 Pod 或其容器的情況下調(diào)整分配給運(yùn)行中 Pod 容器的 CPU 和內(nèi)存資源。 Kubernetes 節(jié)點(diǎn)會(huì)基于 Pod 的 requests 為 Pod 分配資源， 并基于 Pod 的容器中指定的 limits 限制 Pod 的資源使用。

對(duì)于原地調(diào)整 Pod 資源而言：

• 針對(duì) CPU 和內(nèi)存資源的容器的 requests 和 limits 是可變更的。

• Pod 狀態(tài)中 containerStatuses 的 allocatedResources 字段反映了分配給 Pod 容器的資源。

• Pod 狀態(tài)中 containerStatuses 的 resources 字段反映了如同容器運(yùn)行時(shí)所報(bào)告的、針對(duì)正運(yùn)行的容器配置的實(shí)際資源 requests 和 limits。

• Pod 狀態(tài)中resize字段顯示上次請(qǐng)求待處理的調(diào)整狀態(tài)。此字段可以具有以下值：

  • Proposed：此值表示請(qǐng)求調(diào)整已被確認(rèn)，并且請(qǐng)求已被驗(yàn)證和記錄。
  • InProgress：此值表示節(jié)點(diǎn)已接受調(diào)整請(qǐng)求，并正在將其應(yīng)用于 Pod 的容器。
  • Deferred：此值意味著在此時(shí)無(wú)法批準(zhǔn)請(qǐng)求的調(diào)整，節(jié)點(diǎn)將繼續(xù)重試。 當(dāng)其他 Pod 退出并釋放節(jié)點(diǎn)資源時(shí)，調(diào)整可能會(huì)被真正實(shí)施。
  • Infeasible：此值是一種信號(hào)，表示節(jié)點(diǎn)無(wú)法承接所請(qǐng)求的調(diào)整值。 如果所請(qǐng)求的調(diào)整超過(guò)節(jié)點(diǎn)可分配給 Pod 的最大資源，則可能會(huì)發(fā)生這種情況

容器調(diào)整策略

調(diào)整策略允許更精細(xì)地控制 Pod 中的容器如何針對(duì) CPU 和內(nèi)存資源進(jìn)行調(diào)整。 例如，容器的應(yīng)用程序可以處理 CPU 資源的調(diào)整而不必重啟， 但是調(diào)整內(nèi)存可能需要應(yīng)用程序重啟，因此容器也必須重啟。

為了實(shí)現(xiàn)這一點(diǎn)，容器規(guī)約允許用戶指定 resizePolicy。 針對(duì)調(diào)整 CPU 和內(nèi)存可以設(shè)置以下重啟策略：

• NotRequired：在運(yùn)行時(shí)調(diào)整容器的資源。
• RestartContainer：重啟容器并在重啟后應(yīng)用新資源。
• 如果未指定 resizePolicy[*].restartPolicy，則默認(rèn)為 NotRequired。

如果 Pod 的 restartPolicy 為 Never，則 Pod 中所有容器的調(diào)整重啟策略必須被設(shè)置為 NotRequired。

• 創(chuàng)建指導(dǎo)只有的Pod

1. 配置一個(gè) Pod，其中 CPU 可以在不重啟容器的情況下進(jìn)行調(diào)整，但是內(nèi)存調(diào)整需要重啟容器。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
    - name: qos-demo-ctr-5
      image: nginx
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: RestartContainer
      resources:
        limits:
          memory: "200Mi"
          cpu: "700m"
        requests:
          memory: "200Mi"
          cpu: "700m"

在上述示例中，如果所需的 CPU 和內(nèi)存請(qǐng)求或限制已更改，則容器將被重啟以調(diào)整其內(nèi)存。

• 更新Pod資源

設(shè)要求的 CPU 需求已上升，現(xiàn)在需要 0.8 CPU。這通常由 VerticalPodAutoscaler (VPA) 這樣的實(shí)體確定并可能以編程方式應(yīng)用。

說(shuō)明：

盡管你可以更改 Pod 的請(qǐng)求和限制以表示新的期望資源， 但無(wú)法更改 Pod 創(chuàng)建時(shí)所歸屬的 QoS 類(lèi)。

在對(duì) Pod 的 Container 執(zhí)行 patch 命令，將容器的 CPU 請(qǐng)求和限制均設(shè)置為 800m：

kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

在 Pod 已打補(bǔ)丁后查詢其詳細(xì)信息。

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

##以下 Pod 規(guī)約反映了更新后的 CPU 請(qǐng)求和限制。
spec:
  containers:
    ...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
...
  containerStatuses:
...
    allocatedResources:
      cpu: 800m
      memory: 200Mi
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
    restartCount: 0
    started: true

觀察到 allocatedResources 的值已更新，反映了新的預(yù)期 CPU 請(qǐng)求。 這表明節(jié)點(diǎn)能夠容納提高后的 CPU 資源需求。

在 Container 狀態(tài)中，更新的 CPU 資源值顯示已應(yīng)用新的 CPU 資源。 Container 的 restartCount 保持不變，表示已在無(wú)需重啟容器的情況下調(diào)整了容器的 CPU 資源。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-480091.html

到了這里，關(guān)于【云原生|Kubernetes】09-Pod的CPU和內(nèi)存的請(qǐng)求與限制的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！