K8S中的资源管理

K8S中的资源管理是通过pod的reources-requests和reources-limits进行的。

首先K8S中的资源分为两类:

  • 可压缩资源。就是cpu这种,特点是当资源不足时,Pod 只会“饥饿”,但不会退出
  • 不可压缩资源,就是内存这种。当内存不足时,Pod 就会因为 OOM(Out-Of-Memory)被内核杀掉

requests & limits

    spec:
      containers:
      - name: hostnames
        image: mirrorgooglecontainers/serve_hostname
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
          limits:
            cpu: 100m
            memory: 100Mi

由于 Pod 可以由多个 Container 组成,所以 CPU 和内存资源的限额,是配置在每个Container 的定义上的。这样,Pod 整体的资源配置,就由这些 Container 的配置值累加得到

cpu:100m

指的就是 100 millicpu,也就是 0.1 个 CPU 的意思。这样,这个容器只就会被分配到 1 个 CPU 10%的计算能力

也可以写成 cpu:0.1。 但是推荐100m 的写法,毕竟这才是 Kubernetes 内部通用的 CPU 表示方式

Kubernetes 里为 CPU 设置的单位是“CPU 的个数”。比如,cpu=1 指的就是,这个 Pod 的 CPU 限额是 1 个 CPU。当然,具体“1 个 CPU”在宿主机上如何解释,是 1个 CPU 核心,还是 1 个 vCPU,还是 1 个 CPU 的超线程(Hyperthread),完全取决于宿主机的 CPU 实现方式。Kubernetes 只负责保证 Pod 能够使用到“1 个 CPU”的计算能力

memory: 100Mi

内存的单位这里用的是Mi

Mi和M的区别

1Mi=1024*1024;1M=1000*1000

requests & limits的区别

这两者的区别其实非常简单:

在调度的时候,kube-scheduler 是均价 requests 的值进行计算。

而在真正设置 Cgroup参数的时候 kubelet 则会按照 limits 的值来进行设置

也就是requests 是在调度时使用,limit是进行资源限制使用。

QoS级别

根据不同的 requests 和 limits 的设置方式,k8s会将这个 Pod 划分到不同的 QoS 级别当中

Guaranteed 类别 :

Pod 里的每一个 Container 都同时设置了 requests 和 limits,并且 requests 和limits 值相等的时候,k8s会将这个pod的qosClass 字段设置为Guaranteed。

比如上面的例子。


image-20221207142436863.png

需要注意的是,当 Pod 仅设置了 limits 没有设置 requests 的时候,Kubernetes 会自动为它设置与 limits 相同的 requests 值,所以,这也属于 Guaranteed

Burstable 类别

不满足 Guaranteed类别的条件,还设置了request参数。常见的情况就是request和limit不相等。

BestEffort类别

request和limit参数都没有任何配置,就是BestEffort

区分这三种级别有什么用处呢

当宿主机资源紧张的时候,kubelet 对 Pod 进行Eviction资源回收时需要用到的 。

具体地说,当 Kubernetes 所管理的宿主机上不可压缩资源短缺时,就有可能触发Eviction。比如,可用内存(memory.available)、可用的宿主机磁盘空间。

而当 Eviction 发生的时候,kubelet 具体会挑选哪些 Pod 进行删除操作,就需要参考这些Pod 的 QoS 类别了

首先干掉BestEffort级别的,然后是Burstable 类别 ,最后才是Guaranteed 类别。

绑核cpuset

可以通过设置 cpuset 把容器绑定到某个 CPU 的核上

这种情况下,由于操作系统在 CPU 之间进行上下文切换的次数大大减少,容器里应用的性能会得到大幅提升。

事实上,cpuset 方式,是生产环境里部署在线应用类型的 Pod 时,非常常用的一种方式

听起来很高级,在k8s做到却很简单。只需要两步

  1. Pod 的配置是 Guaranteed 的 QoS 类型
  2. CPU 资源的 requests 和 limits 设置为同一个相等的整数值

比如:

        resources:
          requests:
            cpu: 2
            memory: 100Mi
          limits:
            cpu: 2
            memory: 100Mi

这时候,该 Pod 就会被绑定在 2 个独占的 CPU 核上。当然,具体是哪两个 CPU 核,是由kubelet 为你分配的。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 230,578评论 6 544
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 99,701评论 3 429
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 178,691评论 0 383
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 63,974评论 1 318
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 72,694评论 6 413
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 56,026评论 1 329
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 44,015评论 3 450
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 43,193评论 0 290
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 49,719评论 1 336
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 41,442评论 3 360
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 43,668评论 1 374
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 39,151评论 5 365
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 44,846评论 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 35,255评论 0 28
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 36,592评论 1 295
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 52,394评论 3 400
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 48,635评论 2 380

推荐阅读更多精彩内容