默认应用扩缩容优先级策略 使用默认应用扩缩容优先级策略的情况下，集群中存在两个默认CR资源： Balancer CRD对应的CR资源 apiVersion: autoscaling.volcano.sh/v1alpha1 kind: Balancer metadata: name: default-balancer spec: balancerPolicyTemplateName: default-balancerpolicytemplate targets: - namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: Exists weight: 10 表1 Balancer对象关键参数说明 字段 含义 类型 备注 metadata.name 名称 String 必填字段。 spec. balancerPolicyTemplateName 优先级策略名称 String 必填字段。值为集群中相应BalancerPolicyTemplate CR资源名。 spec.targets 优先级策略作用范围 Slice 必填字段。举例： 针对default命名空间下的应用生效 spec: targets: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: default 针对default、other、another多个命名空间下的应用生效 spec: targets: - namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - default - other - another 针对所有命名空间下的应用生效 spec: targets: - namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: Exists 只针对名为xxx-xxx-xxx，类型为Deployment的应用生效 spec: targets: - objectSelectors: - name: xxx-xxx-xxx kind: Deployment 只针对命名空间为default，名为xxx-xxx-xxx类型为Deployment的应用生效 spec: targets: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: default objectSelectors: - name: xxx-xxx-xxx kind: Deployment spec.weight 优先级策略权重 int32 必填字段。在集群存在多个Balancer 对象资源情况下，某个应用可能存在于多个Balancer对象作用范围的交集中，此时选择weight值大的Balancer对象生效。 BalancerPolicyTemplate CRD对应的CR资源 apiVersion: autoscaling.volcano.sh/v1alpha1 kind: BalancerPolicyTemplate metadata: name: default-balancerpolicytemplate spec: policy: policyName: Priority priorities: priorityGroups: - priority: 10 requirements: - key: node.cce.io/billing-mode operator: In values: - post-paid - priority: 100 requirements: - key: node.cce.io/billing-mode operator: In values: - pre-paid - priority: 1 requirements: - key: kubernetes.io/role operator: In values: - virtual-kubelet - bursting 表2 BalancerPolicyTemplate对象关键参数说明 字段 含义 类型 备注 metadata.name 名称 String 必填字段。 spec.policy 优先级策略内容 Struct 必填字段。 spec.policy.policyname 优先级策略名 String 必填字段。当前只支持名为“Priority”的优先级策略。 spec.policy.priorities. priorityGroups 优先级策略中定义的具体优先级 Slice 必填字段。举例： 将包周期节点的优先级设置为100 priorityGroups: - priority: 100 requirements: - key: node.cce.io/billing-mode operator: In values: - pre-paid 将按需计费节点的优先级设置为10 priorityGroups: - priority: 10 requirements: - key: node.cce.io/billing-mode operator: In values: - post-paid 将virtual-kubelet/bursting节点的优先级设置为1 priorityGroups: - priority: 1 requirements: - key: kubernetes.io/role operator: In values: - virtual-kubelet - bursting

