看焱融云CSI动态感知如何扩展Kubernetes Scheduler

K8S Scheduler 是做什么的

Kubernetes Scheduler 的作用是将待调度的 Pod 按照一定的调度算法和策略绑定到集群中一个合适的 Worker Node（以下简称 Node）上，并将绑定信息写入到 etcd 中，之后目标 Node 中 kubelet 服务通过 API Server 监听到 Scheduler 产生的 Pod 绑定事件获取 Pod 信息，然后下载镜像启动容器，调度流程如图所示：

Scheduler 提供的调度流程分为预选 (Predicates) 和优选 (Priorities) 两个步骤：

预选，K8S会遍历当前集群中的所有 Node，筛选出其中符合要求的 Node 作为候选
优选，K8S将对候选的 Node 进行打分

经过预选筛选和优选打分之后，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: v1
kind: ConfigMap
metadata:
  name: yrcloudfile-scheduler-config
  namespace: yanrongyun
data:
  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/v1beta1
kind: Deployment
metadata:
  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/v1
kind: Deployment
metadata:
  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以及云原生技术的广泛使用，容器存储的关注度日渐提高，容器存储也成为软件定义存储新的制高点。然而，优秀的容器存储，远不止支持容器持久化应用，完成数据保存那么简单，如果对数据进行更好的治理，如何与容器的生态进行深度的整合，还大有可为，焱融云会在容器场景上不断深挖，努力为用户带来更卓越的数据存储服务。