文档章节

图解kubernetes资源QOS机制实现原理

8小时
 8小时
发布于 02/19 20:48
字数 1442
阅读 700
收藏 1

3 月,跳不动了?>>>

QOS是k8s中一种资源保护机制,其主要是针对不可压缩资源比如的内存的一种控制技术,比如在内存中其通过为不同的Pod和容器构造OOM评分,并且通过内核的策略的辅助,从而实现当节点内存资源不足的时候,内核可以按照策略的优先级,优先kill掉哪些优先级比较低(分值越高优先级越低)的Pod,今天来分析下背后的实现

1.关键基础特性

image.png

1.1 一切皆文件

在Linux中一切皆文件,控制CGroup本身也是通过配置文件进行的,这是我创建的一个内存Lmits为200M的Pod的容器的配置

# pwd
/sys/fs/cgroup
# cat ./memory/kubepods/pod8e172a5c-57f5-493d-a93d-b0b64bca26df/f2fe67dc90cbfd57d873cd8a81a972213822f3f146ec4458adbe54d868cf410c/memory.limit_in_bytes
209715200

1.2 内核内存配置

这里我们重点关注内存相关的两个配置:VMOvercommitMemory其值为1,表示运行分配所有的物理内存资源,注意不包括SWAP资源VMPanicOnOOM其值为0:表示当内存不足的时候触发oom_killer进行选择部分进程进行kill,QOS也是通过影响其kill流程来实现的