配置应用扩缩容优先级策略 开启应用扩缩容优先级策略开关并成功安装Volcano插件后，会在集群中创建默认扩缩容优先级策略。 获取默认Balancer CR资源。 # kubectl get balancer default-balancer -oyaml apiVersion: autoscaling.volcano.sh/v1alpha1 kind: Balancer metadata: name: default-balancer spec: balancerPolicyTemplateName: default-balancerpolicytemplate targets: - namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: Exists weight: 10 获取默认BalancerPolicyTemplate CR资源。 # kubectl get balancerpolicytemplate default-balancerpolicytemplate -oyaml apiVersion: autoscaling.volcano.sh/v1alpha1 kind: BalancerPolicyTemplate metadata: name: default-balancerpolicytemplate spec: policy: policyName: Priority priorities: priorityGroups: - priority: 10 requirements: - key: node.cce.io/billing-mode operator: In values: - post-paid - priority: 100 requirements: - key: node.cce.io/billing-mode operator: In values: - pre-paid - priority: 1 requirements: - key: kubernetes.io/role operator: In values: - virtual-kubelet - bursting 具体参数含义请参见默认应用扩缩容优先级策略。 部署工作负载，设定实例数为1。 当前应用的Pod将会优先调度到包周期节点上。 apiVersion: apps/v1 kind: Deployment metadata: name: balancer-test namespace: default labels: virtual-kubelet.io/burst-to-cci: 'auto' #如果集群资源不足时，支持将Pod部署到CCI集群 spec: replicas: 1 selector: matchLabels: app: balancer-test template: labels: app: balancer-test spec: containers: image: nginx:latest imagePullPolicy: IfNotPresent name: container-1 resources: limits: cpu: 250m memory: 512Mi requests: cpu: 250m memory: 512Mi schedulerName: volcano 调整工作负载实例数为5。 当前应用的Pod将会优先调度到包周期节点上。在包周期节点资源不足情况下，优先调度到按需计费节点上。在按需计费节点资源不足情况下，优先调度到virtual-kubelet节点（弹性至CCI）。 apiVersion: apps/v1 kind: Deployment metadata: name: balancer-test namespace: default labels: virtual-kubelet.io/burst-to-cci: 'auto' #如果集群资源不足时，支持将Pod部署到CCI集群 spec: replicas: 5 selector: matchLabels: app: balancer-test template: labels: app: balancer-test spec: containers: image: nginx:latest imagePullPolicy: IfNotPresent name: container-1 resources: limits: cpu: 250m memory: 512Mi requests: cpu: 250m memory: 512Mi schedulerName: volcano 查看各种类型节点上Pod的分值。 包周期节点上的Pod。 apiVersion: v1 kind: Pod metadata: annotations: autoscaling.volcano.sh/dominated-by-balancer: default-balancer #当前Pod通过名为default-balancer的Balancer CR资源控制扩缩优先级 openvessel.io/workload-balancer-score: "100" #当前包周期节点对应的优先级，也代表着Pod的分值 ... nodeName: 192.168.20.100 #包周期节点 按需计费节点上的Pod。 apiVersion: v1 kind: Pod metadata: annotations: autoscaling.volcano.sh/dominated-by-balancer: default-balancer #当前Pod通过名为default-balancer的Balancer CR资源控制扩缩优先级 openvessel.io/workload-balancer-score "10" #当前按需计费节点对应的优先级，也代表着Pod的分值 ... nodeName: 192.168.20.196 #按需计费节点 virtual-kubelet节点（弹性至CCI）的Pod。 apiVersion: v1 kind: Pod metadata: annotations: autoscaling.volcano.sh/dominated-by-balancer: default-balancer #当前Pod通过名为default-balancer的Balancer CR资源控制扩缩优先级 openvessel.io/workload-balancer-score: "1" #当前virtual-kubelet节点对应的优先级，也代表着pod的分值 ... nodeName: virtual-kubelet #virtual-kubelet节点 逐步进行工作负载的缩容操作，调小实例数。 virtual-kubelet节点（弹性至CCI）的Pod将优先被删除，其次为按需计费节点上的Pod，最后为包周期节点上的Pod。

