深入分析Kubernetes Critical Pod(四)

简介: 本文分析了DeamonSetController及PriorityClass Validate时,对CriticalPod的所做的特殊处理。

摘要:本文分析了DeamonSetController及PriorityClass Validate时,对CriticalPod的所做的特殊处理。

Daemonset Controller对CriticalPod的特殊处理

深入分析Kubernetes Critical Pod系列:
深入分析Kubernetes Critical Pod(一)
深入分析Kubernetes Critical Pod(二)
深入分析Kubernetes Critical Pod(三)
深入分析Kubernetes Critical Pod(四)

在DaemonSetController判断某个node上是否要运行某个DaemonSet时,会调用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出现以下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做了区分对待。

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,调用predicates.EssentialPredicates,否则调用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检查。

PriorityClass Validate对CriticalPod的特殊处理

在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/v1alpha1GroupVersion的,在client提交创建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.",
    },
}

总结

因此DeamonSetController及PriorityClass Validate时,对CriticalPod的特殊处理总结如下:

  • DaemonSetController会为CriticalPod加上OutOfDisk:NoScheduleToleration。
  • DeamonSetController对于CriticalPod进行Predicate时不会进行PodFitsResources检查。
  • 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。
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
Prometheus Kubernetes 监控
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
|
12月前
|
Kubernetes Docker 容器
Kubernetes与Docker参数对照:理解Pod中的command、args与Dockerfile中的CMD、ENTRYPOINT。
需要明确的是,理解这些都需要对Docker和Kubernetes有一定深度的理解,才能把握二者的区别和联系。虽然它们都是容器技术的二个重要组成部分,但各有其特性和适用场景,理解它们的本质和工作方式,才能更好的使用这些工具,将各自的优点整合到生产环境中,实现软件的快速开发和部署。
465 25
|
Kubernetes Shell Windows
【Azure K8S | AKS】在AKS的节点中抓取目标POD的网络包方法分享
在AKS中遇到复杂网络问题时,可通过以下步骤进入特定POD抓取网络包进行分析:1. 使用`kubectl get pods`确认Pod所在Node;2. 通过`kubectl node-shell`登录Node;3. 使用`crictl ps`找到Pod的Container ID;4. 获取PID并使用`nsenter`进入Pod的网络空间;5. 在`/var/tmp`目录下使用`tcpdump`抓包。完成后按Ctrl+C停止抓包。
445 12
|
存储 Kubernetes Docker
【赵渝强老师】Kubernetes中Pod的基础容器
Pod 是 Kubernetes 中的基本单位,代表集群上运行的一个进程。它由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。基础容器负责维护 Pod 的网络空间,对用户透明。文中附有图片和视频讲解,详细介绍了 Pod 的组成结构及其在网络配置中的作用。
277 1
【赵渝强老师】Kubernetes中Pod的基础容器
|
运维 Kubernetes Shell
【赵渝强老师】K8s中Pod的临时容器
Pod 是 Kubernetes 中的基本调度单位,由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。临时容器用于故障排查和性能诊断,不适用于构建应用程序。当 Pod 中的容器异常退出或容器镜像不包含调试工具时,临时容器非常有用。文中通过示例展示了如何使用 `kubectl debug` 命令创建临时容器进行调试。
292 1
|
Kubernetes 调度 容器
【赵渝强老师】K8s中Pod中的业务容器
Pod 是 Kubernetes 中的基本调度单元,由一个或多个容器组成。除了业务容器,Pod 还包括基础容器、初始化容器和临时容器。本文通过示例介绍如何创建包含业务容器的 Pod,并提供了一个视频讲解。示例中创建了一个名为 "busybox-container" 的业务容器,并使用 `kubectl create -f firstpod.yaml` 命令部署 Pod。
229 1
|
Kubernetes 容器 Perl
【赵渝强老师】K8s中Pod中的初始化容器
Kubernetes的Pod包含业务容器、基础容器、初始化容器和临时容器。初始化容器在业务容器前运行,用于执行必要的初始化任务。本文介绍了初始化容器的作用、配置方法及优势,并提供了一个示例。
317 1
|
5月前
|
人工智能 算法 调度
阿里云ACK托管集群Pro版共享GPU调度操作指南
本文介绍在阿里云ACK托管集群Pro版中,如何通过共享GPU调度实现显存与算力的精细化分配,涵盖前提条件、使用限制、节点池配置及任务部署全流程,提升GPU资源利用率,适用于AI训练与推理场景。
506 1
|
5月前
|
弹性计算 监控 调度
ACK One 注册集群云端节点池升级:IDC 集群一键接入云端 GPU 算力,接入效率提升 80%
ACK One注册集群节点池实现“一键接入”,免去手动编写脚本与GPU驱动安装,支持自动扩缩容与多场景调度,大幅提升K8s集群管理效率。
346 89
|
10月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
621 9

相关产品

  • 容器服务Kubernetes版
  • 推荐镜像

    更多