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