k8s scheduler配置多调度器 |
您所在的位置：网站首页 › 龙井茶水图片大全 › k8s scheduler配置多调度器 |
k8s scheduler配置多调度器
|
kubernetes 多调度器
一、前言二、环境准备2.1 使用 yum 安装 git2.2 配置 go 环境
三、构建第二个调度器3.1 拉取源码3.2 编译源码3.2 创建调度器镜像3.4 生成调度器 yaml 文件
四、使用自定义调度器4.1 部署不同 pod4.2 部署自定义调度器
一、前言
Kubernetes 支持多个调度器共存，在部署 pod 时，可在 yaml 配置文件通过schedulerName中指定调度器。 实际上，调度器就是运行在集群中的一个 deployment，因此构建自己的调度器，其本质就是创建一个 deployment。 构建调度器的步骤如下： 编写调度器编译构建代码生成调度器容器镜像部署调度器使用调度器在本文中，将利用 kubernetes 中默认调度器 kube-scheduler 的源码构建一个自己的调度器（并未修改源码）。 二、环境准备首先要搭建好 k8s 集群，并完成对 master 节点的初始化及 flannel 网络部署等步骤。可见 Centos7部署k8s集群。 接下来，要安装一些构建过程中用到的工具。 2.1 使用 yum 安装 git由于需要使用 kube-scheduler 源码，因此需要使用 git 命令从 GitHub 上拉取源码。安装 git 很简单，直接使用下面命令。 [root@master ~]# yum install git 2.2 配置 go 环境在下载好源码后，需要对源码进行编译，因此需要使用 go 语言。配置 go 环境如下。 安装 golang [root@master ~]# yum install golang 为 golang 添加环境变量 在文件最后添加三行代码。 [root@master ~]# vim /etc/profile # 添加代码如下 # GOROOT export GOROOT=/usr/lib/golang # GOPATH export GOPATH=/root/go/ # GOPATH bin export PATH=$PATH:$GOROOT/bin:$GOPATH/bin 设置环境变量立即生效 [root@master ~]# source /etc/profile # 查看是否成功 [root@master ~]# go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/root/.cache/go-build" GOENV="/root/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/root/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/root/go/" GOPRIVATE="" GOPROXY="direct" GOROOT="/usr/lib/golang" GOSUMDB="off" GOTMPDIR="" GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build083138936=/tmp/go-build -gno-record-gcc-switches" 三、构建第二个调度器 3.1 拉取源码利用 git 命令从 GitHub 上拉取 Kubernetes 源码。 [root@master ~]# git clone https://github.com/kubernetes/kubernetes.git 正克隆到 'kubernetes'... remote: Enumerating objects: 218, done. remote: Counting objects: 100% (218/218), done. remote: Compressing objects: 100% (127/127), done. remote: Total 1169214 (delta 112), reused 91 (delta 91), pack-reused 1168996 接收对象中: 100% (1169214/1169214), 710.89 MiB | 5.30 MiB/s, done. 处理 delta 中: 100% (839490/839490), done. Checking out files: 100% (22748/22748), done.因为源码比较大，可能时间较久。 可通过 ls 命令列出根目录下文件夹，若有kubernetes 文件夹，则下载成功。 WHAT：指定要编译的文件路径，kube-scheduler 源码位于 cmd 文件夹下。如果不指定 WHAT，则会对整个 kubernetes 的源码进行编译。编译的过程比较慢，需要耐心等待。 若编译中报错 ./hack/run-in-gopath.sh: 行 34: 49138 已杀死 "${@}" make[1]: *** [gen_deepcopy] 错误1 make: *** [ generated_files] 错误 2可能是因为 master 节点内存太小，导致编译失败，可尝试增加 master 节点内存至少为 3GB。另外，可用make clear来清除编译文件。 3.2 创建调度器镜像 生成 Dockerfile 文件 [root@master kubernetes]# vim Dockerfile # 文件内容 FROM busybox ADD /_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler命令解析 FROM：定制的镜像都是基于 FROM 的镜像，这里的 busybox 就是定制需要的基础镜像。后续的操作都是基于 busybox 。 ADD：复制指令，从上下文目录中复制文件或者目录到容器里指定路径。 创建镜像 [root@master kubernetes]# docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 . Sending build context to Docker daemon 1.669GB Step 1/2 : FROM busybox ---> f0b02e9d092d Step 2/2 : ADD /_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler ---> dc4af52b3c99 Successfully built dc4af52b3c99 Successfully tagged gcr.io/my-gcp-project/my-kube-scheduler:1.0在 Dockerfile 文件的存放目录下，执行构建动作。 最后的 . 代表本次执行的上下文路径。上下文路径，是指 docker 在构建镜像，有时候想要使用到本机的文件（比如复制），docker build 命令得知这个路径后，会将路径下的所有内容打包。如果未说明最后一个参数，那么默认上下文路径就是 Dockerfile 所在的位置。 注：可能第二步会失败，这是因为 Dockerfile 文件中第二行命令中的第一个路径错误，导致找不到编译后的 kube-scheduler 文件，此时可根据错误信息查找文件位置。 Step 2/2 : ADD ./_output/bin/kube-scheduler /usr/local/bin/kube-scheduler ADD failed: stat /var/lib/docker/tmp/docker-builder066148616/root/kubernetes/_output/local/bin/linux/amd64/kube-scheduler: no such file or directory 创建成功后，可查看镜像是否已存在 [root@master kubernetes]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE gcr.io/my-gcp-project/my-kube-scheduler 1.0 dc4af52b3c99 About an hour ago 44MB 3.4 生成调度器 yaml 文件将调度器放在容器镜像中，我们可以为它创建一个 Pod 配置，并在我们的 Kubernetes 集群中运行它。但是与其在集群中直接创建一个 Pod，不如使用 Deployment。 Deployment 管理一个 ReplicaSet， ReplicaSet 再管理 Pod，从而使调度器能够免受一些故障的影响 [root@master kubernetes]# vim my-scheduler.yaml apiVersion: v1 kind: ServiceAccount metadata: name: my-scheduler namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-scheduler-as-kube-scheduler subjects: - kind: ServiceAccount name: my-scheduler namespace: kube-system roleRef: kind: ClusterRole name: system:kube-scheduler apiGroup: rbac.authorization.k8s.io --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: my-scheduler-as-volume-scheduler subjects: - kind: ServiceAccount name: my-scheduler namespace: kube-system roleRef: kind: ClusterRole name: system:volume-scheduler apiGroup: rbac.authorization.k8s.io --- apiVersion: apps/v1 kind: Deployment metadata: labels: component: scheduler tier: control-plane name: my-scheduler namespace: kube-system spec: selector: matchLabels: component: scheduler tier: control-plane replicas: 1 template: metadata: labels: component: scheduler tier: control-plane version: second spec: serviceAccountName: my-scheduler containers: - command: - /usr/local/bin/kube-scheduler - --address=0.0.0.0 - --leader-elect=false - --scheduler-name=my-scheduler image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 livenessProbe: httpGet: path: /healthz port: 10251 initialDelaySeconds: 15 name: kube-second-scheduler readinessProbe: httpGet: path: /healthz port: 10251 resources: requests: cpu: '0.1' securityContext: privileged: false volumeMounts: [] hostNetwork: false hostPID: false volumes: []这里需要注意的是，在容器规约中配置的调度器启动命令参数（–scheduler-name）所指定的 调度器名称应该是唯一的。 这个名称应该与 Pod 上的可选参数 spec.schedulerName 的值相匹配，也就是说调度器名称的匹配关系决定了 Pods 的调度任务由哪个调度器负责。 还要注意，我们创建了一个专用服务账号 my-scheduler 并将集群角色 system:kube-scheduler 绑定到它，以便它可以获得与 kube-scheduler 相同的权限。 注：为测试自定义调度器是否被使用，我们先不部署调度器，在下面的实验中部署 pod 后再部署调度器。 四、使用自定义调度器为测试自定义调度器是否能被使用，这里我们定义三个 pod ，使其分别用不同的方式进行部署，观察实验结果。 4.1 部署不同 pod 不指定调度器的 pod 在构建此 pod 时，不指定调度器。 [root@master ~]# vim pod1.yaml apiVersion: v1 kind: Pod metadata: name: pod1 labels: name: multischeduler-example spec: containers: - name: pod-with-no-annotation-container image: nginx 指定默认调度器 在此 pod 中，指定使用默认调度器。 [root@master ~]# vim pod2.yaml apiVersion: v1 kind: Pod metadata: name: pod2 labels: name: multischeduler-example spec: schedulerName: default-scheduler containers: - name: pod-with-default-annotation-container image: nginx 指定自定义调度器 在此 pod 中，指定自定义调度器 my-scheduler。 [root@master ~]# vim pod3.yaml apiVersion: v1 kind: Pod metadata: name: pod3 labels: name: multischeduler-example spec: schedulerName: my-scheduler containers: - name: pod-with-second-annotation-container image: nginx 依次部署三个 pod [root@master ~]# kubectl create -f pod1.yaml pod/pod1 created [root@master ~]# kubectl create -f pod2.yaml pod/pod2 created [root@master ~]# kubectl create -f pod3.yaml pod/pod3 created 查看 pod 状态 [root@master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod1 1/1 Running 0 42s pod2 1/1 Running 0 38s pod3 0/1 Pending 0 33s可以看到，pod1 和 pod2 处于运行状态，但 pod3一直处于 Pending 状态。这是因为 pod3 使用自定义调度器，而自定义调度器还未部署，因此 pod3 无法部署。 4.2 部署自定义调度器 部署自定义调度器 利用之前编写的 my-schedule.yaml 文件，部署调度器。 [root@master ~]# cd kubernetes [root@master kubernetes]# kubectl create -f my-scheduler.yaml serviceaccount/my-scheduler created clusterrolebinding.rbac.authorization.k8s.io/my-scheduler-as-kube-scheduler created clusterrolebinding.rbac.authorization.k8s.io/my-scheduler-as-volume-scheduler created deployment.apps/my-scheduler created注意：由于my-scheduler.yaml在 kubernetes 目录下，因此部署前要先进入该目录。 再次查看 pod 状态 [root@master kubernetes]# kubectl get pod NAME READY STATUS RESTARTS AGE pod1 1/1 Running 0 71s pod2 1/1 Running 0 67s pod3 0/1 ContainerCreating 0 62s [root@master kubernetes]# kubectl get pod NAME READY STATUS RESTARTS AGE pod1 1/1 Running 0 82s pod2 1/1 Running 0 78s pod3 1/1 Running 0 73s可以看到自定义调度器部署成功后 pod3 开始部署，过一段时间后变为 Running 状态，说明成功使用自定义的调度器部署了 pod3。 |
【本文地址】
今日新闻 |
推荐新闻 |