自定义应用扩缩容优先级策略 BalancerPolicyTemplate 资源用来进行优先级策略定义，如果用户需要自定义应用扩缩容优先级策略，则需要针对其内容进行修改。 如果存在多个BalancerPolicyTemplate资源，扩缩策略执行结果将受到这些资源对象的共同作用。因此，如果用户不存在默认扩缩容优先级策略的应用场景，可以执行如下命令对默认优先级策略进行删除。 kubectl delete balancerpolicytemplate default-balancerpolicytemplate 以“扩容时优先将工作负载调度到HCE2.0操作系统的节点，其次调度到欧拉操作系统的节点；缩容时优先删除欧拉操作系统节点上的工作负载，其次删除HCE2.0操作系统上的工作负载”为例： 编写新BalancerPolicyTemplate 资源对象。 vim new-balancerpolicytemplate.yaml 内容如下： apiVersion: autoscaling.volcano.sh/v1alpha1 kind: BalancerPolicyTemplate metadata: name: new-balancerpolicytemplate spec: policy: policyName: Priority priorities: priorityGroups: - priority: 10 # 设置欧拉操作系统节点优先级为10 requirements: - key: os.name # 节点操作系统标签 operator: In values: - EulerOS_2.0_SP9x86_64 # 可能涉及操作系统的小版本号，用户可以根据自身场景，任意添加 - priority: 100 # 设置HCE2.0操作系统节点优先级为100 requirements: - key: os.name # 节点操作系统标签 operator: In values: - Huawei_Cloud_EulerOS_2.0_x86_64 创建新BalancerPolicyTemplate资源对象。 kubectl create -f new-balancerpolicytemplate.yaml 修改default-balancer对象内容，也可以按需进行新建balancer对象 kubectl edit balancer default-balancer 修改内容如下： apiVersion: autoscaling.volcano.sh/v1alpha1 kind: Balancer metadata: name: default-balancer spec: balancerPolicyTemplateName: new-balancerpolicytemplate targets: - namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: Exists weight: 10 查看各个Pod的注解中openvessel.io/workload-balancer-score对应的值是否满足预期。 EulerOS节点上Pod的openvessel.io/workload-balancer-score注解对应值是10；HCE2.0节点上的pod 的openvessel.io/workload-balancer-score注解对应值是100。

应用扩缩容优先级策略介绍 开启应用扩缩容优先级策略，将会在集群中新增两类CRD资源，分别为Balancer与BalancerPolicyTemplate，并创建默认的扩缩容优先级策略，详情请参见默认应用扩缩容优先级策略。Volcano插件根据BalancerPolicyTemplate来获取各个节点的优先级，以控制应用扩容时Pod调度的优先级，同时volcano插件基于Balancer和BalancerPolicyTemplate来设置应用缩容时的优先级。 BalancerPolicyTemplate CRD资源用来进行优先级策略定义。以默认扩缩容优先级策略为例，默认BalancerPolicyTemplate CR资源将会把包周期节点的优先级设置为最高，按需计费节点次之，virtual-kubelet节点（弹性至CCI）设置为最低。 BalancerPolicyTemplate CR资源不支持更新操作。 Balancer CRD资源用来申明扩缩容优先级的作用范围。创建Balancer CR资源时，可以指定某个命名空间下的工作负载作为生效范围，也可以具体指定某个Deployment或者某个ReplicaSet工作负载作为生效范围。 一个Balancer CR资源对应一个BalancerPolicyTemplate CR资源，两者结合共同申明哪些工作负载使用了哪些优先级策略。 插件默认的扩缩容优先级策略通过BalancerPolicyTemplate对象将包周期节点、按需计费节点、virtual-kubelet节点（弹性至CCI）三种类型分成不同的优先级，扩容时，volcano在调度新增Pod时将会考虑这些优先级，优先将Pod调度到优先级高的包周期节点上。 通过Balancer和BalancerPolicyTemplate对象，Volcano插件对Balancer作用范围内的Pod，根据BalancerPolicyTemplate对象定义的优先级分别打上以下注解： openvessel.io/workload-balancer-score：表示Pod的分值，对于高优先级节点上的Pod，其对应的分值也相对较大。 autoscaling.volcano.sh/dominated-by-balancer：表示当前Pod受哪个Balancer对象控制，缩容时会优先缩容分值低的Pod。 如果用户原先的Pod已经存在社区支持的controller.kubernetes.io/pod-deletion-cost注解，那么缩容时将会按照该值定义的优先级来进行缩容。当两个Pod对应controller.kubernetes.io/pod-deletion-cost值相同时，才会按照openvessel.io/workload-balancer-score注解定义的优先级进行缩容。

