Loading [MathJax]/jax/input/TeX/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >深入分析Kubernetes Critical Pod(一)

深入分析Kubernetes Critical Pod(一)

作者头像
Walton
发布于 2019-03-12 09:18:55
发布于 2019-03-12 09:18:55
1.7K00
代码可运行
举报
文章被收录于专栏:KubernetesKubernetes
运行总次数:0
代码可运行

大家在Kubernetes集群中部署核心组件时,经常会用到Critical Pod,那么你知道Critical Pod到底有何特别吗?要完整的了解这一点,其实并不是那么简单,它关系到调度、Kubelet Eviction Manager、DaemonSet Controller、Kubelet Preemption等,我将分4个系列为大家剖析。这一篇先介绍Critical Pod在Predicate in Schedule阶段的行为,以及用户期望的行为等。

官方宣布Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.12,所以本文将不讨论Rescheduler对Critical Pod的处理逻辑。

有什么方法标识一个Pod为Critical Pod

规则1:

  • Enable Feature Gate ExperimentalCriticaPodAnnotation
  • 必须隶属于kube-system namespace;
  • 必须加上Annotation scheduler.alpha.kubernetes.io/critical-pod=""

规则2:

  • Enable Feature Gate ExperimentalCriticaPodAnnotation, PodPriority
  • Pod的Priority不为空,且不小于2 * 10^9; system-node-critical priority = 10^9 + 1000; system-cluster-critical priority = 10^9;

满足规则1或规则2之一,就认为该Pod为Critical Pod;

Schedule Critical Pod

在default scheduler进行pod调度的predicate阶段,会注册GeneralPredicates为default predicates之一,并没有判断critical Pod使用EssentialPredicates来对critical Pod进行predicate process。这意味着什么呢?

我们看看GeneralPredicates和EssentialPredicates的关系就知道了。GeneralPredicates中,先调用noncriticalPredicates,再调用EssentialPredicates。因此如果你给Deployment/StatefulSet等(DeamonSet除外)标识为Critical,那么在scheduler调度时,仍然走GeneralPredicates的流程,会调用noncriticalPredicates,而你却希望它直接走EssentialPredicates。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
// GeneralPredicates checks whether noncriticalPredicates and EssentialPredicates pass. noncriticalPredicates are the predicates
// that only non-critical pods need and EssentialPredicates are the predicates that all pods, including critical pods, need
func GeneralPredicates(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) {
	var predicateFails []algorithm.PredicateFailureReason
	fit, reasons, err := noncriticalPredicates(pod, meta, nodeInfo)
	if err != nil {
		return false, predicateFails, err
	}
	if !fit {
		predicateFails = append(predicateFails, reasons...)
	}

	fit, reasons, err = EssentialPredicates(pod, meta, nodeInfo)
	if err != nil {
		return false, predicateFails, err
	}
	if !fit {
		predicateFails = append(predicateFails, reasons...)
	}

	return len(predicateFails) == 0, predicateFails, nil
}

noncriticalPredicates原意是想对non-critical pod做的额外predicate逻辑,这个逻辑就是PodFitsResources检查。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
pkg/scheduler/algorithm/predicates/predicates.go:1076

// noncriticalPredicates are the predicates that only non-critical pods need
func noncriticalPredicates(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) {
	var predicateFails []algorithm.PredicateFailureReason
	fit, reasons, err := PodFitsResources(pod, meta, nodeInfo)
	if err != nil {
		return false, predicateFails, err
	}
	if !fit {
		predicateFails = append(predicateFails, reasons...)
	}

	return len(predicateFails) == 0, predicateFails, nil
}

PodFitsResources就做以下检查资源是否满足要求:

  • Allowed Pod Number;
  • CPU;
  • Memory;
  • EphemeralStorage;
  • Extended Resources;

也就是说,如果你给Deployment/StatefulSet等(DeamonSet除外)标识为Critical,那么对应的Pod调度时仍然会检查Allowed Pod Number, CPU, Memory, EphemeralStorage,Extended Resources是否足够,如果不满足则会触发预选失败,并且在Preempt阶段也只是根据对应的PriorityClass进行正常的抢占逻辑,并没有针对Critical Pod进行特殊处理,因此最终可能会因为找不到满足资源要求的Node,导致该Critical Pod调度失败,一直处于Pending状态。

