`kube-scheduler`的职责主要有以下 3 个:
1. 集群高可用
`kube-scheduler`可以设置`leader-elect`启动参数,这样会通过`etcd`进行节点选主。`kube-scheduler`和`kube-controller-manager`都使用了一主多从的高可用方案。简单理解的话是这样的:`kube-scheduler`启动时,会在`etcd`中创建 endpoint,endpoint 的信息中记录了当前的 leader 节点信息,以及上次更新时间。leader 节点会定期更新 endpoint 的信息,维护自己的 leader 身份,每个从节点的服务都会定期检查 endpoint 的信息,如果 endpoint 的信息在规定的时间范围内没有更新,从节点将会尝试更新自己的 leader 节点。
2. 调度资源监听
通过 Watch 机制监听`kube-apiserver`上资源(Pod 和 Node)的变化。
`kube-apiserver`给其它的组件(比如:`kubelet`、`kube-controller-manager`、`kube-scheduler`)等提供了一套`Watch`机制用于监控各种资源的变化,类似于消息中间件的发布-订阅模式(Push),这样`kube-apiserver`可以主动通知这些组件。
`kube-apiserver`初始化时,会建立对 etcd 的连接并 watch etcd。当`kube-scheduler`客户端调用`Watch API`时,`kube-apiserver`内部会建立一个 WatchServer,WatchServer 会从`etcd`中获取资源的`Watch event`,`Watch event`经过加工过滤后就会发送给客户端,`Watch API`本质上是一个 GET 请求,通常有两种实现模式:通过`websocket`协议发送;或是通过`Transfer-Encoding=chunked`方式建立长连接。
3. 调度节点分配
这个职责也是我们本节点将会重点介绍的部分。调度节点分配分为两个环节:预选(`Predicates`)与优选(`Priorites`)。调度资源监听也是为了这个环节提供数据输入。
* 预选:遍历所有目标 Node,根据配置的预选策略`Predicates Policies`过滤掉不符合策略的 Node,剩下符合要求的候选节点。预选的输出将会作为优选的输入。预选策略默认使用的是`DefaultProvider`中定义的`default predicates policies`集合。
* 优选:根据配置的优选策略`Priorites Policies`,为前一步过滤后的 Node 进行打分排名,得分最高的 Node 将作为最适合的 Node,该 Pod 将绑定(Bind)到最适合的 Node 上。如果打分排名后,有多个 Node 并列得分最高,`kube-scheduler`会从中随机选取一个 Node 作为目标 Node。优选策略默认使用的是`DefaultProvider`中定义的`default priorites policies`集合。
`kube-scheduler`调度节点分配需要考虑的问题较多,有:
* 公平:如何保证每个 Node 都能够分配资源
* 资源高效利用:集群所有资源能够被最大化使用
* 效率:调度性能高,能够尽快对大批量的 Pod 完成调度工作
* 灵活:允许用户自定义调度逻辑
`kube-scheduler`官方流程图如下所示:
~~~text
For given pod:
+---------------------------------------------+
| Schedulable nodes: |
| |
| +--------+ +--------+ +--------+ |
| | node 1 | | node 2 | | node 3 | |
| +--------+ +--------+ +--------+ |
| |
+-------------------+-------------------------+
|
|
v
+-------------------+-------------------------+
Pred. filters: node 3 doesn't have enough resource
+-------------------+-------------------------+
|
|
v
+-------------------+-------------------------+
| remaining nodes: |
| +--------+ +--------+ |
| | node 1 | | node 2 | |
| +--------+ +--------+ |
| |
+-------------------+-------------------------+
|
|
v
+-------------------+-------------------------+
Priority function: node 1: p=2
node 2: p=5
+-------------------+-------------------------+
|
|
v
select max{node priority} = node 2
~~~
- Pod 基本用法
- Pod 简介
- 操作 Pod
- 创建 Pod
- 标签
- 标签选择器
- 命名空间
- 删除及更新 Pod
- 副本集(RS)、后台支撑服务集(DaemonSet)、任务(Job)
- 副本集(RS)
- 后台支撑服务集(DaemonSet)
- 任务(Job)
- 使用 ConfigMap 配置应用程序
- ConfigMap 简介
- 创建 ConfigMap 资源对象
- 通过 YAML 配置文件方式创建
- 通过 kubectl 命令行方式创建
- 通过生成器创建 ConfigMap
- 在 Pod 中使用 ConfigMap
- 通过环境变量方式使用 ConfigMap
- 通过卷挂载(volumeMount)方式使用 ConfigMap
- 使用 Secret 传递敏感数据
- Secret 简介
- 默认令牌 Secret
- 创建 Secret
- 使用 kubectl 创建 Secret
- 使用 YAML 文件手动创建 Secret
- 使用生成器创建 Secret
- 使用 Secrets
- 挂载 Secret 到 Pod 中作为卷进行使用
- 使用 Secret 作为环境变量
- 使用镜像拉取 Secret(ImagePullSecrets)
- 多容器 Pod
- 多容器 Pod 简介
- Pod 中容器间的通信
- Pod 容器共享 Volume
- 进程间通信(IPC)
- 容器间网络通信
- Scheduler
- kube-scheduler 简介
- kube-scheduler 职责及调度流程
- 常用参数
- 预选策略(Predicates Policies)
- 优选策略(Priorites Policies)
- 自定义调度器
- 使用 Deployment 进行 Pod 升级回滚
- Deployment 简介
- Deployment 的升级
- 多重更新(Rollover)
- 更新 Deployment 的标签选择器(Label Selector)
- Deployment 的回滚
- Deployment 的暂停与恢复
- Pod 扩容与缩容
- 手动扩缩容
- 自动扩缩容
- 扩缩容算法
- php-apache 自动扩缩容实例
- 配置 HPA
- v1 版本
- v2beta2 版本
- DaemonSet
- DaemonSet 简介
- 运行示例程序
- 滚动更新
- StatefulSet
- StatefulSet 简介
- 运行 nginx 实例
- 扩缩容 StatefulSet
- 更新 StatefulSet
- 删除 StatefulSet
- 非级联删除
- 级联删除
- Pod 管理策略
- Service 基本用法
- Service 简介
- Service 的类型
- 使用命令创建服务
- 使用 YAML 文件创建服务
- Service Discovery
- 环境变量
- DNS
- ClusterIP Service
- ClusterIp Service 简介
- Normal Service
- YAML 文件模板
- 服务负载分发策略 & 多端口服务 & 端口命名
- 一个简单的例子
- Headless Service
- 无 Selector 的服务
- NodePort Service
- NodePort Service 简介及实例
- 扩展:客户端直接访问 Pod
- hostPort
- hostNetwork
- Port Forward
- LoadBalancer与ExternalName
- LoadBalancer Service 简介
- LoadBalancer Service 实例
- 使用 nginx 软件手动实现负载均衡
- 由云服务商提供负载均衡器
- ExternalName Service 简介
- Ingress
- Ingress 简介
- 部署 nginx-ingress-controller
- 部署一个简单的 Nginx 实例
- 不同的 Ingress 策略配置类型
- 配置 Ingress 处理 TLS 传输
