做饮品的网站定制v下载安卓

做饮品的网站,定制v下载安卓,网站建设龙头股,wordpress 加统计代码一、Pod优先级优先级是什么#xff1f;优先级代表一个Pod相对其他Pod的重要性优先级有什么用优先级可以保证重要的Pod被调用运行如何使用优先级和抢占配置优先级类PriorityClass创建Pod是为其设置对应的优先级PriorityClassPriorityClass是一个全局资源对象#xff0c;它定义…一、Pod优先级优先级是什么优先级代表一个Pod相对其他Pod的重要性优先级有什么用优先级可以保证重要的Pod被调用运行如何使用优先级和抢占配置优先级类PriorityClass创建Pod是为其设置对应的优先级PriorityClassPriorityClass是一个全局资源对象它定义了从优先级类名称到优先级整数值的映射。优先级在values字段中指定可以设置小于10亿的整数值值越大优先级越高PriorityClass还有两个可选字段globalDefault用于设置默认优先级状态如果没有任何优先级设置Pod的优先级为零description用来配置描述性信息告诉用户优先级的用途优先级策略非抢占优先指的是在调度阶段优先进行调度分配一旦容器调度完成就不可以抢占资源不足时只能等待对应preemptionPolicy: Never抢占优先强制调度一个Pod如果资源不足无法被调度调度程序会抢占(删除)较低优先级的Pod的资源来保证高优先级Pod的运行对应preemptionPolicy: PreemptLowerPriority1、非抢占优先级# 定义优先级队列优先 [rootk8s-master ~]# vim mypriority.yaml --- kind: PriorityClass # 资源对象类型 apiVersion: scheduling.k8s.io/v1 # 资源对象版本 metadata: name: high-non # 优先级名称可在Pod中引用 globalDefault: false # 是否定义默认优先级唯一 preemptionPolicy: Never # 抢占策略 value: 1000 # 优先级 description: non-preemptive # 描述信息 ​ --- kind: PriorityClass apiVersion: scheduling.k8s.io/v1 metadata: name: low-non globalDefault: false preemptionPolicy: Never value: 500 description: non-preemptive ​ [rootk8s-master ~]# kubectl apply -f mypriority.yaml priorityclass.scheduling.k8s.io/high-non created priorityclass.scheduling.k8s.io/low-non created [rootk8s-master ~]# kubectl get priorityclasses.scheduling.k8s.io NAME VALUE GLOBAL-DEFAULT AGE high-non 1000 false 12s low-non 500 false 12s system-cluster-critical 2000000000 false 45h system-node-critical 2000001000 false 45hPod资源文件# 无优先级的 Pod [rootk8s-master ~]# cat nginx1.yaml --- kind: Pod apiVersion: v1 metadata: name: nginx1 spec: nodeName: k8s-node2 containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent resources: requests: cpu: 1500m ​ # 低优先级 Pod [rootk8s-master ~]# cat nginx2.yaml --- kind: Pod apiVersion: v1 metadata: name: nginx2 spec: nodeName: k8s-node2 priorityClassName: low-non # 指定优先级的名称 containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent resources: requests: cpu: 1500m ​ # 高优先级 Pod [rootk8s-master ~]# cat nginx3.yaml --- kind: Pod apiVersion: v1 metadata: name: nginx3 spec: nodeName: k8s-node2 priorityClassName: high-non # 指定优先级的名称 containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent resources: requests: cpu: 1500m2、验证非抢占优先[rootmaster ~]# kubectl apply -f nginx1.yaml pod/nginx1 created [rootmaster ~]# kubectl apply -f nginx2.yaml pod/nginx2 created [rootmaster ~]# kubectl apply -f nginx3.yaml pod/nginx3 created [rootmaster ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx1 1/1 Running 0 9s nginx2 0/1 Pending 0 6s nginx3 0/1 Pending 0 4s [rootmaster ~]# kubectl delete pod nginx1 pod nginx1 deleted [rootmaster ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx2 0/1 Pending 0 20s nginx3 1/1 Running 0 18s ​ # 清理实验 Pod [rootmaster ~]# kubectl delete pod nginx2 nginx3 pod nginx2 deleted pod nginx3 deleted3、抢占策略(有问题)K8S在发生调度失败后会基于优先级进行抢占抢占并不是简单的将Node上的低优先级的pod”挤走“抢占的设计还是相对比较有意思的。K8S内部在调度过程中会维护2个队列分别是activeQ和unschedulableQ。activeQ当K8S里新创建一个Pod的时候,调度器会将这个Pod入队到activeQ里面然后调度器从这个队列里取出一个pod进行调度。unschedulableQ专门用来存放调度失败的pod,当一个unschedulableQ里的Pod被更新之后,调度器会自动把这个Pod移动到activeQ里。3.1、抢占的基本流程:正常调度的pod会先放入activeQ, activeQ会经过正常的调度策略进行调度。调度失败后将这个pod放入unreachableQ里随后出发寻找牺牲者流程。在寻找牺牲者之前先对失败原因检查下看下是不是因为一些无法恢复的原因导致失败的比如node-selector失败之类的。确认可以触发抢占后scheduler 会拉取所有node的缓存信息进行一次模拟抢占流程基于影响集群稳定性最小原则选出了哪些node上的哪些pod可以成为”牺牲者”。对于选出的牺牲者podschedueler 会先清楚他们pod里的nominatedNodeName字段。然后更新抢占者pod将nominatedNodeName改成第4步选出的node名字。由于抢占者pod已发生了更新所以给他“重新做人”的机会重新放入activeQ里。同时开启一个新的协程清理牺牲者node上对应的牺牲者pod。3.2、抢占的异常流程抢占者和牺牲者其实是相对的或者说优先级是相对的抢占者在第一次流程后一般会创建在之前模拟出来的那个牺牲者node上但是假设同样队列里有另外一个pod也正好要调度在那个node上K8S会对这种情况做一些特殊处理即对该node进行2次预选操作。第一次预选假设抢占者已经在对应node上了以这个前提进行一次预选算法。第二次预选假设抢占者不在对应node上以这个前提进行一次预选算法。只有这两次预选都通过了调度器才认为这个node和pod可以绑定再进入后续的优选算法。第二预选比较奇怪为什么需要假设抢占者不在node上呢这是因为删除牺牲者操作实际是调用了标准的DELETE API进行操作的这是一个优雅关闭的操作,所以存在默认30S的退出时间而30S内可能会有很多变故比如再重新调度的时候Node服务器挂了或者有更加高优先级的pod需要抢占这个node这些都导致了重新调度的失败所以说抢占者不一定会调度到对应的node上。另外还有一种情况假设整个K8S集群有了一个比较大的变化比如新扩容了node节点等scheduler会执行MoveAllToActiveQueue的操作,把所调度失败的Pod从unscheduelableQ移动到activeQ里面。另外由于亲和性的存在当一个已经调度成功的Pod被更新时,调度器则会将unschedulableQ里所有跟这个Pod有 Affinity/Anti-affinity关系的Pod,移动到 activeQ 里面开始调度。[rootmaster ~]# vim mypriority.yaml --- kind: PriorityClass apiVersion: scheduling.k8s.io/v1 metadata: name: high globalDefault: false preemptionPolicy: PreemptLowerPriority value: 1000 description: non-preemptive ​ --- kind: PriorityClass apiVersion: scheduling.k8s.io/v1 metadata: name: low globalDefault: false preemptionPolicy: PreemptLowerPriority value: 500 description: non-preemptive ​ [rootmaster ~]# kubectl apply -f mypriority.yaml priorityclass.scheduling.k8s.io/high created priorityclass.scheduling.k8s.io/low created [rootmaster ~]# kubectl get priorityclasses.scheduling.k8s.io NAME VALUE GLOBAL-DEFAULT AGE high 1000 false 12s low 500 false 12s system-cluster-critical 2000000000 false 45h system-node-critical 2000001000 false 45h4、验证抢占优先级# 默认优先级 Pod [rootmaster ~]# kubectl apply -f nginx1.yaml pod/nginx1 created [rootmaster ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx1 1/1 Running 0 6s ​ # 高优先级 Pod [rootmaster ~]# sed s,-non,, nginx3.yaml |kubectl apply -f- pod/nginx3 created [rootmaster ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx3 1/1 Running 0 9s ​ # 低优先级 Pod [rootmaster ~]# sed s,-non,, nginx2.yaml |kubectl apply -f- pod/nginx2 created [rootmaster ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx2 0/1 Pending 0 3s nginx3 1/1 Running 0 9s ​ # 清理实验 Pod [rootmaster ~]# kubectl delete pod nginx2 nginx3 pod nginx2 deleted pod nginx3 deleted [rootmaster ~]# kubectl delete -f mypriority.yaml priorityclass.scheduling.k8s.io high-non deleted priorityclass.scheduling.k8s.io low-non deleted priorityclass.scheduling.k8s.io high deleted priorityclass.scheduling.k8s.io low deleted二、节点优先级在 Kubernetes 中节点优先级Node Priority是用于指定节点的调度权重的设置。节点优先级主要用于调度器在选择节点时进行权衡和做出选择。1、优先级类型1.1、静态优先级Static Priority可以手动为每个节点设置一个固定的优先级值。在节点对象的注解Annotations中使用scheduler.alpha.kubernetes.io/priority注解来定义节点的优先级。较高的优先级值表示节点的优先级较高。1.2、亲和性优先级Affinity Priority可以通过节点的亲和性Affinity设置来隐式地设置节点的优先级。优先级是根据亲和性规则和节点的亲和性权重weight来计算的。1.3、服务质量优先级Quality of Service Priority可以通过指定 Pod 的服务质量等级Quality of Service Class来设置节点的优先级。服务质量等级包括 Guaranteed、Burstable、BestEffort。较高的服务质量等级对应较高的优先级。1.3.1、QoS服务质量Requests 和 limits 的配置除了表明资源情况和限制资源使用之外还有一个隐藏的作用它决定了 pod 的 QoS 等级。如果 pod 没有配置 limits 那么它可以使用节点上任意多的可用资源。这类 pod 能灵活使用资源但这也导致它不稳定且危险对于这类 pod 我们一定要在它占用过多资源导致节点资源紧张时处理掉。优先处理这类 pod而不是资源使用处于自己请求范围内的 pod 是非常合理的想法而这就是 pod QoS 的含义根据 pod 的资源请求把 pod 分成不同的重要性等级。kubernetes 把 pod 分成了三个 QoS 等级Guaranteed优先级最高可以考虑数据库应用或者一些重要的业务应用。除非 pods 使用超过了它们的 limits或者节点的内存压力很大而且没有 QoS 更低的 pod否则不会被杀死Burstable这种类型的 pod 可以多于自己请求的资源上限有 limit 指定如果 limit没有配置则可以使用主机的任意可用资源但是重要性认为比较低可以是一般性的应用或者批处理任务Best Effort优先级最低集群不知道 pod的资源请求情况调度不考虑资源可以运行到任意节点上从资源角度来说可以是一些临时性的不重要应用。pod可以使用节点上任何可用资源但在资源不足时也会被优先杀死1.3.2、根据QoS进行资源回收策略Kubernetes 通过cgroup给pod设置QoS级别当资源不足时先kill优先级低的 pod在实际使用过程中通过OOM分数值来实现OOM分数值范围为0-1000。OOM 分数值根据OOM_ADJ参数计算得出。对于Guaranteed级别的 PodOOM_ADJ参数设置成了-998对于Best-Effort级别的 PodOOM_ADJ参数设置成了1000对于Burstable级别的 PodOOM_ADJ参数取值从2到999。对于 kuberntes 保留资源比如kubeletdockerOOM_ADJ参数设置成了-999表示不会被OOM kill掉。OOM_ADJ参数设置的越大计算出来的OOM分数越高表明该pod优先级就越低当出现资源竞争时会越早被kill掉对于OOM_ADJ参数是-999的表示kubernetes永远不会因为OOM将其kill掉。1.3.3、QoS pods被kill掉场景与顺序Best-Effort pods系统用完了全部内存时该类型 pods 会最先被kill掉。Burstable pods系统用完了全部内存且没有 Best-Effort 类型的容器可以被 kill 时该类型的 pods 会被kill 掉。Guaranteed pods系统用完了全部内存且没有 Burstable 与 Best-Effort 类型的容器可以被 kill时该类型的 pods 会被 kill 掉。1.4、插件优先级Plugin Priority可以编写插件来扩展调度器的功能并为节点设置一些额外的优先级规则。调度器在进行节点选择时会根据节点的优先级进行权衡优先选择具有较高优先级的节点。如果存在多个节点具有相同的优先级则会根据其它因素例如节点资源、亲和性规则等进一步进行选择。2、实战案例2.1、静态优先级案例场景描述假设有一个混合了新旧硬件的Kubernetes集群。新硬件性能更优希望调度器优先将资源密集型的应用部署到新硬件节点上。设置步骤与示例首先给新硬件节点设置较高的静态优先级。假设集群中有三个节点node-new-1和node-new-2是新硬件节点node-old是旧硬件节点。通过以下命令假设可以直接修改节点注解为新硬件节点设置优先级kubectl annotate node node-new-1 scheduler.alpha.kubernetes.io/priority100 ​ kubectl annotate node node-new-2 scheduler.alpha.kubernetes.io/priority100 ​ kubectl annotate node node-old scheduler.alpha.kubernetes.io/priority50现在有一个大数据处理的Pod需要大量的CPU和内存资源。当调度器调度这个Pod时会首先考虑node-new-1和node-new-2这两个优先级为100的节点因为它们的优先级高于node-old优先级为50。只有当新硬件节点资源不足或者不符合其他调度规则如亲和性规则时调度器才会考虑node-old。删除注解kubectl annotate node node-old scheduler.alpha.kubernetes.io/priority-2.2、亲和性优先级案例场景描述考虑一个具有多个区域zone的多节点集群应用需要根据区域亲和性进行部署并且希望在满足区域亲和性的基础上根据某种权重来优先选择节点。例如有一个应用它的数据存储在特定区域的存储服务中为了减少网络延迟希望将应用的Pod优先调度到靠近存储服务的区域的节点上并且在这个区域内有些节点与存储服务的网络连接质量更好希望给这些节点更高的优先级。设置步骤与示例首先为节点添加区域标签。假设存储服务在zone-a区域节点node-1、node-2在zone-a节点node-3在zone-b。bashkubectl label node node-1 zonezone-a ​ kubectl label node node-2 zonezone-a ​ kubectl label node node-3 zonezone-b然后在Pod的配置文件中设置节点亲和性和权重。假设node-1与存储服务的网络连接质量更好希望给它更高的优先级。apiVersion: v1 kind: Pod metadata: name: data-app-pod spec: containers: - name: data-app-container image: data-app-image affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: - zone-a preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 preference: matchExpressions: - key: node-name operator: In values: - node-1 - weight: 40 preference: matchExpressions: - key: node-name operator: In values: - node-2当调度data-app-pod时调度器首先会过滤出zone-a的节点node-1和node-2因为有硬亲和性要求。然后根据亲和性优先级的权重计算node-1因为权重为80会比node-2权重为40更有可能被选中。2.3、服务质量优先级案例场景描述有一个在线交易系统包括一个保证服务质量Guaranteed的核心交易处理服务一个可突发Burstable的订单查询服务以及一个尽力而为BestEffort的日志收集服务。希望核心交易处理服务的Pod能够优先调度到资源充足且稳定的节点上。设置步骤与示例对于核心交易处理服务的Pod在配置文件中设置服务质量等级为Guaranteedlimit与request的资源设置一致。apiVersion: v1 kind: Pod metadata: name: trade-processing-pod spec: containers: - name: trade-container image: trade-processing-image resources: requests: cpu: 1 memory: 1Gi limits: cpu: 1 memory: 1Gi ### qosClass: Guaranteed对于订单查询服务的Pod设置为Burstablelimit的资源设置小于request的资源设置apiVersion: v1 kind: Pod metadata: name: order-query-pod spec: containers: - name: order-container image: order-query-image resources: requests: cpu: 0.5 memory: 512Mi limits: cpu: 1 memory: 1Gi ### qosClass: Burstable对于日志收集服务的Pod设置为BestEffort不进行资源限制apiVersion: v1 kind: Pod metadata: name: log-collection-pod spec: containers: - name: log-container image: log-collection-image ### qosClass: BestEffort调度器在调度这些Pod时会优先考虑将trade-processing-podGuaranteed调度到资源充足且稳定的节点。因为它的服务质量等级最高其次是order-query-podBurstable最后是log-collection-podBestEffort。2.4、插件优先级案例场景描述假设在一个企业级的Kubernetes集群中安全团队要求对于运行敏感数据处理应用的Pod必须优先调度到经过特定安全加固的节点上。这些节点有额外的安全防护软件和硬件模块并且希望通过插件来实现这种特殊的优先级设置。设置步骤与示例首先开发一个自定义的调度插件。这个插件可以检查节点是否具有“security-hardened”标签表示经过安全加固的节点并为这些节点设置较高的优先级。安装和配置插件后给经过安全加固的节点添加标签kubectl label node node-sec-1 security-hardenedtrue kubectl label node node-sec-2 security-hardenedtrue对于敏感数据处理应用的Pod正常创建配置文件。当调度器运行时由于插件的作用会优先将这些Pod调度到带有“security-hardened”标签的节点node-sec-1和node-sec-2上因为插件为这些节点设置了更高的优先级。具体的插件实现可能涉及到Go语言编程并且需要遵循Kubernetes调度器插件的开发规范来与调度器集成。