Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
Kubernetes 自带了一个默认调度器,其详细描述请查阅这里。
如果默认调度器不适合您的需求,您可以实现自己的调度器。
不仅如此,您甚至可以伴随着默认调度器同时运行多个调度器,并告诉 Kubernetes 为每个 pod 使用什么调度器。 让我们通过一个例子讲述如何在 Kubernetes 中运行多个调度器。
关于实现调度器的具体细节描述超出了本文范围。 请参考 kube-scheduler 的实现,规范示例代码位于 pkg/scheduler。
你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群,你可以通过 Minikube 构建一 个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:
要获知版本信息,请输入kubectl version
.
将调度器二进制文件打包到容器镜像中。出于示例目的,我们就使用默认调度器(kube-scheduler)作为我们的第二个调度器。
从 Github 克隆 Kubernetes 源代码,并编译构建源代码。
git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make
创建一个包含 kube-scheduler 二进制文件的容器镜像。用于构建镜像的 Dockerfile
内容如下:
FROM busybox
ADD ./_output/dockerized/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler
将文件保存为 Dockerfile
,构建镜像并将其推送到镜像仓库。
此示例将镜像推送到 Google 容器镜像仓库(GCR)。
有关详细信息,请阅读 GCR 文档。
docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .
gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0
现在我们将调度器放在容器镜像中,我们可以为它创建一个 pod 配置,并在我们的 Kubernetes 集群中运行它。
但是与其在集群中直接创建一个 pod,不如使用 Deployment。
Deployment 管理一个 Replica Set,Replica Set 再管理 pod,从而使调度器能够适应故障。
以下是 Deployment 配置,被保存为 my-scheduler.yaml
:
admin/sched/my-scheduler.yaml
|
---|
|
这里需要注意的是,在该部署文件中 Container 的 spec 配置的调度器启动命令参数(--scheduler-name)指定的调度器名称应该是惟一的。
这个名称应该与 pods 上的可选参数 spec.schedulerName
的值相匹配,也就是说调度器名称的匹配关系决定了 pods 的调度任务由哪个调度器负责。
还要注意,我们创建了一个专用服务帐户 my-scheduler
并将集群角色 system:kube-scheduler
绑定到它,以便它可以获得与 kube-scheduler
相同的权限。
请参阅 kube-scheduler 文档以获取其他命令行参数的详细说明。
为了在 Kubernetes 集群中运行我们的第二个调度器,只需在 Kubernetes 集群中创建上面配置中指定的 Deployment:
kubectl create -f my-scheduler.yaml
验证调度器 pod 正在运行:
$ kubectl get pods --namespace=kube-system
NAME READY STATUS RESTARTS AGE
....
my-scheduler-lnf4s-4744f 1/1 Running 0 2m
...
此列表中,除了默认的 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,如以下示例所示:
$ kubectl edit clusterrole system:kube-scheduler
- apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: system:kube-scheduler
rules:
- apiGroups:
- ""
resourceNames:
- kube-scheduler
- my-scheduler
resources:
- endpoints
verbs:
- delete
- get
- patch
- update
现在我们的第二个调度器正在运行,让我们创建一些 pod,并指定它们由默认调度器或我们刚部署的调度器进行调度。 为了使用特定的调度器调度给定的 pod,我们在那个 pod 的 spec 中指定调度器的名称。让我们看看三个例子。
admin/sched/pod1.yaml
|
---|
|
如果未提供调度器名称,则会使用 default-scheduler 自动调度 pod。
将此文件另存为 pod1.yaml
,并将其提交给 Kubernetes 集群。
kubectl create -f pod1.yaml
default-scheduler
admin/sched/pod2.yaml
|
---|
|
通过将调度器名称作为 spec.schedulerName
参数的值来指定调度器。在这种情况下,我们提供默认调度器的名称,即 default-scheduler
。
将此文件另存为 pod2.yaml
,并将其提交给 Kubernetes 集群。
kubectl create -f pod2.yaml
my-scheduler
admin/sched/pod3.yaml
|
---|
|
在这种情况下,我们指定此 pod 使用我们部署的 my-scheduler
来调度。
请注意,spec.schedulerName
参数的值应该与 Deployment 中配置的提供给 scheduler 命令的参数名称匹配。
将此文件另存为 pod3.yaml
,并将其提交给 Kubernetes 集群。
kubectl create -f pod3.yaml
确认所有三个 pod 都在运行。
kubectl get pods
为了更容易地完成这些示例,我们没有验证 pod 实际上是使用所需的调度程序调度的。
我们可以通过更改 pod 的顺序和上面的部署配置提交来验证这一点。
如果我们在提交调度器部署配置之前将所有 pod 配置提交给 Kubernetes 集群,我们将看到注解了 annotation-second-scheduler
的 pod 始终处于 “Pending” 状态,而其他两个 pod 被调度。
一旦我们提交调度器部署配置并且我们的新调度器开始运行,注解了 annotation-second-scheduler
的 pod 就能被调度。
或者,可以查看事件日志中的 “Scheduled” 条目,以验证是否由所需的调度器调度了 pod。
kubectl get events