而用户设置Critical Pod是不想因为资源不足导致调度失败的。那如果我就是想使用Deployment/StatefulSet等(DeamonSet除外)标识为Critical Pod来部署关键服务呢?有以下两个办法:

  1. 按照前面提到的规则2,给Pod设置system-cluster-criticalsystem-node-critical Priority Class,这样就会在scheduler正常的Preempt流程中抢占到资源完成调度。
  2. 按照前面提到的规则1,并且修改GeneralPredicates的代码如下,检测是否为Critical Pod,如果是,则不执行noncriticalPredicates逻辑,也就是说predicate阶段不对Allowed Pod Number, CPU, Memory, EphemeralStorage,Extended Resources资源进行检查。
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
func GeneralPredicates(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) {
	var predicateFails, resons []algorithm.PredicateFailureReason
	var fit bool
	var err error
	
	// **Modify**: check whether the pod is a Critical Pod, don't invoke noncriticalPredicates if false.
	isCriticalPod := utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalCriticalPodAnnotation) &&
		kubelettypes.IsCriticalPod(newPod)
	
	if !isCriticalPod {
	   fit, reasons, err = noncriticalPredicates(pod, meta, nodeInfo)
    	if err != nil {
    		return false, predicateFails, err
    	}
	}
	
	if !fit {
		predicateFails = append(predicateFails, reasons...)
	}

	fit, reasons, err = EssentialPredicates(pod, meta, nodeInfo)
	if err != nil {
		return false, predicateFails, err
	}
	if !fit {
		predicateFails = append(predicateFails, reasons...)
	}

	return len(predicateFails) == 0, predicateFails, nil
}

方法1,其实Kubernetes在Admission Priority检查时已经帮你做了。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
// admitPod makes sure a new pod does not set spec.Priority field. It also makes sure that the PriorityClassName exists if it is provided and resolves the pod priority from the PriorityClassName.
func (p *priorityPlugin) admitPod(a admission.Attributes) error {
	...
	if utilfeature.DefaultFeatureGate.Enabled(features.PodPriority) {
		var priority int32
		if len(pod.Spec.PriorityClassName) == 0 &&
			utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalCriticalPodAnnotation) &&
			kubelettypes.IsCritical(a.GetNamespace(), pod.Annotations) {
			pod.Spec.PriorityClassName = scheduling.SystemClusterCritical
		}
            ...
}

在Admission时候会对Pod的Priority进行检查,如果发现您已经:

  • Enable PriorityClass Feature Gate;
  • Enable ExperimentalCriticalPodAnnotation Feature Gate;
  • 给Pod添加了ExperimentalCriticalPodAnnotation;
  • 部署在kube-system namespace;
  • 没有手动设置自定义PriorityClass;

那么,Admisson Priority阶段会自动给Pod添加SystemClusterCritical(system-cluster-critical) PriorityClass;

最佳实践

通过上面的分析,给出如下最佳实践:在Kubernetes集群中,通过非DeamonSet方式(比如Deployment、RS等)部署关键服务时,为了在集群资源不足时仍能保证抢占调度成功,请确保如下事宜:

  • Enable PriorityClass Feature Gate;
  • Enable ExperimentalCriticalPodAnnotation Feature Gate;
  • 给Pod添加了ExperimentalCriticalPodAnnotation;
  • 部署在kube-system namespace;
  • 千万不要手动设置自定义PriorityClass;

总结

