當在Kubernetes中使用容器時，重要的是要知道所涉及的資源是什么以及如何需要它們。有些進程比其他進程需要更多的CPU或內存。有些是關鍵的，不應該被餓死。

知道了這一點，我們應該正確配置我們的容器和Pod，以獲得兩者的最佳效果。

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

• Kubernetes 的Limits和Requests介紹
• 實踐案例
• Kubernetes Requests
• Kubernetes Limits
• CPU的特殊性
• 內存的特殊性
• Namespace ResourceQuta
• Namespace LimitRange
• 總結

Kubernetes的Limits和Requests介紹

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

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

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

image.png

實踐案例

讓我們來看看下面這個deployment，我們需要為兩個不同的容器在CPU和內存上設置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配置的節點上，可以得到如下信息。

1. Pod的有效請求是400 MiB的內存和600 millicores的CPU，你需要一個有足夠自由可分配空間的節點來安排pod。
2. Redis容器的CPU份額將是512，而busybox容器是102，Kubernetes總是為每個核心分配1024個份額，因此redis：1024 * 0.5 cores ? 512和busybox：1024 * 0.1核 ? 102
3. 如果Redis容器試圖分配超過600MB的RAM，它將被OOM殺死，很可能使pod失敗。
4. 如果Redis試圖在每100ms內使用超過100ms的CPU，（因為我們有4個核心，可用時間為每100ms 400ms），它將遭受CPU節流，導致性能下降。
5. 如果Busybox容器試圖分配超過200MB的RAM，它將被OOM殺死，導致一個失敗的Pod。
6. 如果Busybox試圖每100ms使用超過30ms的CPU，它將遭受CPU節流，導致性能下降。

Kubernetes Requests

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

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

當一個Pod被調度時，kube-scheduler將檢查Kubernetes請求，以便將其分配給一個特定的節點：該節點至少可以滿足Pod中所有容器的這個數量。如果請求的數量高于可用的資源，Pod將不會被安排，并保持在Pending狀態。

關于Pending狀態的更多信息，請查看Understanding Kubernetes Pod pending problems【1】。

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

resources:
   requests:
        cpu: 0.1
        memory: 4Mi

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

• 當把Pod分配給一個節點時，所以Pod中的容器的指定請求被滿足。
• 在運行時，指定的請求量將被保證為該Pod中的容器的最小值。

Kubernetes Limits

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

這意味著容器的消耗量永遠不能超過指定的內存量或CPU量。

resources:
      limits:
        cpu: 0.5
        memory: 100Mi

Limits通常用于以下場景：

• 當把Pod分配給一個節點時，如果沒有設置請求，默認情況下，Kubernetes將分配請求=限制。
• 在運行時，Kubernetes將檢查Pod中的容器所消耗的資源量是否高于限制所顯示的數量。

CPU的特性

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

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

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

內存的特性

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

在Kubernetes中，內存的單位是字節。

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

!! 一個Mebibyte（以及它們的類似物Kibibyte、Gibibyte...）是20字節的2次方。它的出現是為了避免與公制中的Kilo、Mega定義相混淆。你應該使用這個符號，因為它是字節的典型定義，而Kilo和Mega是1000的倍數。

最佳實踐

在Kubernetes中，你應該很少使用限制來控制你的資源使用。這是因為如果你想避免饑餓（確保每個重要的進程都能得到它的份額），你應該首先使用請求。

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

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

如果你在一個Pod的所有容器中設置一個等于限制的請求值，該Pod將獲得保證的服務質量。

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

Namespace ResourceQuata

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

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

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數量。
• requests.memory：這個命名空間中所有請求的最大內存量。
• limits.cpu：這個命名空間中所有限制的最大CPU數量。
• limits.memory：這個命名空間中所有限制的總和的最大內存量。

然后，將其應用于你的命名空間。

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

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

kubectl get resourcequota -n mynamespace

注意，如果你為命名空間中的特定資源設置了ResourceQuota，那么你就需要為該命名空間中的每個Pod指定相應的限制或請求。否則，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，其容器限制或請求超過了當前的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很有用。但如果我們想給里面的元素提供默認值，會發生什么？

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

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。如果沒有指定，創建的容器將有這個值。
• min: 創建的容器不能有比這更小的限制或請求。
• max: 創建的容器不能有大于此值的限制或請求。

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

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

現在，想象一下，你添加一個新的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

請注意，默認情況下，Pod中的所有容器將有效地擁有100m CPU的請求，即使沒有設置LimitRanges。

總結

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

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

規模過小或專用于極少的CPU或內存將導致應用程序不能正常運行，甚至Pod被驅逐。

如前所述，除非在非常特殊的情況下，否則不應該使用Kubernetes限制，因為它們可能會造成更大的傷害。在內存不足的情況下，容器有可能被殺死，在CPU不足的情況下，容器有可能被節流。

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

文檔

【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