草庐IT

一文搞懂Kubernetes的Limits和Requests

乔克 2023-03-28 原文
当在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

一文Kubernetesspanstylecolor云计算云原生$KubernetesLimitsRequests

有关一文搞懂Kubernetes的Limits和Requests的更多相关文章

  1. ruby-on-rails - 使用 Rails 编写 RSpec 测试时，spec/requests 文件夹和 spec/controllers 应该放什么？ - 2

    我对Rails还很陌生，并试图通过从一开始就实现测试来以“正确”的方式做事。昨天我使用脚手架生成器创建了我的第一个模型/View/Controller配置。虽然有人告诉我您真的不应该使用脚手架，但它很有用，因为我可以了解Rails代码的结构。我注意到的一件事是，自动生成的RSpec大部分放在spec/controllers文件夹中。然而当我看到thisepisodeofRailscasts,我注意到他用了railsgenerateintegration_test[test_name]将单个测试文件放入spec/requests文件夹的命令。然而，他编写的所有测试都与Controller

  2. 一文解决关于VLAN所有的疑惑 - 2

    一文解决关于VLAN所有的疑惑VLAN基本概念为什么需要VLAN？怎么在交换机上划分VLAN，VLAN的工作原理有了子网，已经隔离了广播，还需要VLAN干啥？只进行子网划分，不进行VLAN划分VLAN划分与子网划分附加VLAN信息的方法VLAN划分交换机的端口类型（Access和Trunk）一、访问链接二、汇聚链接汇聚链接VLAN间通信为什么要进行VLAN间通信？路由器实现VLAN间通信路由器和交换机的连接方式通信细节三层交换机实现VLAN间通信加速VLAN间通信三层交换机与路由器三层交换机路由器路由器和交换机配合构建LAN的实例使用VLAN设计局域网的特点VLAN增加网络的灵活性不使用VLA

  3. 一文让你彻底掌握操作符（超详细教程） - 2

    ✅作者简介：大家好，我是小杨📃个人主页：「小杨」的csdn博客🔥系列专栏：小杨带你玩转C语言【初阶】🐳希望大家多多支持🥰一起进步呀！大家好呀！我是小杨。小杨花几天的时间将C语言中的操作符这部分知识做了一个大总结，在方便自己复习的同时也能够帮助到大家。通篇字数在一万字左右，可以算作是非常详细了，一文就可以带领大家彻底掌握操作符这部分内容，文章很长建议先收藏再看，防止下次想看就找不到啦。文章目录✍1，算术操作符✍2，移位操作符    🔍2.1,左移操作符    🔍2.2,右移操作符       ✨2.2.1,算术移位       ✨2.2.2,逻辑移位✍3，位操作符    🔍3.1,按位与&   

  4. kubernetes集群划分节点 - 2

    Kubernetes（K8s）是一个用于管理容器化应用程序的开源平台，可以帮助开发人员更轻松地部署、管理和扩展应用程序。在Kubernetes中，集群划分是一种重要的概念，可以帮助我们更好地组织和管理集群中的节点和资源。本文将介绍如何使用Kubernetes对集群进行划分，并提供详细的操作示例，希望能够帮助读者更好地了解和使用Kubernetes平台。Node划分Node划分是将集群中的节点按照一定的规则进行划分。在Kubernetes中，可以使用NodeSelector和Affinity机制来实现Node划分。NodeSelectorNodeSelector是一种将Pod调度到符合特定节点标

  5. 云原生（十八） | Kubernetes篇之Kubernetes（k8s）工作负载 - 2

    文章目录Kubernetes（k8s）工作负载一、Workloads二、Pod三、Deployment四、RC、RS、DaemonSet、StatefulSet五、Job、CronJob1、Job2、CronJob六、GCKubernetes（k8s）工作负载一、Workloads什么是工作负载（Workloads）工作负载是运行在Kubernetes上的一个应用程序。一个应用很复杂，可能由单个组件或者多个组件共同完成。无论怎样我们可以用一组Pod来表示一个应用，也就是一个工作负载Pod又是一组容器（Containers）所以关系又像是这样工作负载（Workloads）控制一组PodPod控制

  6. ruby-on-rails - Hartl 教程中的 bundle exec rspec spec/requests/static_pages_spec.rb 不起作用 - 2

    我正在按照MichaelHartl的ruby​​onrails教程测试示例应用程序(3.2.1测试驱动开发)，但在键入bundleexecrspecspec/requests/static_pages_spec.rb后出现以下错误/home/rahul/.rvm/gems/ruby-2.0.0-p247@railstutorial_rails_4_0/gems/selenium-webdriver-2.0.0/lib/selenium/webdriver/common/zipper.rb:1:in`require':cannotloadsuchfile--zip/zip(LoadErr

  7. 一文掌握软件项目成本预算、估算的方法和成本控制的秘籍 - 2

    每个企业都希望在完成项目后获得盈利，但不少企业到了年终后才发现项目做了不少，公司却并没能达到预期，甚至还出现了亏损。那么钱究竟去了哪里？很多公司都搞不清楚原因，出现糊涂账较多的状况，这将会造成严重的后果，尤其在疫情影响下，大环境很恶劣，如果是大公司的事业部门出现亏损，就可能会导致事业部门解散；如果是小公司出现亏损，就很容易导致公司倒闭；怎样做才能确保我们所完成的项目都能获利？从财务角度看，要确保盈利必须做到合理估算成本，只有这样才能在对外签订合约时做出合理报价，在对内在开始项目前做出充分评估投入代价，同时在实施过程中还要控制成本得当，最后项目结束时才会有可能获得盈利。那么我们怎样才能准确的判断

  8. idea连接远程k8s集群使用kubernetes-client - 2

    文章目录一.k8s集群修改config1.1备份当前k8s集群配置文件1.2删除当前k8s集群的apiserver的cert和key1.3生成新的apiserver的cert和key1.4刷新admin.conf1.5重启apiserver1.6刷新.kube/config二.安装kubectl2.1下载kubectl2.2配置kubectl三.使用kubernetes-client操作k8s集群3.1依赖3.2注意（可忽略）3.3创建StatefulSet3.4运行shell命令3.5删除StatefulSet3.6线上运行注意一.k8s集群修改config因为默认的是内网IP，复制出来后，

  9. 【云原生 • Kubernetes】kubernetes 核心技术 - Ingress - 2

    本文导读一、前言二、Ingress和pod有什么关系三、使用Ingress对外暴露应用1.创建应用并使用NodePort暴露端口2.应用Ingress(1)部署IngressController(2)创建Ingress规则(3)在Windows系统的hosts文件添加域名访问规则一、前言在以往的操作过程中，我们都是将某端口号对外暴露，然后再使用IP+端口号进行访问服务，这是通过Service中的NodePort实现的。但是NodePort有着明显的缺陷：NodePort会在每一个node节点都启用一个端口，也就是说在集群中的任何一个node节点中，使用节点IP+端口号都能访问到该服务；每个端口

  10. 一文详解COINDAO是什么？ - 2

    COINDAO旨在重建社区信任和安全。基于皖北基因的强烈共识，COINDAO自发产生了一个共创、共建、共治、共享的协作组织。它专注于DAO投资管理协议，为新的优质项目创造增长技术和资金。COINDAO的使命就是为真正的优质项目打造一个去中心化、公开透明的平台，让各个赛道上的优质项目能够以更低的成本快速募集资金并向公众开放.打破头部垄断。让真正的爱好者直接获得早期参与优质项目的资格，不再遥不可及，构建生态应用的可信体系，打造人人参与共建、人人共享的去中心化DAO好处。生态系统，我们称之为COINDAO生态系统。COINDAO国内各大财经网站宣发如下：COINDAO国外各大财经网站宣发： COIN

随机推荐