一文搞懂Kubernetes的Limits和Requests

作者：喬克 2023-02-10 10:56:56

云計(jì)算云原生

Kubernetes將Limits定義為一個容器使用的最大資源量，這意味著容器的消耗量永遠(yuǎn)不能超過所顯示的內(nèi)存量或CPU量。

當(dāng)在Kubernetes中使用容器時，重要的是要知道所涉及的資源是什么以及如何需要它們。有些進(jìn)程比其他進(jìn)程需要更多的CPU或內(nèi)存。有些是關(guān)鍵的，不應(yīng)該被餓死。

知道了這一點(diǎn)，我們應(yīng)該正確配置我們的容器和Pod，以獲得兩者的最佳效果。

在這篇文章中，我們將看到。

Kubernetes 的Limits和Requests介紹
實(shí)踐案例
Kubernetes Requests
Kubernetes Limits
CPU的特殊性
內(nèi)存的特殊性
Namespace ResourceQuta
Namespace LimitRange
總結(jié)

Kubernetes的Limits和Requests介紹

在使用Kubernetes時，Limits和Requests是重要的配置，主要包含CPU和內(nèi)存的配置。

Kubernetes將Limits定義為一個容器使用的最大資源量，這意味著容器的消耗量永遠(yuǎn)不能超過所顯示的內(nèi)存量或CPU量。

另一方面，Requests是指為容器保留的資源的最小保證量。

image.png

實(shí)踐案例

讓我們來看看下面這個deployment，我們需要為兩個不同的容器在CPU和內(nèi)存上設(shè)置Limits和Requests。

kind: Deployment
apiVersion: extensions/v1beta1
…
template:
  spec:
    containers:
      - name: redis
        image: redis:5.0.3-alpine
        resources:
          limits:
            memory: 600Mi
            cpu: 1
          requests:
            memory: 300Mi
            cpu: 500m
      - name: busybox
        image: busybox:1.28
        resources:
          limits:
            memory: 200Mi
            cpu: 300m
          requests:
            memory: 100Mi
            cpu: 100m

假如，我們要把該deployment部署到4C16G配置的節(jié)點(diǎn)上，可以得到如下信息。

Pod的有效請求是400 MiB的內(nèi)存和600 millicores的CPU，你需要一個有足夠自由可分配空間的節(jié)點(diǎn)來安排pod。
Redis容器的CPU份額將是512，而busybox容器是102，Kubernetes總是為每個核心分配1024個份額，因此redis：1024 * 0.5 cores ? 512和busybox：1024 * 0.1核 ? 102
如果Redis容器試圖分配超過600MB的RAM，它將被OOM殺死，很可能使pod失敗。
如果Redis試圖在每100ms內(nèi)使用超過100ms的CPU，（因?yàn)槲覀冇?個核心，可用時間為每100ms 400ms），它將遭受CPU節(jié)流，導(dǎo)致性能下降。
如果Busybox容器試圖分配超過200MB的RAM，它將被OOM殺死，導(dǎo)致一個失敗的Pod。
如果Busybox試圖每100ms使用超過30ms的CPU，它將遭受CPU節(jié)流，導(dǎo)致性能下降。

Kubernetes Requests

Kubernetes將請求定義為容器使用的資源的最低保證量。

基本上，它將設(shè)定容器所要消耗的資源的最小數(shù)量。

當(dāng)一個Pod被調(diào)度時，kube-scheduler將檢查Kubernetes請求，以便將其分配給一個特定的節(jié)點(diǎn)：該節(jié)點(diǎn)至少可以滿足Pod中所有容器的這個數(shù)量。如果請求的數(shù)量高于可用的資源，Pod將不會被安排，并保持在Pending狀態(tài)。

關(guān)于Pending狀態(tài)的更多信息，請查看Understanding Kubernetes Pod pending problems【1】。

在這個例子中，在容器定義中，我們設(shè)置了一個請求，要求100m核心的CPU和4Mi的內(nèi)存。

resources:
   requests:
        cpu: 0.1
        memory: 4Mi

