K8S Scheduler 是做什么的
Kubernetes Scheduler 的作用是将待调度的 Pod 按照一定的调度算法和策略绑定到集群中一个合适的 Worker Node（以下简称 Node） 上，并将绑定信息写入到 etcd 中，之后目标 Node 中 kubelet 服务通过 API Server 监听到 Scheduler 产生的 Pod 绑定事件获取 Pod 信息，然后下载镜像启动容器，调度流程如图所示：
Scheduler 提供的调度流程分为预选 (Predicates) 和优选 (Priorities) 两个步骤：
经过预选筛选和优选打分之后，K8S 选择分数最高的 Node 来运行 Pod，如果最终有多个 Node 的分数最高，那么 Scheduler 将从当中随机选择一个 Node 来运行 Pod。
K8S Scheduler 提供的预选策略
在 Scheduler 中，可选的预选策略包括：
如果开启了 TaintNodesByCondition(从 1.12 开始为 beta 级别，默认开启) 特性，则 CheckNodeCondition、CheckNodeMemoryPressure、CheckNodeDiskPressure、CheckNodePIDPressure 预选策略则会被禁用，PodToleratesNodeNoExecuteTaints、CheckNodeUnschedulable 则会启用。
K8S Scheduler 提供的优选策略
在 Scheduler 中，可选的优选策略包括：
如果开启了 ResourceLimitsPriorityFunction(默认不开启) 特性，则 ResourceLimitsPriority 会被启用。
如何扩展 K8S SchedulerScheduler
内置的策略在大多数场景下可以满足要求，但是在一些特殊场景下，不能满足复杂的调度需求，我们可以通过扩展程序对 Scheduler 进行扩展。
扩展后的 Scheduler 会在调用内置预选策略和优选策略之后通过 HTTP 协议调用扩展程序再次进行预选和优选，最后选择一个合适的 Node 进行 Pod 的调度。调度流程如下：
如何实现自己的 Scheduler 扩展
编写扩展程序
扩展程序本质上是一个 HTTP 服务，可以对 Node 进行筛选和打分，这里只是一个例子，未做任何修改，可以根据实际业务调度场景修改你的预选逻辑和优选逻辑，然后打包成镜像并部署。
接收 HTTP 请求，并根据 URL 的不同，调用预选或优选函数：
func (e *Extender) serveHTTP(w http.ResponseWriter, req *http.Request) { if strings.Contains(req.URL.Path, filter) { e.processFilterRequest(w, req) } else if strings.Contains(req.URL.Path, prioritize) { e.processPrioritizeRequest(w, req) } else { http.Error(w, "Unsupported request", http.StatusNotFound) }}
复制代码
预选逻辑：
func (e *Extender) processFilterRequest(w http.ResponseWriter, req *http.Request) { decoder := json.NewDecoder(req.Body) defer func() { if err := req.Body.Close(); err != nil { glog.Errorf("Error closing decoder") } }() encoder := json.NewEncoder(w)
var args schedulerApi.ExtenderArgs if err := decoder.Decode(&args); err != nil { glog.Errorf("Error decoding filter request: %v", err) http.Error(w, "Decode error", http.StatusBadRequest) return }
// Your logic pod := args.Pod nodes := args.Nodes.Items
response := &schedulerApi.ExtenderFilterResult{ Nodes: &v1.NodeList{ Items: nodes, }, } if err := encoder.Encode(response); err != nil { glog.Errorf("Error encoding filter response: %+v : %v", response, err) }}
复制代码
优选逻辑：
func (e *Extender) processPrioritizeRequest(w http.ResponseWriter, req *http.Request) { decoder := json.NewDecoder(req.Body) defer func() { if err := req.Body.Close(); err != nil { glog.Fatalf("Error closing decoder") } }() encoder := json.NewEncoder(w)
var args schedulerApi.ExtenderArgs if err := decoder.Decode(&args); err != nil { glog.Errorf("Error decoding prioritize request: %v", err) http.Error(w, "Decode error", http.StatusBadRequest) return }
// Your logic for _, node := range args.Nodes.Items { hostPriority := schedulerApi.HostPriority{Host: node.Name, Score: 1} respList = append(respList, hostPriority) }
if err := encoder.Encode(respList); err != nil { glog.Errorf("Failed to encode response: %v", err) }}
复制代码
部署新的 Scheduler
由于 Kubernetes 集群内已经有了一个名为 default-scheduler 的默认调度器，为了不影响集群正常调度功能，一般需要创建一个新的调度器，这个调度器和 default-scheduler 除了启动参数不一样外，镜像并无差别，下面是部署的过程，只列出了重要部分：
创建 Scheduler 配置
我们以 ConfigMap 的方式创建 Scheduler 调度配置，配置文件中需要指定内置的预选策略和优选策略，还有我们编写的扩展程序。
apiVersion: v1kind: ConfigMapmetadata: name: yrcloudfile-scheduler-config namespace: yanrongyundata: policy.cfg: |- { "kind": "Policy", "apiVersion": "v1", "predicates": [], "priorities": [], "extenders": [ { "urlPrefix": "http://yrcloudfile-extender-service.yanrongyun.svc.cluster.local:8099", "apiVersion": "v1beta1", "filterVerb": "filter", "prioritizeVerb": "prioritize", "weight": 5, "enableHttps": false, "nodeCacheCapable": false } ] }
复制代码
部署 Scheduler
部署 Scheduler 的时候需要将 policy-configmap 指定为我们之前创建的 ConfigMap，还需要为 Scheduler 起一个名字，通过 scheduler-name 参数指定，这里我们设置为 yrcloudfile-scheduler。
apiVersion: apps/v1beta1kind: Deploymentmetadata: labels: component: scheduler tier: control-plane name: yrcloudflie-scheduler namespace: yanrongyun initializers: pending: []spec: replicas: 3 template: metadata: labels: component: scheduler tier: control-plane name: yrcloudflie-scheduler spec: containers: - command: - /usr/local/bin/kube-scheduler - --address=0.0.0.0 - --leader-elect=true - --scheduler-name=yrcloudfile-scheduler - --policy-configmap=yrcloudfile-scheduler-config - --policy-configmap-namespace=yanrongyun - --lock-object-name=yrcloudfile-scheduler image: k8s.gcr.io/kube-scheduler:v1.13.0 livenessProbe: httpGet: path: /healthz port: 10251 initialDelaySeconds: 15 name: yrcloudflie-scheduler readinessProbe: httpGet: path: /healthz port: 10251 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "name" operator: In values: - yrcloudflie-scheduler topologyKey: "kubernetes.io/hostname" hostPID: false serviceAccountName: yrcloudflie-scheduler-account
复制代码
如何使用新的 Scheduler
Scheduler 部署成功之后，我们怎么去使用它呢，其实很简单，只需要在部署 Pod 的时候新增 schedulerName 为 yrcloudfile-scheduler 即可。
apiVersion: apps/v1kind: Deploymentmetadata: name: busybox labels: app: busyboxspec: replicas: 1 selector: matchLabels: app: busybox template: metadata: labels: app: busybox spec: schedulerName: yrcloudfile-scheduler containers: - image: busybox imagePullPolicy: IfNotPresent name: busybox
复制代码
YRCloudFile 扩展的 K8S Scheduler
在焱融云最新发布的 YRCloudFile 6.0 版本中，新增了对 CSI 故障动态感知的功能，这个功能就是通过扩展 Scheduler 实现的。
在使用 default-scheduler 的情况下，如果 Work Node 的存储集群连接中断， Kubernetes 并不能感知到这种故障，仍然会将 Pod 调度到故障 Node 中，这使得 Kubernetes 会不断重复的做无用的调度，使 Pod 无法正常完成部署，影响了整个集群的效能。
如图所示，我们部署了 3 副本的 busybox 容器，并且 node-3.yr 节点和存储存在连接故障，该节点上的 Pod 一直保持在 ContainerCreating 状态，无法创建成功；
查看该 Pod 的事件列表可以发现 Kubernetes 的默认调度器把 Pod 调度到了 node-3.yr 故障节点，导致 PV 挂载超时；
焱融云针对以上问题通过扩展 Scheduler 和部署 CSI NodePlugin Sidecar 容器，检查 Node 和存储集群的连接是否健康，在 Scheduler 预选的时候会调用 NodePlugin Sidecar 容器检查存储连接状态，如果连接状态不健康，会过滤掉该 Node，从而避免 Kubernetes 把有状态 Pod 调度到故障 Node。
我们修改 YAML 文件，指定 spec.schedulerName 为 yrcloudfile-scheduler，重新部署结果如图所示：
Pod 已经创建成功，并且没有部署到 node-3.yr 故障节点上，查看 Pod 事件列表可以发现，调度器已经不是 Kubernetes 的默认调度器了，而是 yrcloudfile-scheduler。
容器存储——远不止支持 K8S 那么简单
随着容器、Kubernetes 以及云原生技术的广泛使用，容器存储的关注度日渐提高，容器存储也成为软件定义存储新的制高点。然而，优秀的容器存储，远不止支持容器持久化应用，完成数据保存那么简单，如果对数据进行更好的治理，如何与容器的生态进行深度的整合，还大有可为，焱融云会在容器场景上不断深挖，努力为用户带来更卓越的数据存储服务。
评论