Kubernetes是一项容器编排技术。它是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
架构图：
Kubernetes属于主从分布式架构，主要由Master节点和Node节点组成。Master节点作为控制节点，对集群进行调度管理；Node节点作为真正的工作节点，运行容器。
Kube-Apiserver : 所有服务访问的统一入口，各组件的协调者
Kube-controller-manager : 控制器，主要维护k8s资源对象
Kube-scheduler: 调度器，为 Pod 选择一个 Node 节点
Etcd: 分布式数据库来储存集群中的重要信息，比如 pod、service 等对象信息
pod:pod是一个非常重要的概念。它是k8s的最小的服务单位，可以理解为把一组关系紧密的容器放在一起，它们共享了同一个 Network Namespace，并且可以声明共享一个 Volume。所以，Pod其实是一组共享了某些资源的容器。
Kubelet: 主要来执行关于资源操作的指令，负责pod的维护。比如创建容器、Pod挂载数据卷、获取节点信息和状态等工作。
Kube-proxy: 负责代理服务，在多个pod之间做负载均衡。
Scheduler 是 kubernetes 的调度器，它的主要任务是为新创建出来的pod寻找一个最佳node 节点，听起来非常简单，但有很多要考虑的问题：
- 公平：如何保证每个节点都能被分配资源
- 资源高效利用：集群资源能被最大化的使用
- 效率：调度的性能要好，能够尽快地对大批量的pod完成调度工作
- 灵活：允许用户根据自己的需求控制调度的逻辑
Scheduler 是作为单独的程序运行的，它启动之后会一直监听 API server ，获取Spec.NodeName为空的 pod。调度执行完之后，调度器会将 Pod 对象的 NodeName 字段的值，修改为 Node 的名字，表明 pod 应该放在哪个节点上，这个步骤在 k8s中称为Bind。
调度分为几个部分：首先是过滤掉不满足条件的节点，这个过程称为predicate；然后对通过的节点按照优先级排序，这个是priority；最后从中选出优先级最高的节点作为最终的结果。
Predicate 有一系列算法可以使用，比如：
PodFitResources：节点上剩余的资源是否大于 pod 请求的资源PodFitHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点
如果在 predicate 过程中没有合适的节点，pod 会一直在 pending状态，不断重试调度，直到有节点满足条件；经过这个步骤，如果有多个节点满足条件，就继续 priority过程。
priority 由一系列键值对组成，键是优先级项的名称，值是它的权重。这些优先级包括：
LeastRequestedPriority：通过计算 CPU 和 Memory 的使用率来决定它的权重，换句话说就是选择空闲资源最多的节点BalancedResourceAllocation：节点上的 CPU 和 Memory 使用率越接近，权重越高ImageLocalityPriority：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高
调度的具体过程，如下图
可以看到，Kubernetes 调度器的核心，实际上就是两个相互独立的控制循环。
第一个控制循环称为Imformer Path,它主要目的是启动一系列imformer，来监听 Etcd 中 Pod、Node、Service 等与调度相关的对象的变化。比如当一个待调度 Pod（即：它的 nodeName 字段是空的）被创建出来之后，调度器就会通过 Pod Informer 的 Handler，将这个待调度 Pod 添加进调度队列。
同时，调度器的 informer 还要负责对调度器缓存( scheduler cache）进行更新。Kubernetes 调度部分进行性能优化的一个最根本原则，就是尽最大可能将集群信息 Cache 化，以便从根本上提高 Predicate 和 Priority 调度算法的执行效率。
第二个控制循环称为Scheduling Path，是调度器负责 pod 调度的主循环。这部分的主要逻辑，就是不断地从调度队列里出队一个 Pod。然后，调用 Predicates 算法进行“过滤”。这一步“过滤”得到的一组 Node，就是所有可以运行这个 Pod 的宿主机列表。
接下来，调度器就会再调用 Priorities 算法为上述列表里的 Node 打分，分数从 0 到 10。得分最高的 Node，就会作为这次调度的结果。
当然，上面两个调度算法所需的 node 数据，都是从 Scheduler Cache 里直接拿到的，这是调度器保证算法执行效率的主要手段。
算法执行完后，调度器会执行 Bind 操作，将 Pod 对象的 nodeName 字段的值，修改为上述 Node 的名字。但是，为了不在这个关键调度步骤中远程访问 API server，在 Bind 阶段，调度器只会更新 Scheduler Cache 里的 Pod 和 Node 信息。这种基于“乐观”假设的 API 对象更新方式，在 Kubernetes 里被称作** Assume**。
等 Assume 之后，调度器才会创建一个 Goroutine 来异步向 API server 发起更新 Pod 的请求，来完成真正的 Bind 操作。对应节点的 kubelet 会进行一个 Admit 的操作，再次确认该 pod 能否运行在该节点上。
除了上面所说的，k8s 调度器还有一个重要设计，那就是无锁化。
在 Scheduling Path 上，调度器会启动多个 Goroutine 并发执行 Predicates 算法，从而提高这一阶段的执行效率。而与之类似的，Priorities 算法也会以 MapReduce 的方式并行计算然后再进行汇总。而在这些所有需要并发的路径上，调度器会避免设置任何全局的竞争资源，从而免去了使用锁进行同步带来的巨大的性能损耗。
总结一下，上面介绍了调度的具体过程，以及提升调度效率的三个方法：Cache化、乐观假设、无锁化。
pod.spec.nodeAffinity分为软策略和硬策略
preferredDuringSchedulingIgnoredDuringExecution：软策略requredDuringSchedulingIgnoredDuringExecution：硬策略
当硬亲和性规则不满足时，Pod会置于Pending状态，软亲和性规则不满足时，会选择一个不匹配的节点。
当节点标签改变而不再符合此节点亲和性规则时，不会将Pod从该节点移出，仅对新建的Pod对象生效。
对于软策略，会使用权重 weight 定义优先级，1~100 值越大优先级越高。
apiVersion: v1
kind: Pod
metadata:
name: node-affinity
namespace: test
spec:
containers:
- name: nginx-pod
image: nginx:latest
affinity:
# 节点亲和
nodeAffinity:
# 硬策略，条件必须成立
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
# 要调度到node的标签是kubernetes.io/hostname=node01的节点上
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- node01
# 软策略，条件尽量要成立
preferredDuringSchedulingIgnoredDuringExecution:
# 多个软策略的权重，范围在1-100内，越大计算的得分越高
- weight: 1
preference:
matchExpressions:
# 要调度到node的标签是area=beijing的节点上
- key: area
operator: NotIn
values:
- beijing
键值运算关系：
- In：label 的值在某个列表中
- NotIn：label 的值不在某个列表中
- Gt：label 的值大于某个值
- Lt：label 的值小于某个值
- Exists：某个 label 存在
- DoesNotExist：某个 label 不存在
pod 亲和性主要解决 pod 可以和哪些 pod 部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster、zone 等等），而 pod 反亲和性主要是解决 pod 不能和哪些 pod 部署在同一个拓扑域中的问题，它们都是处理的 pod 与 pod 之间的关系。
同理，pod.spec.affinity.podAffinity/podAntiAffinity也分为软策略和硬策略。
举例：
apiVersion: v1
kind: Pod
metadata:
name: pod-affinity
namespace: test
spec:
containers:
- name: nginx-pod
image: nginx:latest
affinity:
# pod亲和 要求与指定的pod在同一个拓扑域
podAffinity:
# 硬策略
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx01
# 拓扑域（node上的标签key）
topologyKey: kubernetes.io/hostname
# pod亲和 要求与指定的pod不在同一个拓扑域
podAntiAffinity:
# 软策略
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx02
# 拓扑域（node上的标签key）
topologyKey: kubernetes.io/hostname
上面说的节点亲和性，可以理解为 pod 的一种偏好(或者是硬性的)属性，它使得 pod 被吸引到一类特定的节点。Taint(污点)则相反，它使得节点能排斥一类特定的 pod。
Taint 和 Toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点都可以有一个或多个污点，而对于不能容忍这些污点的pod，是不会被该节点接受的。如果将 Toleration 应用于 pod 上，则表示这些 pod 可以(但不要求)被调度到具有匹配 taint 的节点上。
通过kubectl taint命令可以给某一个node节点设置污点，node上设置了污点之后，pod可以拒绝 node 的调度，甚至可以将node上已经存在的pod驱逐出去。
污点可以用于集群节点迁移准备工作，通过打污点来使当前节点上的pod迁移出去。k8s 的master节点自带污点。
污点的组成为：
key = value : effect
每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。当前 taint 的 effect 支持如下三个选项：
NoSchedule：k8s不会把pod调度到该节点上PreferNoSchedule：k8s尽量不会把pod调度到该节点上NoExecute：k8s不会把pod调度到该节点上，同时会把已有节点驱逐出去
# 设置污点
kubectl taint nodes node1 key1=value:NoSchedule
# 去除污点
Kubectl taint nodes node1 key1:NoSchedule-
pod 可以设置容忍，即使 node 有污点，也可以分配。
pod.spec.toleration：
tolerations:
- key: "key1"
operator: " Equal"
value: "value1"
effect: "NoSchedule"
tolerationSeconds: 3600
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"
- key: "key2"
operator: "Exists"
effect: "NoSchedule"
- 其中key，vaule，effect要与Node中设置的taint保持一致
- tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Pod 上继续保留运行的时间
k8s的namespace可以提供资源的逻辑隔离，但是无法提供物理隔离。物理隔离可以通过污点与容忍来实现。
比如想隔离不同产品线的服务，可以提前给 node 打上不同的污点，不同的产品线的pod容忍对应的污点即可。
默认调度器的可扩展机制，在 Kubernetes 里面叫作 Scheduler Framework。这个设计的主要目的，就是在调度器生命周期的各个关键点上，为用户暴露出可以进行扩展和实现的接口，从而实现由用户自定义调度器的能力。
每一个绿色的箭头都是一个可以插入自定义逻辑的接口.比如,上面的 Queue 部分,就意味着你可以在这一部分提供一个自己的调度队列的实现,从而控制每个Pod 开始被调度(出队)的时机。
Predicates部分,则意味着你可以提供自己的过滤算法实现,根据自己的需求,来决定选择哪些机器
上述这些可插拔式逻辑,都是标准的Go语言插件机制(Go plugin 机制),也就是说,你需要在编译的时候选择把哪些插件编译进去。
以上主要介绍了 k8s 集群调度的主要流程、影响调度器调度的几个因素，以及自定义调度器的可拓展设计。