Requests通常被使用在以下場景：

當(dāng)把Pod分配給一個節(jié)點(diǎn)時，所以Pod中的容器的指定請求被滿足。
在運(yùn)行時，指定的請求量將被保證為該P(yáng)od中的容器的最小值。

Kubernetes Limits

Kubernetes將Limits定義為一個容器使用的最大資源量。

這意味著容器的消耗量永遠(yuǎn)不能超過指定的內(nèi)存量或CPU量。

resources:
      limits:
        cpu: 0.5
        memory: 100Mi

Limits通常用于以下場景：

當(dāng)把Pod分配給一個節(jié)點(diǎn)時，如果沒有設(shè)置請求，默認(rèn)情況下，Kubernetes將分配請求=限制。
在運(yùn)行時，Kubernetes將檢查Pod中的容器所消耗的資源量是否高于限制所顯示的數(shù)量。

CPU的特性

CPU是一種可壓縮的資源，這意味著它可以被拉伸，以滿足所有的需求。如果進(jìn)程要求太多的CPU，其中一些將被節(jié)制。

CPU代表計(jì)算處理時間，以核為單位。

你可以用毫微米（m）來表示比一個核心更小的數(shù)量（例如，500米是半個核心）。
最小的數(shù)量是1m
一個節(jié)點(diǎn)可能有一個以上的核心可用，所以請求CPU>1是可能的

內(nèi)存的特性

內(nèi)存是一種不可壓縮的資源，意味著它不能像CPU那樣被拉伸。如果一個進(jìn)程沒有得到足夠的內(nèi)存來工作，這個進(jìn)程就會被殺死。

在Kubernetes中，內(nèi)存的單位是字節(jié)。

你可以用，E，P，T，G，M，k來代表Exabyte，Petabyte，Terabyte，Gigabyte，Megabyte和kilobyte，盡管只有最后四個是常用的。(例如，500M, 4G)
警告：不要用小寫的m表示內(nèi)存（這代表Millibytes，低得離譜）
你可以用Mi來定義Mebibytes，其余的也可以用Ei、Pi、Ti來定義（例如，500Mi）

!! 一個Mebibyte（以及它們的類似物Kibibyte、Gibibyte...）是20字節(jié)的2次方。它的出現(xiàn)是為了避免與公制中的Kilo、Mega定義相混淆。你應(yīng)該使用這個符號，因?yàn)樗亲止?jié)的典型定義，而Kilo和Mega是1000的倍數(shù)。

最佳實(shí)踐

在Kubernetes中，你應(yīng)該很少使用限制來控制你的資源使用。這是因?yàn)槿绻阆氡苊怵囸I（確保每個重要的進(jìn)程都能得到它的份額），你應(yīng)該首先使用請求。

通過設(shè)置限制，你只是防止進(jìn)程在特殊情況下檢索額外的資源，在內(nèi)存方面造成OOM殺戮，在CPU方面造成Throttling（進(jìn)程將需要等待CPU可以再次使用）。

欲了解更多信息，請查看article about OOM and Throttling【2】。

如果你在一個Pod的所有容器中設(shè)置一個等于限制的請求值，該P(yáng)od將獲得保證的服務(wù)質(zhì)量。

還需要注意的是，資源使用量高于請求的Pod更有可能被驅(qū)逐，所以設(shè)置非常低的請求會造成弊大于利。可以在Pod eviction and Quality of Service【3】查看。

Namespace ResourceQuata

由于命名空間的存在，我們可以將Kubernetes資源隔離到不同的組，也稱為租戶。

通過ResourceQuota，你可以為整個命名空間設(shè)置一個內(nèi)存或CPU限制，確保其中的實(shí)體不能消耗超過這個數(shù)量。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: 2
    requests.memory: 1Gi
    limits.cpu: 3
    limits.memory: 2Gi