本文介绍了标识一个关键服务为Critical服务的两种方法,并介绍了Critical Pod(DaemonSet部署方式除外)在Predicate in Schedule阶段的行为,给出了最佳实践。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018/07/12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
深入分析Kubernetes Critical Pod(四)
摘要:本文分析了DeamonSetController及PriorityClass Validate时,对CriticalPod的所做的特殊处理。
Walton
2019/03/12
6600
深入分析Kubernetes Critical Pod(三)
本文介绍了Kubelet在Predicate Admit准入检查时对CriticalPod的资源抢占的原理,以及Priority Admission Controller对CriticalPod的PriorityClassName特殊处理。
Walton
2019/03/12
2.1K0
原 荐 深入分析Kubernetes Sch
Author: xidianwangtao@gmail.com 在Kubernetes 1.8抢占式调度Preemption源码分析中,有好几处我们提到了NominatedPods,当时没有给出足够的分析,今天我们就重点分析一下NominatedPods的意义和原理。 NominatedPods是什么? 当enable PodPriority feature gate后,scheduler会在集群资源资源不足时为preemptor抢占低优先级的Pods(成为victims)的资源,然后preempto
Walton
2018/06/13
1.2K0
Kubernetes Scheduler源码分析
本文是对Kubernetes 1.5的Scheduler源码层面的剖析,包括对应的源码目录结构分析、kube-scheduler运行机制分析、整体代码流程图、核心代码走读分析等内容。阅读本文前,请先了解kubernetes scheduler原理解析。 Kubernetes源码目录结构分析 Kubernetes Scheduler是作为kubernetes的一个plugin来设计的,这种可插拔的设计极大方便用户自定义调度算法,在不同的公司,通常大家对调度的需求是不同的,自定义调度是很常见的。 Schedul
Walton
2018/04/13
1.8K0
Kubernetes Scheduler源码分析
深入分析Kubernetes DaemonSet Controller
NewDaemonSetsController负责创建Controller,其中很重要的工作就是注册以下Informer的EventHandler:
Walton
2019/03/12
1.9K0
深入分析Kubernetes DaemonSet Controller
如何对kubernetes scheduler进行二次开发
通过新增Predicates&Priorities Policies来扩展default scheduler 新增Predicate Policy predicate Interface plugin/pkg/scheduler/algorithm/types.go:31 // FitPredicate is a function that indicates if a pod fits into an existing node. // The failure information is given
Walton
2018/04/16
2.1K0
k8s源码-揭开scheduler的算法面纱(上)
预选和优选算法都在 pkg/scheduler/algorithm包下,在该包同级的包algorithmprovider注册默认算法(其实是将算法名字和function对应起来)的策略,调用的工厂类algorithm_factory进行注册。
ascehuang
2019/12/07
1.8K0
k8s源码-揭开scheduler的算法面纱(上)
剖析Kubernetes EnableEquivalenceClassCache提升Scheduler吞吐量的工作机制
2015年,google发表的关于Borg的论文“Large-scale cluster management at Google with Borg”中对Equivalence Class的描述如下:
Walton
2018/05/17
1.7K0
剖析Kubernetes EnableEquivalenceClassCache提升Scheduler吞吐量的工作机制
深度解析Kubernetes Local Persistent Volume(二)
摘要:上一篇博客”深度解析Kubernetes Local Persistent Volume(一)“对local volume的基本原理和注意事项进行了分析,本文将进行源码分析,涉及scheduler、pv controller相关的代码,希望能剖析local volume的delay scheduleing、pv node affinity的内部机制。
Walton
2018/09/13
5.1K0
深度解析Kubernetes Local Persistent Volume(二)
一篇读懂Kubernetes Scheduler扩展功能
作者杜杨浩,腾讯云高级工程师,热衷于开源、容器和Kubernetes。目前主要从事镜像仓库以及云原生架构相关研发工作。 前言 Scheduler是Kubernetes组件中功能&逻辑相对单一&简单的模块,它主要的作用是:watch kube-apiserver,监听PodSpec.NodeName为空的pod,并利用预选和优选算法为该pod选择一个最佳的调度节点,最终将pod与该节点进行绑定,使pod调度在该节点上运行。 展开上述调用流程中的scheduler部分,内部细节调用(参考Kubernet
腾讯云原生
2020/11/02
3.2K0
深入分析Kubernetes Critical Pod(二)
深入分析Kubernetes Critical Pod(一)介绍了Scheduler对Critical Pod的处理逻辑,下面我们再看下Kubelet Eviction Manager对Critical Pod的处理逻辑是怎样的,以便我们了解Kubelet Evict Pod时对Critical Pod是否有保护措施,如果有,又是如何保护的。
Walton
2019/03/12
1.5K0
Kubernetes Scheduler的Predicates和Priorities Policies解读
本文是对Kubernetes V1.5 Scheduler 的预选策略Predicates Policies和优选策略Priorities Policies的含义解读,并附有部分样例代码代码解析。关于kubernetes调度器更全面的解析见我的其他博客:Kubernetes Scheduler源码分析, Kubernetes Scheduler原理解析 ##Predicates Policies分析 在/plugin/pkg/scheduler/algorithm/predicates.go中实现了以下的预
Walton
2018/04/13
1.2K0
kube-scheduler predicates 与 priorities 调度算法源码分析
在上篇文章kube-scheduler 源码分析中已经介绍了 kube-scheduler 的设计以及从源码角度分析了其执行流程,这篇文章会专注介绍调度过程中 predicates 和 priorities 这两个调度策略主要发生作用的阶段。
田飞雨
2019/12/15
1.3K0
kubescheduler源码解析
我嫌弃官方提供的编译脚本太麻烦,所以用了更简单粗暴的方式编译k8s代码,当然官方脚本在编译所有项目或者夸平台编译以及realse时还是挺有用的。
sealyun
2019/07/25
1.4K0
Kubernetes 1.8抢占式调
Author: xidianwangtao@gmail.com 阅读本博文前,建议先阅读解析Kubernetes 1.8中的基于Pod优先级的抢占式调度。 ScheduleAlgorithm的变化 在Kubernetes 1.8中,对ScheduleAlgorithm Interface的定义发生了改变,多了一个Preempt(...)。因此,我在博文Kubernetes Scheduler原理解析(当时是基于kubernetes 1.5)中对scheduler调度过程开的一句话概括“将PodS
Walton
2018/04/16
1.3K0
critical pod浅谈
除了在主机上运行的Kubernetes核心组件(如api-server, scheduler, controller-manager )外,还有许多附加组件,由于各种原因,这些附加组件必须在常规群集节点(而不是Kubernetes master)上运行。其中一些附加组件对于功能齐全的群集至关重要,例如metrics-server,DNS和UI。如果紧急附加组件被驱逐(手动或作为其他操作(如升级)的副作用)并变为挂起状态(例如,当该群集被高度利用且有其他挂起的Pod计划进入该群集时,该群集可能会停止正常工作)被驱逐的关键附加组件腾出的空间或节点上可用的资源量由于其他原因而发生了变化)。
有点技术
2020/07/14
8290
原 深入分析Kubernetes Sche
PriorityQueue PriorityQueue Struct 先看看PriorityQueue的结构定义。 type PriorityQueue struct { lock sync.RWM
Walton
2018/06/20
9270
深入分析Kubernetes Scheduler的优先级队列
从1.9版本开始,Kubernetes实现了基于Pod优先级的调度队列,一方面提供高优先级的Pod优先被调度的能力,另一方面减轻抢占式调度时潜在的High Priority Pod Starvation的问题,截止Kubernetes 1.10,PriorityPod Feature Gate仍处于Alpha。本文将从源码的层面对PriorityQueue进行深入分析,了解内部的两个Sub-Queue以及在什么情况下操作这两个Sub-Queue的,又是如何操作的,另外也提醒当前实现还可能存在的问题。
Walton
2018/05/13
3.3K2
深入分析Kubernetes Scheduler的优先级队列
kube-scheduler 优先级与抢占机制源码分析
前面已经分析了 kube-scheduler 的代码逻辑以及 predicates 与 priorities 算法,本节会继续讲 scheduler 中的一个重要机制,pod 优先级与抢占机制(Pod Priority and Preemption),该功能是在 v1.8 中引入的,v1.11 中该功能为 beta 版本且默认启用了,v1.14 为 stable 版本。
田飞雨
2019/12/15
7860
Golang程序性能分析(一)pprof和go-torch
最近计划用三篇文章讲述一下Golang应用性能分析,本文是第一篇,先来介绍Go语言自带的性能分析库pprof怎么使用,后面两篇会讲解怎么用pprof对Echo或者Gin框架开发的应用进行性能分析以及如何使用pprof对gRPC 服务进行性能分析。
KevinYan
2020/11/26
1.2K1
相关推荐
深入分析Kubernetes Critical Pod(四)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验