文章目录
- 前言
- [一、Pod 创建与工作机制流程](#一、Pod 创建与工作机制流程)
-
- [1.1 监听装置](#1.1 监听装置)
- [1.2 pod创建流程](#1.2 pod创建流程)
- 二、Scheduler过程（调度器）
-
- [2.1 调度器的作用](#2.1 调度器的作用)
- [2.2 调度流程](#2.2 调度流程)
-
- [2.2.1 预选](#2.2.1 预选)
- [2.2.2 优选](#2.2.2 优选)
- 三、指定调度节点方式
-
- [3.1 指定调度节点](#3.1 指定调度节点)
-
- [3.1.1 nodeName（强制绑定）](#3.1.1 nodeName（强制绑定）)
- [3.1.2 nodeSelector](#3.1.2 nodeSelector)
- [3.2 节点亲和性](#3.2 节点亲和性)
- [3.3 Pod 亲和性与反亲和性](#3.3 Pod 亲和性与反亲和性)
- [3.3.1 Pod 亲和性调度](#3.3.1 Pod 亲和性调度)
- [3.3.2 反亲和性](#3.3.2 反亲和性)
- [四、 污点和容忍](#四、 污点和容忍)
-
- [4.1 污点](#4.1 污点)
- [4.2 容忍](#4.2 容忍)
- 五、节点维护操作
- [六、Pod 生命周期](#六、Pod 生命周期)
- 总结
前言
本文重点讲解集群讲解，包括pod创建的流程、调度器的工作原理和流程以及如何设置污点容忍等知识点。
一、Pod 创建与工作机制流程
1.1 监听装置
三大组件启动监听（List-Watch）
Controller Manager、Scheduler、kubelet
启动后会分别通过 Watch API Server（HTTPS 6443 端口）监听集群资源事件变化。
1、Controller Manager：监听副本控制类对象（如 ReplicaSet、Deployment）
2、Scheduler：监听未调度的 Pod
3、kubelet：监听分配到本节点的 Pod
1.2 pod创建流程
一、 客户端通过kubectl命令工具向apiserver发送命令创建pod
二、 apiserver将命令信息传入etcd
三、 apiserver收到信息后向control manager发送创建pod的信息
四、 Controller Manager 通过 Watch 机制收到 API Server 发出的 Pod 创建事件并创建pod
五、 调度器通过 Watch 机制收到API Server发出的创建pod事件，通过预选、优选的方式挑选node节点资源更多的节点存放pod
六、 Scheduler 将选定的 Node 信息写回到 API Server，API Server 更新 etcd 中该 Pod 的 Node 绑定信息。
七、 etcd 更新成功后向 API Server 返回确认，API Server 同步 Pod 的最新状态。
八、 kubectl通过watch机制收到API Server发出的创建pod事件，并开始实时监听pod，并定时将pod信息发送给apiserver。
九、 apiserver收到最新的pod信息之后会把信息传入etcd。
二、Scheduler过程（调度器）
2.1 调度器的作用
特点
1、公平性：节点间资源分配均衡
2、高效性：集群所有资源最大化被使用
3、效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作
4、灵活性：允许自定义策略（调度策略、插件）
定义：Sheduler 是作为单独的程序运行的，启动之后会一直监听 APIServer，获取 spec.nodeName 为空的pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上。
2.2 调度流程
调度器通过预选、优选的方式将pod调度到node节点上。（先预选再优选）
2.2.1 预选
简单来说就是，检查node节点的资源够不够存放pod，端口是否有冲突的pod存在，挂载点是否有冲突的存在，如果条件都满足就预选通过，相当于初选通过。
2.2.2 优选
预选过了的node再进行优选，优选的标准主要有资源使用率，cpu与内存使用率占比相近，节点上是否有相同镜像。
资源使用率：假如一个node节点有5g内存，已经用了2g和另一台node节点有3g内存用了2g，经过优选之后会选择前者，因为前者的内存剩余更多，资源使用率更低。
cpu与内存使用率：一个node节点的cpu与内存比为20:20，另一台node节点的cpu与内存比为10:25，经过优选会选择前者，因为前者cpu与内存占比更相近。
镜像：优选节点上已有要拉取的镜像
三、指定调度节点方式
3.1 指定调度节点
3.1.1 nodeName（强制绑定）
pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上，会跳过 Scheduler 的调度策略，该匹
配规则是强制匹配。
3.1.2 nodeSelector
pod.spec.nodeSelector：通过 kubernetes 的 label-selector 机制选择节点，由调度器调度策略匹配 label，然后调度 Pod 到目标节点，该匹配规则属于强制约束。（会强制绑定到有对应标签的node节点上）
kubectl label nodes node1 yjs=a ------------------------------------给node1节点打上yjs=a的标签
3.2 节点亲和性
节点亲和的调度方式有硬策略和软策略。
例如：（硬策略与软策略都指向node1节点）
硬策略（必须去node1节点，如果node1节点资源不足够容纳pod，pod将会一直处于pending状态）
软策略（优先选择node1节点，如果node1节点资源不足，可以选择node2节点）
硬策略优先级大于软策略，如果硬策略和软策略同时存在，优先硬策略
这里我们先来测试软策略：
实验原理：创建pod时指定没有的标签，看是否创建
硬策略实验：
实验原理：创建pod时指定没有的标签，看是否创建
3.3 Pod 亲和性与反亲和性
假设：pod1亲和pod2，那么pod1将调度在pod2所在的node节点，这种用法一般是配置环境容器等辅助容器跟随应用容器。
3.3.1 Pod 亲和性调度
pod亲和就是根据亲和标签选择亲和的pod容器，最后调度到亲和pod所在的node节点。
案例：
第一步 给两个节点都创建yjs标签，方便之后验证
第二步 先创建一个pod，并设定好标签，
第三步 创建第二个pod容器，并且指定亲和pod1
3.3.2 反亲和性
反亲和顾名思义就是通过标签选出不亲和的pod，最后不调度到不亲和的pod所在的node节点。
案例：（步骤一样）
第一步 创建第一个pod
（这里直接用前面的nginx-xjy1）
第二步 创建第二个pod（反亲和规则）
四、 污点和容忍
4.1 污点
节点亲和性，是Pod的一种属性（偏好或硬性要求），它使Pod被吸引到一类特定的节点。Taint则相反，它使节点能够排斥一类特定的 Pod。
Taint 和 Toleration 相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将toleration 应用于 Pod 上，则表示这些 Pod 可以（但不一定）被调度到具有匹配 taint 的节点上。
使用 kubectl taint 命令可以 给某个 Node 节点设置污点，Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系，可以让 Node 拒绝 Pod 的调度执行，甚至将 Node 已经存在的 Pod 驱逐出去。
总而言之：就是将该节点的可调用变为不可调用，不允许其它pod再调度到该容器上，如果用硬策略使pod创建在有污点的node节点，pod会一直处于pending状态。
污点的设置有三种类型
kubectl taint node 节点名 标签：污点类型 ------------------------------设置污点
kubectl describe node 节点名字 ------------------------------可以查看节点污点
案例：
第一步 给节点创建污点
这里已经设置完成
第二步 尝试用硬策略将pod创建在污染node上（看看是否pod会变为pending状态）
4.2 容忍
设置了污点的 Node 将根据 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍(Tolerations)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。
案例：
第一步 设置污点
这一步在前面做过，就不多做了。
第二步 设置容忍并尝试创建pod
五、节点维护操作
六、Pod 生命周期
Pending：表示APIServer创建了Pod资源对象并已经存入了etcd中，但是它并未被调度完成（比如还没有调度到某台node上），或者仍然处于从仓库下载镜像的过程中。
Running：Pod已经被调度到某节点之上，并且Pod中所有容器都已经被kubelet创建。至少有一个容器正在运行，或者正处于启动或者重启状态（也就是说Running状态下的Pod不一定能被正常访问）。
Succeeded：有些pod不是长久运行的，比如job、cronjob，一段时间后Pod中的所有容器都被成功终止，并且不会再重启。需要反馈任务执行的结果。
Failed：Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止，比如 command 写的有问题。
Unknown：表示无法读取 Pod 状态，通常是 kube-controller-manager 无法与 Pod 通信。
总结
本文重点讲解集群讲解，包括pod创建的流程、调度器的工作原理和流程以及如何设置污点容忍等知识点。希望本文内容对您有所帮助，谢谢观看😜