关于云原生:看焱融云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: 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以及云原生技术的宽泛应用，容器存储的关注度日渐进步，容器存储也成为软件定义存储新的制高点。然而，优良的容器存储，远不止反对容器长久化利用，实现数据保留那么简略，如果对数据进行更好的治理，如何与容器的生态进行深度的整合，还大有可为，焱融云会在容器场景上一直深挖，致力为用户带来更卓越的数据存储服务。