requests.cpu：這個命名空間中所有請求的最大CPU數(shù)量。
requests.memory：這個命名空間中所有請求的最大內(nèi)存量。
limits.cpu：這個命名空間中所有限制的最大CPU數(shù)量。
limits.memory：這個命名空間中所有限制的總和的最大內(nèi)存量。

然后，將其應(yīng)用于你的命名空間。

kubectl apply -f resourcequota.yaml --namespace=mynamespace

你可以用以下方法列出一個命名空間的當(dāng)前ResourceQuota。

kubectl get resourcequota -n mynamespace

注意，如果你為命名空間中的特定資源設(shè)置了ResourceQuota，那么你就需要為該命名空間中的每個Pod指定相應(yīng)的限制或請求。否則，Kubernetes將返回一個 "failed quota"的錯誤。

Error from server (Forbidden): error when creating "mypod.yaml": pods "mypod" is forbidden: failed quota: mem-cpu-demo: must specify limits.cpu,limits.memory,requests.cpu,requests.memory

如果你試圖添加一個新的Pod，其容器限制或請求超過了當(dāng)前的ResourceQuota，Kubernetes將返回一個 "exceeded quota "的錯誤。

Error from server (Forbidden): error when creating "mypod.yaml": pods "mypod" is forbidden: exceeded quota: mem-cpu-demo, requested: limits.memory=2Gi,requests.memory=2Gi, used: limits.memory=1Gi,requests.memory=1Gi, limited: limits.memory=2Gi,requests.memory=1Gi

Namespace LimitRange

如果我們想限制一個命名空間可分配的資源總量，ResourceQuotas很有用。但如果我們想給里面的元素提供默認(rèn)值，會發(fā)生什么？

LimitRanges是一種Kubernetes策略，它限制了命名空間中每個實(shí)體的資源設(shè)置。

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:
      cpu: 500m
    defaultRequest:
      cpu: 500m
    min:
      cpu: 100m
    max:
      cpu: "1"
    type: Container

default。如果沒有指定，創(chuàng)建的容器將有這個值。
min: 創(chuàng)建的容器不能有比這更小的限制或請求。
max: 創(chuàng)建的容器不能有大于此值的限制或請求。

以后，如果你創(chuàng)建一個沒有設(shè)置請求或限制的新Pod，LimitRange會自動為其所有的容器設(shè)置這些值。

Limits:
      cpu:  500m
    Requests:
      cpu:  100m

現(xiàn)在，想象一下，你添加一個新的Pod，以1200M為限。你會收到以下錯誤。

Error from server (Forbidden): error when creating "pods/mypod.yaml": pods "mypod" is forbidden: maximum cpu usage per Container is 1, but limit is 1200m

請注意，默認(rèn)情況下，Pod中的所有容器將有效地?fù)碛?00m CPU的請求，即使沒有設(shè)置LimitRanges。

總結(jié)

為我們的Kubernetes集群選擇最佳限制是關(guān)鍵，以便獲得最佳的能源消耗和成本。

為我們的Pod分配過多的資源可能會導(dǎo)致成本激增。

規(guī)模過小或?qū)Ｓ糜跇O少的CPU或內(nèi)存將導(dǎo)致應(yīng)用程序不能正常運(yùn)行，甚至Pod被驅(qū)逐。

如前所述，除非在非常特殊的情況下，否則不應(yīng)該使用Kubernetes限制，因?yàn)樗鼈兛赡軙斐筛蟮膫ΑＴ趦?nèi)存不足的情況下，容器有可能被殺死，在CPU不足的情況下，容器有可能被節(jié)流。

對于請求，當(dāng)你需要確保一個進(jìn)程獲得一個有保障的資源份額時，可以使用它們。

文檔

【1】https://sysdig.com/blog/kubernetes-pod-pending-problems/
【2】https://sysdig.com/blog/troubleshoot-kubernetes-oom/
【3】?https://sysdig.com/blog/kubernetes-pod-evicted/

原文：https://sysdig.com/blog/kubernetes-limits-requests/作者：JAVIER MARTíNEZ

責(zé)任編輯：武曉燕來源：運(yùn)維開發(fā)故事