func setupKernelTunables(option KernelTunableBehavior) error {
	desiredState := map[string]int{
		utilsysctl.VMOvercommitMemory: utilsysctl.VMOvercommitMemoryAlways,
		utilsysctl.VMPanicOnOOM:       utilsysctl.VMPanicOnOOMInvokeOOMKiller,
		utilsysctl.KernelPanic:        utilsysctl.KernelPanicRebootTimeout,
		utilsysctl.KernelPanicOnOops:  utilsysctl.KernelPanicOnOopsAlways,
		utilsysctl.RootMaxKeys:        utilsysctl.RootMaxKeysSetting,
		utilsysctl.RootMaxBytes:       utilsysctl.RootMaxBytesSetting,
	}

2.QOS打分机制与判定实现

QOS打分机制主要是根据Requests和limits里面的资源限制来进行类型判定与打分的,我们就来快速看下这部分的实现

2.1 根据容器判定QOS类型

2.1.1 构建容器列表

遍历所有的容器列表,注意这里会包含所有的初始化容器和业务容器

	requests := v1.ResourceList{}
	limits := v1.ResourceList{}
	zeroQuantity := resource.MustParse("0")
	isGuaranteed := true
	allContainers := []v1.Container{}
	allContainers = append(allContainers, pod.Spec.Containers...)
// 追加所有的初始化容器 
	allContainers = append(allContainers, pod.Spec.InitContainers...)

2.1.2 处理Requests和limits

这里遍历所有的Requests和Limits限制的资源,分别加入到不同的资源集合汇总,其中判定是不是Guaranteed主要是根据limits里面的资源是否包含CPU和内存两种资源,都包含才可能是Guaranteed

	for _, container := range allContainers {
		// process requests
		for name, quantity := range container.Resources.Requests {
			if !isSupportedQoSComputeResource(name) {
				continue
			}
			if quantity.Cmp(zeroQuantity) == 1 {
				delta := quantity.DeepCopy()
				if _, exists := requests[name]; !exists {
					requests[name] = delta
				} else {
					delta.Add(requests[name])
					requests[name] = delta
				}
			}
		}
		// process limits
		qosLimitsFound := sets.NewString()
		for name, quantity := range container.Resources.Limits {
			if !isSupportedQoSComputeResource(name) {
				continue
			}
			if quantity.Cmp(zeroQuantity) == 1 {
				qosLimitsFound.Insert(string(name))
				delta := quantity.DeepCopy()
				if _, exists := limits[name]; !exists {
					limits[name] = delta
				} else {
					delta.Add(limits[name])
					limits[name] = delta
				}
			}
		}

		if !qosLimitsFound.HasAll(string(v1.ResourceMemory), string(v1.ResourceCPU)) {
			// 必须是全部包含cpu和内存限制
			isGuaranteed = false
		}
	}

2.1.3 BestEffort

如果Pod里面的容器没有任何requests和limits的限制则就是BestEffort

	if len(requests) == 0 && len(limits) == 0 {
		return v1.PodQOSBestEffort
	}

2.1.4 Guaranteed

要是Guaranteed必须是资源相等,并且限定的数量相同

	// Check is requests match limits for all resources.
	if isGuaranteed {
		for name, req := range requests {
			if lim, exists := limits[name]; !exists || lim.Cmp(req) != 0 {
				isGuaranteed = false
				break
			}
		}
	}
	if isGuaranteed &&
		len(requests) == len(limits) {
		return v1.PodQOSGuaranteed
	}

2.1.5 Burstable

如果不是上面两种就是最后一种burstable了

	return v1.PodQOSBurstable

2.2 QOS OOM打分机制

2.2.1 OOM打分机制

其中guaranteedOOMScoreAdj是-998其实这跟OOM实现有关系,一台node节点上主要是三部分组成:kubelet主进程、docker进程、业务容器进程,而OOM的打分里面-1000表示该进程不会被oom所kill, 那一个业务进程最少也就只能是-999因为你不能保证自己的业务永远不会出现问题,所以在QOS里面-999其实就是kubelet和docker进程所保留的,剩下的才能作为业务容器分配(分值越高越容易被kill)

	// KubeletOOMScoreAdj is the OOM score adjustment for Kubelet
	KubeletOOMScoreAdj int = -999
	// DockerOOMScoreAdj is the OOM score adjustment for Docker
	DockerOOMScoreAdj int = -999
	// KubeProxyOOMScoreAdj is the OOM score adjustment for kube-proxy
	KubeProxyOOMScoreAdj  int = -999
	guaranteedOOMScoreAdj int = -998
	besteffortOOMScoreAdj int = 1000

2.2.2 关键Pod

关键Pod是一种特殊的存在,它可以是Burstable或者BestEffort类型的Pod,但是OOM打分却可以跟Guaranteed一样,这种类型的Pod主要包含三种:静态Pod、镜像Pod和高优先级Pod

	if types.IsCriticalPod(pod) {
		return guaranteedOOMScoreAdj
	}

判定实现

func IsCriticalPod(pod *v1.Pod) bool {
	if IsStaticPod(pod) {
		return true
	}
	if IsMirrorPod(pod) {
		return true
	}
	if pod.Spec.Priority != nil && IsCriticalPodBasedOnPriority(*pod.Spec.Priority) {
		return true
	}
	return false
}

2.2.3 Guaranteed与BestEffort

这两种类型都有各自默认的值分别为Guaranteed(-998)和BestEffort(1000)

	switch v1qos.GetPodQOS(pod) {
	case v1.PodQOSGuaranteed:
		// Guaranteed containers should be the last to get killed.
		return guaranteedOOMScoreAdj
	case v1.PodQOSBestEffort:
		return besteffortOOMScoreAdj
	}

2.2.4 Burstable

其中关键的一行就是:oomScoreAdjust := 1000 - (1000memoryRequest)/memoryCapacity,从这个计算里面可以看出,如果我们申请的资源越多,那么 (1000memoryRequest)/memoryCapacity这个里面计算出来的时机值就会越小,即最终结果就越大,其实也就表明如果我们占用的内存越少,则打分就越高,这类容器就相对比较容易被kill

	
	memoryRequest := container.Resources.Requests.Memory().Value()
	oomScoreAdjust := 1000 - (1000*memoryRequest)/memoryCapacity
	// A guaranteed pod using 100% of memory can have an OOM score of 10. 
Ensure that burstable pods have a higher OOM score adjustment.
	if int(oomScoreAdjust) < (1000 + guaranteedOOMScoreAdj) {
		return (1000 + guaranteedOOMScoreAdj)
	}
	// Give burstable pods a higher chance of survival over besteffort pods.
	if int(oomScoreAdjust) == besteffortOOMScoreAdj {
		return int(oomScoreAdjust - 1)
	}
	return int(oomScoreAdjust)

好了今天就到这里,看之前还很懵逼,看完有种豁然开朗的感觉,还是那句话说的对,源码面前了无秘密,加油

k8s源码阅读电子书地址: https://www.yuque.com/baxiaoshi/tyado3

> 微信号:baxiaoshi2020 > 关注公告号阅读更多源码分析文章 21天大棚 > 更多文章关注 www.sreguide.com > 本文由博客一文多发平台 OpenWrite 发布

© 著作权归作者所有

8小时
粉丝 12
博文 41
码字总数 85459
作品 0
私信 提问
加载中

评论(0)

深入解析 kubernetes 资源管理,容器云牛人有话说

资源,无论是计算资源、存储资源、网络资源,对于容器管理调度平台来说都是需要关注的一个核心问题。 • 如何对资源进行抽象、定义? • 如何确认实际可以使用的资源量? • 如何为容器分配它...

七牛云
2018/06/25
0
0
Kubernetes1.3:QoS服务质量管理

Kubernetes1.3:QoS服务质量管理 在kubernetes中,每个POD都有个QoS标记,通过这个Qos标记来对POD进行服务质量管理。QoS的英文全称为"Quality of Service",中文名为"服务质量",它取决于用户...

xiaomin0322
2018/04/18
32
0
容器开启数据服务之旅系列(三):Kubernetes QoS助力在线运用与大数据离线运用的混部

容器开启数据服务之旅系列(三) (三):Kubernetes QoS助力在线运用与大数据离线运用的混部 概述 本文是2018年大数据峰会上的一些分享,关于在线业务,离线业务在ACK(阿里云容器服务Kuber...

cu.eric.lee
2018/05/23
0
0
如何设置 Kubernetes 资源限制

Kubernetes 作为当下最流行的的容器集群管理平台,需要统筹集群整体的资源使用情况,将合适的资源分配给pod容器使用,既要保证充分利用资源,提高资源利用率,又要保证重要容器在运行周期内能...

萧元
2018/07/10
0
0
Kuberntes 服务质量保证(QoS)

Kubernetes做为目前主流的容器集群管理平台,需要整体统筹平台资源使用情况、公平合理的将资源分配给相关pod容器使用,并且要保证容器生命周期内有足够的资源来保证其运行。 与此同时,由于资...

店家小二
2018/12/14
0
0

没有更多内容

加载失败,请刷新页面

加载更多

F版本SpringCloud 4—Eureka注册中心开发和客户端开发

源码地址:https://gitee.com/bingqilinpeishenme/Java-Tutorials 前言 通过前三篇文章,用大白话介绍了微服务和SpringCloud以及服务治理相关的概念,从这篇开始SpringCloud代码的开发。 Sp...

鹿老师的Java笔记
22分钟前
26
0
解析CentOS 8上的Xrdp服务器安装

Xrdp 是 Microsoft 远程桌面协议 (RDP) 的开源实现,允许您以图形方式控制远程系统。使用 RDP ,您可以登录到远程计算机并创建真实的桌面会话,就像登录本地计算机一样。 本教程说明了如何在...

Linux就该这么学
24分钟前
17
0
用上触控板的 iPad Pro,是苹果对人机交互的一次妥协

  iPad 作为平板电脑诞生,至今已有十个年头。如果说让我们现在回到最初的起点,跟 2010 年的初代 iPad 用户说,你的平板在十年后会变成一台带实体键盘和触控板的电脑,可能会让很多人觉得...

水果黄瓜
25分钟前
20
0
Pandas pipe() apply() applymap()

要将自定义或其他库的函数应用于Pandas对象,有三个重要的方法,下面来讨论如何使用这些方法。使用适当的方法取决于函数是否期望在整个DataFrame,行或列或元素上进行操作。 表合理函数应用:...

沙门行道
33分钟前
14
0
application.properties提示Cannot resolve configuration property 'xxxx'

1 问题描述 在IDEA的Spring Boot工程中的application.properties文件中,如果自定义属性会如下提示: Cannot resolve configuration property 'xxxx' 2 解决方式一 这其实是一个警告,可以不用...

氷泠
34分钟前
15
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部