配置多个调度器

    关于实现调度器的具体细节描述超出了本文范围。 请参考 kube-scheduler 的实现，规范示例代码位于 pkg/scheduler。

    你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群，你可以通过 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

    要获知版本信息，请输入 .

    将调度器二进制文件打包到容器镜像中。出于示例目的，我们就使用默认调度器（kube-scheduler）作为我们的第二个调度器。 从 Github 克隆 Kubernetes 源代码，并编译构建源代码。

    创建一个包含 kube-scheduler 二进制文件的容器镜像。用于构建镜像的 Dockerfile 内容如下：

    1. FROM busybox
    2. ADD ./_output/dockerized/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler

    将文件保存为 Dockerfile，构建镜像并将其推送到镜像仓库。 此示例将镜像推送到 。 有关详细信息，请阅读 GCR 文档。

    1. docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .
    2. gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0

    现在我们将调度器放在容器镜像中，我们可以为它创建一个 pod 配置，并在我们的 Kubernetes 集群中运行它。 但是与其在集群中直接创建一个 pod，不如使用 。 Deployment 管理一个 ，Replica Set 再管理 pod，从而使调度器能够适应故障。 以下是 Deployment 配置，被保存为 my-scheduler.yaml：

    这里需要注意的是，在该部署文件中 Container 的 spec 配置的调度器启动命令参数（–scheduler-name）指定的调度器名称应该是惟一的。 这个名称应该与 pods 上的可选参数 spec.schedulerName 的值相匹配，也就是说调度器名称的匹配关系决定了 pods 的调度任务由哪个调度器负责。

    请参阅 kube-scheduler 文档以获取其他命令行参数的详细说明。

    为了在 Kubernetes 集群中运行我们的第二个调度器，只需在 Kubernetes 集群中创建上面配置中指定的 Deployment：

    1. kubectl create -f my-scheduler.yaml

    验证调度器 pod 正在运行：

    此列表中，除了默认的 kube-scheduler pod 之外，您应该还能看到处于 “Running” 状态的 my-scheduler pod。

    要在启用了 leader 选举的情况下运行多调度器，您必须执行以下操作：

    首先，更新上述 Deployment YAML（my-scheduler.yaml）文件中的以下字段：

    • --leader-elect=true
    • --lock-object-namespace=lock-object-namespace
    • --lock-object-name=lock-object-name

    如果在集群上启用了 RBAC，则必须更新 system：kube-scheduler 集群角色。将调度器名称添加到应用于端点资源的规则的 resourceNames，如以下示例所示：

    1. $ kubectl edit clusterrole system:kube-scheduler
    2. - apiVersion: rbac.authorization.k8s.io/v1
    3.   kind: ClusterRole
    4.   metadata:
    5.     annotations:
    6.       rbac.authorization.kubernetes.io/autoupdate: "true"
    7.     labels:
    8.       kubernetes.io/bootstrapping: rbac-defaults
    9.     name: system:kube-scheduler
    10.   rules:
    11.   - apiGroups:
    12.     - ""
    13.     - kube-scheduler
    14.     - my-scheduler
    15.     resources:
    16.     - endpoints
    17.     verbs:
    18.     - delete
    20.     - patch
    21.     - update

    现在我们的第二个调度器正在运行，让我们创建一些 pod，并指定它们由默认调度器或我们刚部署的调度器进行调度。 为了使用特定的调度器调度给定的 pod，我们在那个 pod 的 spec 中指定调度器的名称。让我们看看三个例子。

    • Pod spec 没有任何调度器名称

    将此文件另存为 pod1.yaml，并将其提交给 Kubernetes 集群。

    1. kubectl create -f pod1.yaml
    • Pod spec 设置为 default-scheduler

    通过将调度器名称作为 spec.schedulerName 参数的值来指定调度器。在这种情况下，我们提供默认调度器的名称，即 default-scheduler。

    将此文件另存为 pod2.yaml，并将其提交给 Kubernetes 集群。

    • Pod spec 设置为 my-scheduler

    在这种情况下，我们指定此 pod 使用我们部署的 my-scheduler 来调度。 请注意，spec.schedulerName 参数的值应该与 Deployment 中配置的提供给 scheduler 命令的参数名称匹配。

    将此文件另存为 pod3.yaml，并将其提交给 Kubernetes 集群。

    1. kubectl create -f pod3.yaml

    确认所有三个 pod 都在运行。

    1. kubectl get pods

    为了更容易地完成这些示例，我们没有验证 pod 实际上是使用所需的调度程序调度的。 我们可以通过更改 pod 的顺序和上面的部署配置提交来验证这一点。 如果我们在提交调度器部署配置之前将所有 pod 配置提交给 Kubernetes 集群，我们将看到注解了 annotation-second-scheduler 的 pod 始终处于 “Pending” 状态，而其他两个 pod 被调度。 一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了 annotation-second-scheduler 的 pod 就能被调度。

    或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 pod。