一、Kubernetes的list-watch机制
1、List-watch
K8S集群中，通过List-watch机制进行每个组件的协作，保持数据同步。这种设计可以实现每个组件之间的解耦
kubectl配置文件，统一向集群内部apiserver发送命令——通过apiserver把命令发送到各个组件
创建成功之后，kubectl get pod，kubectl describe pod nginx查看信息——在ETCD数据库中
List-watch会在每一步把监听的消息（apiserver:6443）——组件controller-manager、schedule、kubelet、ETCD都会监听apiserver的6443端口
2、创建pod的过程：
1、客户端向apiserver发送创建创建pod的请求，然后apiserver将请求信息存入到ETCD中
2、存入完之后，ETCD会通过apiserver发送创建pod资源的事件
3、controller-manager通过List-watch机制监听apiserver发送出来的事件，并创建相关的pod资源。创建完成之后，通过apiserver将信息存入到ETCD中
4、ETCD存入更新信息之后，再次通过apiserver发送调度pod资源的事件到scheduler
5、scheduler通过List-watch机制监听到apiserver发出的调度事件，通过调度算法，将pod资源调度到合适的node节点上，调度完成后通过apiserver将调度信息更新到ETCD中
6、ETCD收到更新信息后，再次向apiserver发出的创建pod的事件
7、kubelet通过List-watch机制监听apiserver发出的创建pod的事件，然后根据事件信息，在相应的node节点完成pod的创建
二、scheduler调度的过程和策略：
1、简介
scheduler是K8S集群的调度器，把pod分配到集群的节点
调度规则：
- 公平，每个节点都能够分配资源
- 资源高效利用，集群中的资源可以被最大化使用
- 效率：调度的性能要好，能够尽快的完成大批量pod的调度工作
- 灵活：允许用户根据自己的需求，控制和改变调度的逻辑
scheduler：负责调度资源，把Pod调度到node节点上
有两种策略：预算策略、优选策略
scheduler是一个单独运行的程序，只要启动之后就会一直监听apiserver。获取报文中的字段：spec中的nodeName字段
创建pod时，为每个pod创建一个binding，表示该往哪个节点上部署
创建pod到节点时，有两个策略
先执行预算策略，在执行优先策略。这两步的操作都必须成功，否则立刻返回报错
部署的node必须满足这两个策略，少一个都不行
2、预算策略：predicate
自带一些算法，选择node节点，是scheduler自带的算法策略，不需要人工干预
- podfitsresources：pod的适应策源，检查节点上剩余的资源是否满足pod请求的资源（主要是CPU和内存）
- podfitshost：po适应主机，如果pod指定了node的name，检测主机名是否存在，如果存在要和pod指定的名称匹配，这才能调度过去
- podselectormarches：pod选择器匹配，创建pod的时候，可以根据node'节点的标签来进行匹配。他查找指定的node节点上标签是否存在。存在的标签是否匹配
- nodeskconflict：无磁盘冲突，确保已挂载的卷和pod卷不发生冲突。除非目录是只读
如果预算策略不满足，pod将始终处于pending状态，不断重试调度，直到节点满足条件为止
若三个node节点都满足——>优选策略
3、优先策略：
3.1、leastrequestedpriority：
最低请求优先级，通过算法计算节点上的CPU和内存使用率，确定节点的权重
使用率越低的节点，相应的权重就越高。调度时会更倾向于这些使用率低的节点。实现资源合理的利用
3.2、balanceresourceallocation：
平衡资源分配，算CPU和内存的使用率，给节点赋予权重。权重算的是CPU和内存使用率接近，权重越高。
和上面的最低请求优先级一起使用
举例：
node1 CPU和内存使用率：20 60
node2 CPU和内存使用率：50 50
node2的内存和CPU使用率接近，权重高，会被选择
3.3、imagelocalitypriority：
节点上是否已经有了要部署的镜像。镜像的总数成正比，满足的镜像数越多，权重越好
以上三个策略都是scheduler自带的算法，自动的
4、选择的过程：
先通过预算策略选择出可以部署的节点，在通过优选策略选择出最好的节点，以上都是自带的算法。K8S集群自己来选择
三、kubernetes对Pod的调度策略
在 Kubernetes 中，调度 是指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod。
1）定向调度： 使用 nodeName 字段指定node节点名称；使用 nodeSelector 字段指定node节点的标签；
2）亲和性调度： 使用 节点/Pod 亲和性（NodeAffinity、PodAffinity、PodAntiAffinity）；
3）污点与容忍： 使用 节点设置污点，结合 Pod设置容忍。
4）全自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出；
-
#补充，Pod和node的关系 -
Node 是 Kubernetes 集群中的工作节点 -
一个 Node 可以运行多个 Pod，而一个 Pod 只能运行在一个 Node 上 -
使用标签和选择器可以管理 Node 和 Pod 之间的关系，从而实现灵活的调度和管理。
四、定向调度
1、调度策略简介：
nodeName：指定节点名称，用于将Pod调度到指定的Node上，不经过调度器。
nodeSelector：在 Pod 定义文件的 spec 下的 nodeSelector 字段中设置一个标签选择器，在 Pod 调度的时候，只有具有这些标签的 Node 才会被考虑用来运行这个 Pod。
2、指定节点：
spec参数设置：
nodeName: node2
指定了节点，在参数中设置了nodeName，指定了节点的名称，会跳过scheduler的调度策略，这个规则是强制匹配
3、指定标签：
spec参数设置：
nodeSelector:
节点自定义标签：
-
kubectl label nodes master01 test1=a -
kubectl label nodes node01 test2=b -
kubectl label nodes node02 test3=c -
kubectl get nodes --show-labels -
#查看节点的标签
指定节点标签部署pod，是要经过scheduler的算法，如果节点不满足条件，pod会进入pending状态。直到节点满足条件为止
五、亲和性调度：
1、介绍：
两种亲和性：节点亲和性和pod亲和性
两种策略：软策略和硬策略
node节点的亲和性：
preferredDuringSchedulingIgnoredDuringExecution：软策略
选择node节点时，声明了我最好能部署在node01。如果是软策略，他会尽量满足这个条件，不一定会完全部署在node01节点上。
requiredDuringSchedulinglgnoredDuringExecution：硬策略
选择pod时，声明了部署在node1上。如果是硬策略，必须满足硬策略的条件，必须部署在node1上。强制性要求
pod的亲和性：
preferredDuringSchedulingIgnoredDuringExecution：软策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是，也可以不是，尽量满足
requiredDuringSchedulingIgnoredDuringExecution：硬策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上，强制性满足
2、键值的运算关系：
都是根据标签来选择node或者pod的亲和性
- In（大写的i）：在，选择的标签值在node节点上存在
- Notin：不在，选择label的值不在node节点上
- Gt：大于，要大于选择的标签值，只能比较整数
- Lt：小于，要小于选择的标签值，只能比较整数
- Exists：存在，只是选择标签对象，不考虑值
- DoesNotExist：不存在，选择不具有指定标签的对象。不考虑值
3、node亲和性实例
node亲和性的硬策略：
in策略：
-
apiVersion: apps/v1 -
kind: Deployment -
metadata: -
labels: -
app: nginx -
name: nginx -
spec: -
replicas: 3 -
selector: -
matchLabels: -
app: nginx -
template: -
metadata: -
labels: -
app: nginx -
spec: -
containers: -
- image: nginx:1.22 -
name: nginx -
affinity: -
#选择亲和性部署方式 -
nodeAffinity: -
#选择的是node节点的亲和性 -
requiredDuringSchedulingIgnoredDuringExecution: -
nodeSelectorTerms: -
#选择了亲和性的策略。nodeSelectorTerms你要选择哪个node作为硬策略。匹配的节点标签 -
- matchExpressions: -
#定义了一个符合我要选择的node节点信息 -
- key: test3 -
operator: In -
#指定键值对的算法 -
values: -
- c
硬限制选择test3=c的节点
Notin：
notin，只要不在test3=c的节点，都能够部署
删除节点上的标签：
-
kubectl label nodes master01 test1- -
kubectl label nodes node01 test2- -
kubectl label nodes node02 test3-
更改标签名：
kubectl label nodes node02 memory=1000 --overwriteGt：
-
affinity: -
nodeAffinity: -
requiredDuringSchedulingIgnoredDuringExecution: -
nodeSelectorTerms: -
- matchExpressions: -
- key: memory -
operator: Gt -
values: -
- "612"
大于612节点上部署
Exists：
-
affinity: -
nodeAffinity: -
requiredDuringSchedulingIgnoredDuringExecution: -
nodeSelectorTerms: -
- matchExpressions: -
- key: memory -
operator: Exists -
#指定键值对的算法为Exists或DoesNotExist，不能使用values字段
DoesNotExist：
-
affinity: -
nodeAffinity: -
requiredDuringSchedulingIgnoredDuringExecution: -
nodeSelectorTerms: -
- matchExpressions: -
- key: memory -
operator: DoesNotExist
软策略：
-
affinity: -
nodeAffinity: -
preferredDuringSchedulingIgnoredDuringExecution: -
- weight: 1 -
preference: -
matchExpressions: -
- key: memory -
operator: In -
values: -
- "1000" -
preferredDuringSchedulingIgnoredDuringExecution: -
- weight: 10 -
preference: -
matchExpressions: -
- key: memory -
operator: In -
values: -
- "500"
多个软策略看权重，权重高，执行指定的软策略
硬策略和软策略一起执行：
先满足硬策略，再考虑软策略。若硬策略无法满足，软策略一个都不会执行
面试题：
你在部署pod的时候选择什么样的策略：
根据node的亲和性：
性能不一致，尽量把pod往性能高的多部署，选择软策略
节点故障或者节点维护中，只能选择硬策略，把故障节点剔除
4、pod亲和性实例
4.1、pod的亲和性和反亲和性：
| 调度策略： | 匹配标签 | 操作符 | 拓扑域 | 调度目标 |
| node的亲和性 | 主机标签 | In、NotIn、Exists、DoesNotExist、Gt、Lt | 不支持 | 指定主机 |
| pod的亲和性 | pod的标签 | In、NotIn、Exists、DoesNotExist | 支持 | pod和指定标签的pod部署在同一个拓扑域 |
| pod的反亲和性 | pod的标签 | In、NotIn、Exists、DoesNotExist | 支持 | pod和指定标签的pod部署在不同一个拓扑域 |
4.2、拓扑域：
K8S集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分
可以用来标识节点之间的空间关系，网络关系，或者其他类型的关系
这里pod的亲和性的拓扑域是标签
4.3、pod的亲和性实例：
1、In
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: test1
#topologyKey指定拓扑域的关键字段，表示正在使用test1作为拓扑的关键字。test1一般是节点标签，表示希望吧pod调度到包含有app标签的pod，值为nginx1的在test1的拓扑域上的节点
2、Exists
满足test1节点，且满足pod标签等于app的
-
affinity: -
podAffinity: -
requiredDuringSchedulingIgnoredDuringExecution: -
- labelSelector: -
matchExpressions: -
- key: app -
operator: Exists -
topologyKey: test1
软策略：
表示尽量选择满足不存在app的pod标签的 并且 是满足test1的节点的
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: DoesNotExist
topologyKey: test1
反亲和性：
表示反转，满足哪个就不去哪个
软策略反亲和性：
硬策略反亲和性：
注意点：
- pod的亲和性策略，在配置时，必须要加上拓扑域的关键字topologykey，指向的是节点标签
- pod亲和性的策略分为硬策略和软策略
- pod亲和性的NotIn可以替代反亲和性
- pod亲和性主要是为了把相关联的pod组件部署在同一节点上。lnmp
你在进行部署的时候，怎么考虑node节点：
软硬策略
污点和容忍
污点和容忍可以配合node的亲和性一块使用
污点：是node的调度机制，不是pod
被设为污点的节点，不会部署pod
污点和亲和性相反，亲和性是尽量选择和一定选择
污点的节点一定不被选择？
一、污点
1.查看主节点污点：kubectl describe nodes master
2.污点是什么：一旦节点上有污点的标签，那么调度器在部署pod的时候会避开这些有污点标签的节点。
3.污点的两种格式：
1》key:effect 键值：类型
kubectl taint node node1 test1:effect
2》key=value:effect 键值=值：类型
kubectl taint node node1 test1=1:effect
3.污点的类型：
1》NoSchedule：节点上一旦有这个污点，调度器不会把pod部署到该节点上。
2》PreferNoSchedule：尽量避免把pod部署到该节点。
3》NoExecute:调度器不仅不会把pod部署到该节点，而且会把该节点的pod驱逐到其它节点上。
4.删除污点：
三种污点类型
修改污点类型
二、容忍：k8s第二个机制
1.容忍：即使节点上有污点，调度依然可以把pod部署在有污点的节点上。
2.容忍的类型只有两个 operator: Equal(等于)和Exists（包含）
Equal类型
污点的容忍类型为驱逐NoExecute
tolerationseconds只能和Equal一起使用
Exists类型
只要是指定污点，不管节点key键值是啥都会部署
只要键值key存在，不考虑你是啥污点类型都会部署
三、cordon不可调度：直接标记节点为不可用节点
kubectl cordon node1
四、drain排水（谨慎使用）：标记节点为不可调度，而且会把节点上的pod驱逐到其它节点
--ignore：无视daemonsets的部署的pod
-data：如果被排水的节点上有本地的挂载点，会强制杀死
--force：不是控制器创建的pod会被强制释放
如何恢复
五、面试题
问：当排水和驱逐之后，怎么样能让pod重新回到节点？
回：污点类型放逐必须要取消
kubectl uncordon node1
重启 delete -f
六、关于主节点master一般情况下做为集群的调度器，尽量不部署pod，但是为了资源最大化，master也可以部署，前提是设置污点类型为preferNoschedule；如果集群规模很小，可以直接用来当节点部署。
七、数据卷volum
pod的生命周期是有限的，一旦重启或者崩溃数据就会丢失，为了保证数据的完整，我们要实现pod内的容器和节点进行挂载
1.数据卷类型:
emptyDir存储卷：容器和容器之间挂载；pod分配给节点之前，首先创建emotyDir卷，只要运行在节点，数据卷就会一直存在；这个数据卷不能和宿主机共享，pod内容器之间共享，一旦pod重启，enptyDir卷的数据也会一起删除。主要用于容器内部组件通信，不涉及敏感数据。
hostPath数据卷：每个pod和节点进行挂载，当pod部署到节点时，就会和节点的指定目录进行挂载；数据可以持久化；node节点数据格式化pod数据也就会消失。每个pod运行的数据不同，保留的数据要做分区，所以需要hostPath挂载。
Nfs共享存储卷：整个k8s集群里的pod相当于客户端，另外一台服务器提供Nfs共享；也就是所有pod共享一个挂载点，所有的数据也都在这一个挂载点。用于nginx服务或者pod的数据是一致的。
2.实验：
1》emptyDir：用{}代表
容器1的user/share和容器2 data/目录进行挂载，数据卷类型为emptyDir
进入pod其中一个容器内
2》hostPath数据卷实验
三台共同操作：以节点的数据为主
3》Nfs共享存储卷实验
K8s集群：
192.168.127.44 master1
192.168.127.55 node1
192.168.127.66 node2
192.168.127.36 集群外主机
首先四台主机做IP--主机名的映射
集群外主机创建目录 mkdir /opt/data1
在k8s主节点yaml文件内进行nfs挂载
于集群外主机创建的data1目录下创建文件并查看挂载结果
查看容器内挂载情况
1166
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
