一文搞懂Kubernetes的Limits和Requests

　　Kubernetes将Limits定义为一个容器使用的最大资源量，这意味着容器的消耗量永远不能超过所显示的内存量或CPU量。

　　当在Kubernetes中使用容器时，重要的是要知道所涉及的资源是什么以及如何需要它们。有些进程比其他进程需要更多的CPU或内存。有些是关键的，不应该被饿死。

　　知道了这一点，我们应该正确配置我们的容器和Pod，以获得两者的最佳效果。

　　在这篇文章中，我们将看到。

　　1.Kubernetes 的Limits和Requests介绍

　　2.实践案例

　　3.Kubernetes Requests

　　4.Kubernetes Limits

　　5.CPU的特殊性

　　6.内存的特殊性

　　7.Namespace ResourceQuta

　　8.Namespace LimitRange

　　9.总结

　　Kubernetes的Limits和Requests介绍

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

　　Kubernetes将Limits定义为一个容器使用的最大资源量，这意味着容器的消耗量永远不能超过所显示的内存量或CPU量。

　　另一方面，Requests是指为容器保留的资源的最小保证量。

　　image.png

　　实践案例

　　让我们来看看下面这个deployment，我们需要为两个不同的容器在CPU和内存上设置Limits和Requests。

　　复制

　　1.  kind: Deployment

　　2.  apiVersion: extensions/v1beta1

　　3.  …

　　4.  template:

　　5.  spec:

　　6.  containers:

　　7.  - name: redis

　　8.  image: redis:5.0.3-alpine

　　9.  resources:

　　10.  limits:

　　11.  memory: 600Mi

　　12.  cpu: 1

　　13.  requests:

　　14.  memory: 300Mi

　　15.  cpu: 500m

　　16.  - name: busybox

　　17.  image: busybox:1.28

　　18.  resources:

　　19.  limits:

　　20.  memory: 200Mi

　　21.  cpu: 300m

　　22.  requests:

　　23.  memory: 100Mi

　　24.  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的内存。

　　复制

　　1.  resources:

　　2.  requests:

　　3.  cpu: 0.1

　　4.  memory: 4Mi

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

　　1.当把Pod分配给一个节点时，所以Pod中的容器的指定请求被满足。

　　2.在运行时，指定的请求量将被保证为该Pod中的容器的最小值。

　　Kubernetes Limits

　　Kubernetes将Limits定义为一个容器使用的最大资源量。

　　这意味着容器的消耗量永远不能超过指定的内存量或CPU量。

　　复制

　　1.  resources:

　　2.  limits:

　　3.  cpu: 0.5

　　4.  memory: 100Mi

　　Limits通常用于以下场景：

　　1.当把Pod分配给一个节点时，如果没有设置请求，默认情况下，Kubernetes将分配请求=限制。

　　2.在运行时，Kubernetes将检查Pod中的容器所消耗的资源量是否高于限制所显示的数量。

　　CPU的特性

　　CPU是一种可压缩的资源，这意味着它可以被拉伸，以满足所有的需求。如果进程要求太多的CPU，其中一些将被节制。

　　CPU代表计算处理时间，以核为单位。

　　1.你可以用毫微米(m)来表示比一个核心更小的数量(例如，500米是半个核心)。

　　2.最小的数量是1m

　　3.一个节点可能有一个以上的核心可用，所以请求CPU>1是可能的

　　内存的特性

　　内存是一种不可压缩的资源，意味着它不能像CPU那样被拉伸。如果一个进程没有得到足够的内存来工作，这个进程就会被杀死。

　　在Kubernetes中，内存的单位是字节。

　　1.你可以用，E，P，T，G，M，k来代表Exabyte，Petabyte，Terabyte，Gigabyte，Megabyte和kilobyte，尽管只有最后四个是常用的。(例如，500M, 4G)

　　2.警告：不要用小写的m表示内存(这代表Millibytes，低得离谱)

　　3.你可以用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限制，确保其中的实体不能消耗超过这个数量。

　　复制

　　1.  apiVersion: v1

　　2.  kind: ResourceQuota

　　3.  metadata:

　　4.  name: mem-cpu-demo

　　5.  spec:

　　6.  hard:

　　7.  requests.cpu: 2

　　8.  requests.memory: 1Gi

　　9.  limits.cpu: 3

　　10.  limits.memory: 2Gi

　　requests.cpu：这个命名空间中所有请求的最大CPU数量。

　　requests.memory：这个命名空间中所有请求的最大内存量。

　　limits.cpu：这个命名空间中所有限制的最大CPU数量。

　　limits.memory：这个命名空间中所有限制的总和的最大内存量。

　　然后，将其应用于你的命名空间。

　　复制

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

　　你可以用以下方法列出一个命名空间的当前ResourceQuota。

　　复制

　　1.  kubectl get resourcequota -n mynamespace

　　注意，如果你为命名空间中的特定资源设置了ResourceQuota，那么你就需要为该命名空间中的每个Pod指定相应的限制或请求。否则，Kubernetes将返回一个 "failed quota"的错误。

　　复制

　　1.  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=1Gi1.

　　Namespace LimitRange

　　如果我们想限制一个命名空间可分配的资源总量，ResourceQuotas很有用。但如果我们想给里面的元素提供默认值，会发生什么?

　　LimitRanges是一种Kubernetes策略，它限制了命名空间中每个实体的资源设置。

　　复制

　　1.  apiVersion: v1

　　2.  kind: LimitRange

　　3.  metadata:

　　4.  name: cpu-resource-constraint

　　5.  spec:

　　6.  limits:

　　7.  - default:

　　8.  cpu: 500m

　　9.  defaultRequest:

　　10.  cpu: 500m

　　11.  min:

　　12.  cpu: 100m

　　13.  max:

　　14.  cpu: "1"

　　15.  type: Container

　　default。如果没有指定，创建的容器将有这个值。

　　min: 创建的容器不能有比这更小的限制或请求。

　　max: 创建的容器不能有大于此值的限制或请求。

　　以后，如果你创建一个没有设置请求或限制的新Pod，LimitRange会自动为其所有的容器设置这些值。

　　复制

　　1.  Limits:

　　2.  cpu: 500m

　　3.  Requests:

　　4.  cpu: 100m

　　现在，想象一下，你添加一个新的Pod，以1200M为限。你会收到以下错误。

　　复制

　　1.  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

　　来源： 运维开发故事

  　　>>>>>>点击进入云计算专题