您好,登錄后才能下訂單哦!
這篇文章主要介紹“Daemonset Controller對Critical Pod的特殊處理是什么”,在日常操作中,相信很多人在Daemonset Controller對Critical Pod的特殊處理是什么問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Daemonset Controller對Critical Pod的特殊處理是什么”的疑惑有所幫助!接下來,請跟著小編一起來學習吧!
在DaemonSetController判斷某個node上是否要運行某個DaemonSet時,會調(diào)用DaemonSetsController.simulate來分析PredicateFailureReason。
pkg/controller/daemon/daemon_controller.go:1206 func (dsc *DaemonSetsController) simulate(newPod *v1.Pod, node *v1.Node, ds *apps.DaemonSet) ([]algorithm.PredicateFailureReason, *schedulercache.NodeInfo, error) { // DaemonSet pods shouldn't be deleted by NodeController in case of node problems. // Add infinite toleration for taint notReady:NoExecute here // to survive taint-based eviction enforced by NodeController // when node turns not ready. v1helper.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key: algorithm.TaintNodeNotReady, Operator: v1.TolerationOpExists, Effect: v1.TaintEffectNoExecute, }) // DaemonSet pods shouldn't be deleted by NodeController in case of node problems. // Add infinite toleration for taint unreachable:NoExecute here // to survive taint-based eviction enforced by NodeController // when node turns unreachable. v1helper.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key: algorithm.TaintNodeUnreachable, Operator: v1.TolerationOpExists, Effect: v1.TaintEffectNoExecute, }) // According to TaintNodesByCondition, all DaemonSet pods should tolerate // MemoryPressure and DisPressure taints, and the critical pods should tolerate // OutOfDisk taint additional. v1helper.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key: algorithm.TaintNodeDiskPressure, Operator: v1.TolerationOpExists, Effect: v1.TaintEffectNoSchedule, }) v1helper.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key: algorithm.TaintNodeMemoryPressure, Operator: v1.TolerationOpExists, Effect: v1.TaintEffectNoSchedule, }) // TODO(#48843) OutOfDisk taints will be removed in 1.10 if utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalCriticalPodAnnotation) && kubelettypes.IsCriticalPod(newPod) { v1helper.AddOrUpdateTolerationInPod(newPod, &v1.Toleration{ Key: algorithm.TaintNodeOutOfDisk, Operator: v1.TolerationOpExists, Effect: v1.TaintEffectNoSchedule, }) } ... _, reasons, err := Predicates(newPod, nodeInfo) return reasons, nodeInfo, err }
DeamonSetController會給Pod添加以下Toleratoins,防止Node出現(xiàn)以下Conditions被Node Controller Taint-based eviction殺死。
NotReady:NoExecute
Unreachable:NoExecute
MemoryPressure:NoSchedule
DisPressure:NoSchedule
當ExperimentalCriticalPodAnnotation Feature Gate Enable,并且該Pod是CriticalPod時,還會給該Pod加上OutOfDisk:NoSchedule
Toleration。
在simulate中,還會像類似scheduler一樣,進行Predicates處理。Predicates過程中也對CriticalPod做了區(qū)分對待。
pkg/controller/daemon/daemon_controller.go:1413 // Predicates checks if a DaemonSet's pod can be scheduled on a node using GeneralPredicates // and PodToleratesNodeTaints predicate func Predicates(pod *v1.Pod, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) { var predicateFails []algorithm.PredicateFailureReason // If ScheduleDaemonSetPods is enabled, only check nodeSelector and nodeAffinity. if false /*disabled for 1.10*/ && utilfeature.DefaultFeatureGate.Enabled(features.ScheduleDaemonSetPods) { fit, reasons, err := nodeSelectionPredicates(pod, nil, nodeInfo) if err != nil { return false, predicateFails, err } if !fit { predicateFails = append(predicateFails, reasons...) } return len(predicateFails) == 0, predicateFails, nil } critical := utilfeature.DefaultFeatureGate.Enabled(features.ExperimentalCriticalPodAnnotation) && kubelettypes.IsCriticalPod(pod) fit, reasons, err := predicates.PodToleratesNodeTaints(pod, nil, nodeInfo) if err != nil { return false, predicateFails, err } if !fit { predicateFails = append(predicateFails, reasons...) } if critical { // If the pod is marked as critical and support for critical pod annotations is enabled, // check predicates for critical pods only. fit, reasons, err = predicates.EssentialPredicates(pod, nil, nodeInfo) } else { fit, reasons, err = predicates.GeneralPredicates(pod, nil, nodeInfo) } if err != nil { return false, predicateFails, err } if !fit { predicateFails = append(predicateFails, reasons...) } return len(predicateFails) == 0, predicateFails, nil }
如果是CriticalPod,調(diào)用predicates.EssentialPredicates,否則調(diào)用predicates.GeneralPredicates。
這里的GeneralPredicates與EssentialPredicates有何不同呢?其實GeneralPredicates就是比EssentialPredicates多了noncriticalPredicates處理,也就是Scheduler的Predicate中的PodFitsResources。
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 }
因此,對于CriticalPod,DeamonSetController進行Predicate時不會進行PodFitsResources檢查。
在Kubernetes 1.11中,很重要的個更新就是,Priority和Preemption從alpha升級為Beta了,并且是Enabled by default。
Kubernetes Version | Priority and Preemption State | Enabled by default |
---|---|---|
1.8 | alpha | no |
1.9 | alpha | no |
1.10 | alpha | no |
1.11 | beta | yes |
PriorityClass是屬于scheduling.k8s.io/v1alpha1
GroupVersion的,在client提交創(chuàng)建PriorityClass請求后,寫入etcd前,會進行合法性檢查(Validate),這其中就有對SystemClusterCritical和SystemNodeCritical兩個PriorityClass的特殊對待。
pkg/apis/scheduling/validation/validation.go:30 // ValidatePriorityClass tests whether required fields in the PriorityClass are // set correctly. func ValidatePriorityClass(pc *scheduling.PriorityClass) field.ErrorList { ... // If the priorityClass starts with a system prefix, it must be one of the // predefined system priority classes. if strings.HasPrefix(pc.Name, scheduling.SystemPriorityClassPrefix) { if is, err := scheduling.IsKnownSystemPriorityClass(pc); !is { allErrs = append(allErrs, field.Forbidden(field.NewPath("metadata", "name"), "priority class names with '"+scheduling.SystemPriorityClassPrefix+"' prefix are reserved for system use only. error: "+err.Error())) } } ... return allErrs } // IsKnownSystemPriorityClass checks that "pc" is equal to one of the system PriorityClasses. // It ignores "description", labels, annotations, etc. of the PriorityClass. func IsKnownSystemPriorityClass(pc *PriorityClass) (bool, error) { for _, spc := range systemPriorityClasses { if spc.Name == pc.Name { if spc.Value != pc.Value { return false, fmt.Errorf("value of %v PriorityClass must be %v", spc.Name, spc.Value) } if spc.GlobalDefault != pc.GlobalDefault { return false, fmt.Errorf("globalDefault of %v PriorityClass must be %v", spc.Name, spc.GlobalDefault) } return true, nil } } return false, fmt.Errorf("%v is not a known system priority class", pc.Name) }
PriorityClass的Validate時,如果PriorityClass's Name是以**system-**為前綴的,那么必須是system-cluster-critical
或者system-node-critical
之一。否則就會Validate Error,拒絕提交。
如果提交的PriorityClass's Name為system-cluster-critical
或者system-node-critical
,那么要求globalDefault必須為false,即system-cluster-critical
或者system-node-critical
不能是全局默認的PriorityClass。
另外,在PriorityClass進行Update時,目前是不允許其Name和Value的,也就是說只能更新Description和globalDefault。
pkg/apis/scheduling/helpers.go:27 // SystemPriorityClasses define system priority classes that are auto-created at cluster bootstrapping. // Our API validation logic ensures that any priority class that has a system prefix or its value // is higher than HighestUserDefinablePriority is equal to one of these SystemPriorityClasses. var systemPriorityClasses = []*PriorityClass{ { ObjectMeta: metav1.ObjectMeta{ Name: SystemNodeCritical, }, Value: SystemCriticalPriority + 1000, Description: "Used for system critical pods that must not be moved from their current node.", }, { ObjectMeta: metav1.ObjectMeta{ Name: SystemClusterCritical, }, Value: SystemCriticalPriority, Description: "Used for system critical pods that must run in the cluster, but can be moved to another node if necessary.", }, }
到此,關于“Daemonset Controller對Critical Pod的特殊處理是什么”的學習就結(jié)束了,希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習,快去試試吧!若想繼續(xù)學習更多相關知識,請繼續(xù)關注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。