Kubernetes 是通过 List-Watch **** 的机制进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦
用户是通过 kubectl 根据配置文件，向 APIServer 发送命令，在 Node 节点上面建立 Pod 和 Container。
APIServer 经过 API 调用，权限控制，调用资源和存储资源的过程，实际上还没有真正开始部署应用。这里 需要 Controller Manager、Scheduler 和 kubelet 的协助才能完成整个部署过程
Pod 是 Kubernetes 的基础单元，Pod 启动典型创建过程如下
- 这里有三个 List-Watch，分别是 Controller Manager（运行在 Master），Scheduler（运行在 Master），kubelet（运行在 Node）。 他们在进程已启动就会监听（Watch）APIServer 发出来的事件。
- 用户通过 kubectl 或其他 API 客户端提交请求给 APIServer 来建立一个 Pod 对象副本。
- APIServer 尝试着将 Pod 对象的相关元信息存入 etcd 中，待写入操作执行完成，APIServer 即会返回确认信息至客户端。
- 当 etcd 接受创建 Pod 信息以后，会发送一个 Create 事件给 APIServer。
- 由于 Controller Manager 一直在监听（Watch，通过https的6443端口）APIServer 中的事件。此时 APIServer 接受到了 Create 事件，又会发送给 Controller Manager。
- Controller Manager 在接到 Create 事件以后，调用其中的 Replication Controller 来保证 Node 上面需要创建的副本数量。一旦副本数量少于 RC 中定义的数量，RC 会自动创建副本。总之它是保证副本数量的 Controller（PS：扩容缩容的担当）。
- 在 Controller Manager 创建 Pod 副本以后，APIServer 会在 etcd 中记录这个 Pod 的详细信息。例如 Pod 的副本数，Container 的内容是什么。
- 同样的 etcd 会将创建 Pod 的信息通过事件发送给 APIServer。
- 由于 Scheduler 在监听（Watch）APIServer，并且它在系统中起到了“承上启下”的作用，“承上”是指它负责接收创建的 Pod 事件，为其安排 Node；“启下”是指安置工作完成后，Node 上的 kubelet 进程会接管后继工作，负责 Pod 生命周期中的“下半生”。 换句话说，Scheduler 的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上。
- Scheduler 调度完毕以后会更新 Pod 的信息，此时的信息更加丰富了。除了知道 Pod 的副本数量，副本内容。还知道部署到哪个 Node 上面了。并将上面的 Pod 信息更新至 API Server，由 APIServer 更新至 etcd 中，保存起来。
- etcd 将更新成功的事件发送给 APIServer，APIServer 也开始反映此 Pod 对象的调度结果。
- kubelet 是在 Node 上面运行的进程，它也通过 List-Watch 的方式监听（Watch，通过https的6443端口）APIServer 发送的 Pod 更新的事件。kubelet 会尝试在当前节点上调用 Docker 启动容器，并将 Pod 以及容器的结果状态回送至 APIServer。
- APIServer 将 Pod 状态信息存入 etcd 中。在 etcd 确认写入操作成功完成后，APIServer将确认信息发送至相关的 kubelet，事件将通过它被接受
【注：在创建 Pod 的工作就已经完成了后，为什么 kubelet 还要一直监听呢？原因很简单，假设这个时候 kubectl 发命令，要扩充 Pod 副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的 Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化，但是其中的镜像文件升级了，kubelet 也会自动获取最新的镜像文件并且加载】
Predicate 有一系列的常见的调度算法可以使用:
-
PodFitsResources
节点上剩余的资源是否大于 pod 请求的资源nodeName，检查节点名称是否和 NodeName 匹配
-
PodFitsHost：
如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配
-
PodFitsHostPorts
节点上已经使用的 port 是否和 pod 申请的 port 冲突。
-
PodSelectorMatches
过滤掉和 pod 指定的 label 不匹配的节点。
-
NoDiskConflict
已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读。
如果在 predicate 过程中没有合适的节点，pod 会一直在 pending 状态，不断重试调度，直到有节点满足条件。 经过这个步骤，如果有多个节点满足条件，就继续 priorities 过程: 按照优先级大小对节点排序
优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重(该项的重要性)。有一系列的常见的优先级选项包括：
-
LeastRequestedPriority
通过计算CPU和Memory的使用率来决定权重，使用率越低权重越高。也就是说，这个优先级指标倾向于资源使用比例更低的节点
-
BalancedResourceAllocation
节点上 CPU 和 Memory 使用率越接近，权重越高。这个一般和上面的一起使用，不单独使用
-
ImageLocalityPriority
倾向于已经有要使用镜像的节点，镜像总大小值越人，权重越高
实例：
实例2、
给对应的 node 设置标签分别为 kgc=a 和 kgc=b，并查看
kubectl label nodes node01 kgc=a
kubectl label nodes node02 kgc=b
查看：kubectl get nodes --show-labels
查看详细事件 可以发现要先经过 scheduler 调度分配
修改一个 label 的值，需要加上 --overwrite 参数
kubectl label nodes node02 kgc=a --overwrite
删除一个 label，只需在命令行最后指定 label 的 key 名并与一个减号相连即可
kubectl label nodes node02 kgc-
指定标签查询 node 节点
kubectl get node -l kgc=a
亲和性
将 Pod 指派给节点 | Kubernetes你可以约束一个 Pod 以便 限制 其只能在特定的节点上运行， 或优先在特定的节点上运行。有几种方法可以实现这点，推荐的方法都是用 标签选择算符来进行选择。 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上， 而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制 Pod 被部署到哪个节点。例如，确保 Pod 最终落在连接了 SSD 的机器上， 或者将来自两个不同的服务且有大量通信的 Pod 被放置在同一个可用区。你可以使用下列方法中的任何一种来选择 Kubernetes 对特定 Pod 的调度：与节点标签匹配的 nodeSelector 亲和性与反亲和性 nodeName 字段 Pod 拓扑分布约束 节点标签 与很多其他 Kubernetes 对象类似，节点也有标签。 你可以手动地添加标签。 Kubernetes 也会为集群中所有节点添加一些标准的标签。说明： 这些标签的取值是取决于云提供商的，并且是无法在可靠性上给出承诺的。 例如，kubernetes.io/hostname 的取值在某些环境中可能与节点名称相同， 而在其他环境中会取不同的值。 节点隔离/限制 通过为节点添加标签，你可以准备让 Pod 调度到特定节点或节点组上。 你可以使用这个功能来确保特定的 Pod 只能运行在具有一定隔离性、安全性或监管属性的节点上。如果使用标签来实现节点隔离，建议选择节点上的 kubelet 无法修改的标签键。 这可以防止受感染的节点在自身上设置这些标签，进而影响调度器将工作负载调度到受感染的节点。NodeRestriction 准入插件防止 kubelet 使用 node-restriction.kubernetes.io/ 前缀设置或修改标签。要使用该标签前缀进行节点隔离：确保你在使用节点鉴权机制并且已经启用了 NodeRestriction 准入插件。 将带有 node-restriction.kubernetes.io/ 前缀的标签添加到 Node 对象， 然后在节点选择算符中使用这些标签。 例如，example.
https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node/
节点亲和性【不支持拓扑域 】
配置位置： pod.spec.nodeAffinity
软策略：preferredDuringSchedulingIgnoredDuringExecution
硬策略：requiredDuringSchedulingIgnoredDuringExecution
Pod 亲和性【支持拓扑域 】
配置位置：pod.spec.affinity.podAffinity/podAntiAffinity
软策略：preferredDuringSchedulingIgnoredDuringExecution
硬策略：requiredDuringSchedulingIgnoredDuringExecution| 调度策略 | 匹配标签 | 操作符 | 拓扑域支持 | 调度目标 |
| nodeAffinity | 主机 | In, NotIn, Exists,DoesNotExist, Gt, Lt | 否 | 指定主机 |
| podAffinity | Pod | In, NotIn, Exists,DoesNotExist | 是 | Pod与指定Pod同一拓扑域 |
| podAntiAffinity | Pod | In, NotIn, Exists,DoesNotExist | 是 | Pod与指定Pod不在同一拓扑域 |
可以把自己理解成一个Pod，当你去报名兴趣小组，如果你更倾向去张三老师带的班级，把不同老师带的班级当作一个node的话，这个就是节点亲和性。如果你是必须要去张三老师带的班级，这就是硬策略；而你说你想去并且最好能去张三老师带的班级，这就是软策略。
如果你有一个很好的朋友叫李四，你倾向和李四同学在同一个班级，这个就是Pod亲和性。如果你一定要去李四同学在的班级，这就是硬策略；而你说你想去并且最好能去李四同学在的班级，这就是软策略。软策略是不去也可以，硬策略则是不去就不行。
键值运算关系
-
In: label 的值在某个列表中 【状态显示pending】
-
NotIn: label的值不在某个列表中
-
Gt: label 的值大于某个值
-
Lt: label 的值小于某个值
-
Exists:某个label存在
-
DoesNotExist:某个label 不存在
实例1、
硬策略：requiredDuringSchedulingIgnoredDuringExecution
【注：如果硬策略不满足条件，Pod 状态一直会处于 Pending 状态。】
实例2、
软策略： preferredDuringSchedulingIgnoredDuringExecution
【注：把values:的值改成node01，则会优先在node01上创建Pod】
实例 3、
如果把硬策略和软策略合在一起使用，则要先满足硬策略之后才会满足软策略
实例4、
创建一个标签为 app=myapp01 的 Pod
使用 Pod 亲和性调度，创建多个 Pod 资源
使用 Pod 反亲和性调度
【如果节点处于 Pod 所在的同一拓扑域且具有键“app”和值“myapp01”的标签， 则该 pod 不应将其调度到该节点上。 （如果 topologyKey 为 kubernetes.io/hostname，则意味着当节点和具有键 “app”和值“myapp01”的 Pod 处于相同的拓扑域，Pod 不能被调度到该节点上。）】
污点、容忍、驱逐
污点（Taint）：
是一种用于标记Node节点的属性，它会阻止调度器在该节点上创建Pod，一般用在一些特殊节点或者保留节点上，比如Master节点或备份节点等
使用 kubectl taint 命令可以给某个 Node 节点设置污点，Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系，可以让 Node 拒绝 Pod 的调度执行，甚至将 Node 已经存在的 Pod 驱逐出去
当前 taint effect 支持如下三个选项：
- NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
- PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
- NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去
master 就是因为有 NoSchedule 污点，k8s 才不会将 Pod 调度到 master 节点上
命令查看：kubectl describe node master01
#设置污点
kubectl taint node node01 keyl=value1:Noschedule
#节点说明中，查找Taints字段
kubectl describe node rmde-name
#去除污点
kubectl taint node node0l keyl:NoSchedule-
查看 Pod 状态，会发现 node01 上的 Pod 已经被全部驱逐
【注：如果是 Deployment 或者 StatefulSet 资源类型，为了维持副本数量则会在别的 Node 上再创建新的 Pod】
容忍(Tolerations)
用于标记Pod可以在哪些Node节点上调度运行。如果一个节点拥有Pod容忍度中指定的Taints（污点），那么该节点上就可以调度Pod
设置了污点的 Node 将根据 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍(Tolerations)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。
实例、
将 node02也设置污点
在两个 Node 上都设置了污点后，此时 Pod状态将变为 pending
#其中的 key、vaule、effect 都要与 Node 上设置的 taint 保持一致
#operator 的值为 Exists 将会忽略 value 值，即存在即可
#tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间在设置了容忍之后，Pod 创建成功【设置的容忍时间为60s】
注意事项：
（1）当不指定 key 值时，表示容忍所有的污点 key
tolerations:
- operator: "Exists"
（2）当不指定 effect 值时，表示容忍所有的污点作用
tolerations:
- key: "key"
operator: "Exists"
（3）有多个 Master 存在时，防止资源浪费，可以如下设置
kubectl taint node Master-Name node-role.kubernetes.io/master=:PreferNoSchedule
//如果某个 Node 更新升级系统组件，为了防止业务长时间中断，可以先在该 Node 设置 NoExecute 污点，把该 Node 上的 Pod 都驱逐出去
kubectl taint node node01 check=mycheck:NoExecute
//此时如果别的 Node 资源不够用，可临时给 Master 设置 PreferNoSchedule 污点，让 Pod 可在 Master 上临时创建
kubectl taint node master node-role.kubernetes.io/master=:PreferNoSchedule
//待所有 Node 的更新操作都完成后，再去除污点
kubectl taint node node01 check=mycheck:NoExecute-驱逐（Eviction）：
是指将一个无法正常运行的Pod从Node节点中移除。通常情况下，Pod会因为节点故障或以其他原因无法正常工作，此时需要进行驱逐操作
去除污点：