Volcano开启NUMA亲和性调度 开启静态（static）CPU管理策略，具体请参考 开启CPU管理策略。 配置CPU拓扑策略。 登录CCE控制台，单击集群名称进入集群，在左侧选择“节点管理”，在右侧选择“节点池”页签，单击节点池名称后的“ 配置管理”。 将kubelet的拓扑管理策略（topology-manager-policy）的值修改为需要的CPU拓扑策略即可。 有效拓扑策略为“none”、“best-effort”、“restricted”、“single-numa-node”，具体策略对应的调度行为请参见Pod调度预测。 开启numa-aware插件功能和resource_exporter功能。 Volcano 1.7.1及以上版本 登录CCE控制台，单击集群名称进入集群，单击左侧导航栏的“插件中心”，在右侧找到Volcano，单击“编辑”，并在“参数配置”中设置Volcano调度器配置参数。 { "ca_cert": "", "default_scheduler_conf": { "actions": "allocate, backfill, preempt", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { // add this also enable resource_exporter "name": "numa-aware", // the weight of the NUMA Aware Plugin "arguments": { "weight": "10" } } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, "server_cert": "", "server_key": "" } Volcano 1.7.1以下版本 Volcano插件开启resource_exporter_enable参数，用于收集节点numa拓扑信息。 { "plugins": { "eas_service": { "availability_zone_id": "", "driver_id": "", "enable": "false", "endpoint": "", "flavor_id": "", "network_type": "", "network_virtual_subnet_id": "", "pool_id": "", "project_id": "", "secret_name": "eas-service-secret" } }, "resource_exporter_enable": "true" } 开启后可以查看当前节点的numa拓扑信息。 kubectl get numatopo NAME AGE node-1 4h8m node-2 4h8m node-3 4h8m 启用Volcano numa-aware算法插件。 kubectl edit cm -n kube-system volcano-scheduler-configmap kind: ConfigMap apiVersion: v1 metadata: name: volcano-scheduler-configmap namespace: kube-system data: default-scheduler.conf: |- actions: "allocate, backfill, preempt" tiers: - plugins: - name: priority - name: gang - name: conformance - plugins: - name: overcommit - name: drf - name: predicates - name: nodeorder - plugins: - name: cce-gpu-topology-predicate - name: cce-gpu-topology-priority - name: cce-gpu - plugins: - name: nodelocalvolume - name: nodeemptydirvolume - name: nodeCSIscheduling - name: networkresource arguments: NetworkType: vpc-router - name: numa-aware # add it to enable numa-aware plugin arguments: weight: 10 # the weight of the NUMA Aware Plugin

调度优先级 不管是什么拓扑策略，都是希望把Pod调度到当时最优的节点上，这里通过给每一个节点进行打分的机制来排序筛选最优节点。 原则：尽可能把Pod调度到需要跨NUMA节点最少的工作节点上。 打分公式如下： score = weight * (100 - 100 * numaNodeNum / maxNumaNodeNum) 参数说明： weight：NUMA Aware Plugin的权重。 numaNodeNum：表示工作节点上运行该Pod需要NUMA节点的个数。 maxNumaNodeNum：表示所有工作节点中该Pod的最大NUMA节点个数。 例如，假设有三个节点满足Pod的CPU拓扑策略，且NUMA Aware Plugin的权重设为10： Node A：由1个NUMA节点提供Pod所需的CPU资源，即numaNodeNum=1 Node B：由2个NUMA节点提供Pod所需的CPU资源，即numaNodeNum=2 Node C：由4个NUMA节点提供Pod所需的CPU资源，即numaNodeNum=4 则根据以上公式，maxNumaNodeNum=4 score(Node A) = 10 * (100 - 100 * 1 / 4) = 750 score(Node B) = 10 * (100 - 100 * 2 / 4) = 500 score(Node C) = 10 * (100 - 100 * 4 / 4) = 0 因此最优节点为Node A。

确认NUMA使用情况 您可以通过lscpu命令查看当前节点的CPU概况： # 查看当前节点的CPU概况 lscpu ... CPU(s): 32 NUMA node(s): 2 NUMA node0 CPU(s): 0-15 NUMA node1 CPU(s): 16-31 然后查看NUMA节点使用情况。 # 查看当前节点的CPU分配 cat /var/lib/kubelet/cpu_manager_state {"policyName":"static","defaultCpuSet":"0,10-15,25-31","entries":{"777870b5-c64f-42f5-9296-688b9dc212ba":{"container-1":"16-24"},"fb15e10a-b6a5-4aaa-8fcd-76c1aa64e6fd":{"container-1":"1-9"}},"checksum":318470969} 以上示例中表示，节点上运行了两个容器，一个占用了NUMA node0的1-9核，另一个占用了NUMA node1的16-24核。

使用Volcano设置NUMA亲和性调度 以下为使用Volcano设置NUMA亲和性调度的示例。 示例一：在无状态工作负载中配置NUMA亲和性。 kind: Deployment apiVersion: apps/v1 metadata: name: numa-tset spec: replicas: 1 selector: matchLabels: app: numa-tset template: metadata: labels: app: numa-tset annotations: volcano.sh/numa-topology-policy: single-numa-node # set the topology policy spec: containers: - name: container-1 image: nginx:alpine resources: requests: cpu: 2 # 必须为整数，且需要与limits中一致 memory: 2048Mi limits: cpu: 2 # 必须为整数，且需要与requests中一致 memory: 2048Mi imagePullSecrets: - name: default-secret 示例二：创建一个Volcano Job，并使用NUMA亲和性。 apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: vj-test spec: schedulerName: volcano minAvailable: 1 tasks: - replicas: 1 name: "test" topologyPolicy: best-effort # set the topology policy for task template: spec: containers: - image: alpine command: ["/bin/sh", "-c", "sleep 1000"] imagePullPolicy: IfNotPresent name: running resources: limits: cpu: 20 memory: "100Mi" restartPolicy: OnFailure NUMA调度分析。 假设NUMA节点情况如下： 工作节点 节点策略拓扑管理器策略 NUMA 节点 0 上的可分配 CPU NUMA 节点 1 上的可分配 CPU node-1 single-numa-node 16U 16U node-2 best-effort 16U 16U node-3 best-effort 20U 20U 则根据以上示例， 示例一中，Pod的CPU申请值为2U，设置拓扑策略为“single-numa-node”，因此会被调度到相同策略的node-1。 示例二中，Pod的CPU申请值为20U，设置拓扑策略为“best-effort”，它将被调度到node-3，因为node-3可以在单个NUMA节点上分配Pod的CPU请求，而node-2需要在两个NUMA节点上执行此操作。

背景信息 当节点运行许多CPU绑定的Pod时，工作负载可以迁移到不同的CPU核心，这取决于Pod是否被限制以及调度时哪些CPU核心可用。许多工作负载对此迁移不敏感，因此在没有任何干预的情况下工作正常。但是，在CPU缓存亲和性和调度延迟显著影响工作负载性能的工作负载中，如果CPU是从不同的NUMA节点分配的，会导致额外的延迟。因此kubelet允许使用拓扑管理器（Topology Manager）替代CPU管理策略来确定节点的分配。 CPU Manager和拓扑管理器都是kubelet组件，但有以下限制： K8s默认调度器不感知NUMA拓扑。因此，可能会调度到不满足NUMA拓扑要求的节点上，然后工作负载实例启动失败。这对于Tensorflow作业来说是不可接受的。如果节点上有任何工作进程或ps失败，则作业将失败。 管理器是节点级的，导致无法匹配整个集群中NUMA拓扑的最佳节点。 Volcano的目标是解决调度程序NUMA拓扑感知的限制，以便实现以下目标： 避免将Pod调度到NUMA拓扑不匹配的节点。 将Pod调度到NUMA拓扑的最佳节点。 更多资料请查看社区NUMA亲和性插件指导链接：https://github.com/volcano-sh/volcano/blob/master/docs/design/numa-aware.md

Pod调度预测 当Pod设置了拓扑策略时，Volcano会根据Pod设置的拓扑策略预测匹配的节点列表。调度过程如下： 根据Pod设置的Volcano拓扑策略，筛选具有相同策略的节点。Volcano提供的拓扑策略与拓扑管理器相同。 在设置了相同策略的节点中，筛选CPU拓扑满足该策略要求的节点进行调度。 Volcano拓扑策略 节点调度行为 1.筛选具有相同策略的节点 2.节点的CPU拓扑满足该策略的要求 none 无筛选行为： none：可调度 best-effort：可调度 restricted：可调度 single-numa-node：可调度 - best-effort 筛选拓扑策略同样为“best-effort”的节点： none：不可调度 best-effort：可调度 restricted：不可调度 single-numa-node：不可调度 尽可能满足策略要求进行调度： 优先调度至单NUMA节点，如果单NUMA节点无法满足CPU申请值，允许调度至多个NUMA节点。 restricted 筛选拓扑策略同样为“restricted”的节点： none：不可调度 best-effort：不可调度 restricted：可调度 single-numa-node：不可调度 严格限制的调度策略： 单NUMA节点的CPU容量上限大于等于CPU的申请值时，仅允许调度至单NUMA节点。此时如果单NUMA节点剩余的CPU可使用量不足，则Pod无法调度。 单NUMA节点的CPU容量上限小于CPU的申请值时，可允许调度至多个NUMA节点。 single-numa-node 筛选拓扑策略同样为“single-numa-node”的节点： none：不可调度 best-effort：不可调度 restricted：不可调度 single-numa-node：可调度 仅允许调度至单NUMA节点。 假设单个节点CPU总量为32U，由2个NUMA节点提供资源，分配如下： 工作节点 节点拓扑策略 NUMA节点1上的CPU总量 NUMA节点2上的CPU总量 节点-1 best-effort 16 16 节点-2 restricted 16 16 节点-3 restricted 16 16 节点-4 single-numa-node 16 16 Pod设置拓扑策略后，调度情况如图1所示。 当Pod的CPU申请值为9U时，设置拓扑策略为“best-effort”，Volcano会匹配拓扑策略同样为“best-effort”的节点-1，且该策略允许调度至多个NUMA节点，因此9U的申请值会被分配到2个NUMA节点，该Pod可成功调度至节点-1。 当Pod的CPU申请值为9U时，设置拓扑策略为“restricted”，Volcano会匹配拓扑策略同样为“restricted”的节点-2/节点-3，且单NUMA节点CPU总量满足9U的申请值，但单NUMA节点剩余可用的CPU量无法满足，因此该Pod无法调度。 当Pod的CPU申请值为17U时，设置拓扑策略为“restricted”，Volcano会匹配拓扑策略同样为“restricted”的节点-2/节点-3，且单NUMA节点CPU总量无法满足17U的申请值，可允许分配到2个NUMA节点，该Pod可成功调度至节点-3。 当Pod的CPU申请值为17U时，设置拓扑策略为“single-numa-node”，Volcano会匹配拓扑策略同样为“single-numa-node”的节点，但由于单NUMA节点CPU总量均无法满足17U的申请值，因此该Pod无法调度。 图1 NUMA调度策略对比

Volcano Scheduler Volcano Scheduler是负责Pod调度的组件，它由一系列action和plugin组成。action定义了调度各环节中需要执行的动作；plugin根据不同场景提供了action 中算法的具体实现细节。Volcano Scheduler具有高度的可扩展性，您可以根据需要实现自己的action和plugin。 图1 Volcano Scheduler工作流 Volcano Scheduler的工作流程如下： 客户端提交的Job被调度器识别到并缓存起来。 周期性开启会话，一个调度周期开始。 将没有被调度的Job发送到会话的待调度队列中。 遍历所有的待调度Job，按照定义的次序依次执行enqueue、allocate、preempt、reclaim、backfill等动作，为每个Job找到一个最合适的节点。将该Job 绑定到这个节点。action中执行的具体算法逻辑取决于注册的plugin中各函数的实现。 关闭本次会话。

Volcano自定义资源 Pod组（PodGroup）：Pod组是Volcano自定义资源类型，代表一组强关联Pod的集合，主要用于批处理工作负载场景，比如Tensorflow中的一组ps和worker。 队列（Queue）：容纳一组PodGroup的队列，也是该组PodGroup获取集群资源的划分依据。 作业（Volcano Job，简称vcjob）：Volcano自定义的Job资源类型。区别于Kubernetes Job，vcjob提供了更多高级功能，如可指定调度器、支持最小运行Pod数、 支持task、支持生命周期管理、支持指定队列、支持优先级调度等。Volcano Job更加适用于机器学习、大数据、科学计算等高性能计算场景。