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

K8S Scheduler 是做什么的

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

看焱融云CSI动态感知如何扩展Kubernetes Scheduler_第1张图片

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

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

经过预选筛选和优选打分之后,K8S选择分数最高的 Node 来运行 Pod,如果最终有多个 Node 的分数最高,那么 Scheduler 将从当中随机选择一个 Node 来运行 Pod。

K8S Scheduler 提供的预选策略

在 Scheduler 中,可选的预选策略包括:

看焱融云CSI动态感知如何扩展Kubernetes Scheduler_第2张图片

如果开启了 TaintNodesByCondition(从 1.12 开始为 beta级别,默认开启) 特性,则 CheckNodeCondition、CheckNodeMemoryPressure、CheckNodeDiskPressure、CheckNodePIDPressure 预选策略则会被禁用,PodToleratesNodeNoExecuteTaints、CheckNodeUnschedulable 则会启用。

K8S Scheduler 提供的优选策略

在 Scheduler 中,可选的优选策略包括:

看焱融云CSI动态感知如何扩展Kubernetes Scheduler_第3张图片

如果开启了 ResourceLimitsPriorityFunction(默认不开启) 特性,则 ResourceLimitsPriority 会被启用。

如何扩展 K8S SchedulerScheduler

内置的策略在大多数场景下可以满足要求,但是在一些特殊场景下,不能满足复杂的调度需求,我们可以通过扩展程序对 Scheduler 进行扩展。

扩展后的 Scheduler 会在调用内置预选策略和优选策略之后通过 HTTP 协议调用扩展程序再次进行预选和优选,最后选择一个合适的 Node 进行 Pod 的调度。调度流程如下:

看焱融云CSI动态感知如何扩展Kubernetes Scheduler_第4张图片

如何实现自己的 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以及云原生技术的广泛使用,容器存储的关注度日渐提高,容器存储也成为软件定义存储新的制高点。然而,优秀的容器存储,远不止支持容器持久化应用,完成数据保存那么简单,如果对数据进行更好的治理,如何与容器的生态进行深度的整合,还大有可为,焱融云会在容器场景上不断深挖,努力为用户带来更卓越的数据存储服务。

你可能感兴趣的:(看焱融云CSI动态感知如何扩展Kubernetes Scheduler)