前情回顾
预算策略：过滤出合适的节点
优选策略：选择部署的节点
nodeName：硬匹配，不走调度策略。node01.
nodeSelector：根据节点的标签选择，会走调度算法。
只要是走调度算法，在不满足预算策略的情况下，所有pod都是pending。
node节点的亲和性：硬策略和软策略
硬策略：必须一定。匹配原则：根据节点的标签
软策略：尽量满足你的要求。
pod的亲和性和反亲和性
| 调度策略 | 匹配标签 | 操作符 | 拓展域 | 调度目标 |
| node亲和性 | 主机标签 | In,NotIn,Exists,DoesExists,Gt,Lt | 不支持 | 指定主机 |
| pod亲和性 | pod的标签 | In（在）,NotIn（不在）,Exists（存在）,DoesExists（不存在） | 支持 | pod和指定标签的pod部署在同一个拓扑域 |
| pod反亲和性 | pod的标签 | In,NotIn,Exists,DoesExists | 支持 | pod和指定标签的pod部署在同一个拓扑域 |
拓扑域：k8s集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分。
可以用来表示节点之间的空间关系，网络关系或者其他类型的关系。
pod内的拓扑域也就是 ---> 标签
pod亲和性演示操作
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx1
spec:
replicas: 1
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- image: nginx:1.22
name: nginx1
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx1
topologyKey: test1
#toplogyKey指定拓扑域的关键字段，表示正在使用test1作为拓扑域的关键字。test1一般都是节点标签，表示希望把pod调度到包含有app标签的Pod，值为nginx1的在test1的拓扑域上的节点。
部署pod时候会遇到pending的情况，是因为指定条件没有一个可以满足！！！！
pod亲和性的软策略展示
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx1
spec:
replicas: 3
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- image: nginx:1.22
name: nginx1
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: DoesNotExist
topologyKey: test3
pod的反亲和性
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx1
name: nginx1
spec:
replicas: 3
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
containers:
- image: nginx:1.22
name: nginx1
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx1
topologyKey: test3
总结：反亲和性顾名思义和亲和性相反，相当于NotIn
注意点：
1.pod的亲和性策略，在配置时，必须要加上拓扑域的关键字
2.pod亲和性的策略也分为硬策略和软策略
3.pod亲和性的notin可以替代反亲和性
4.pod亲和性主要是为了把相关联的pod部署在同一个节点。
k8s中污点和容忍可以配合node的亲和性一块使用
污点与容忍的概念
节点亲和性，是Pod的一种属性（偏好或硬性要求），它使Pod被吸引到一类特定的节点。Taint 则相反，它使节点能够排斥一类特定的 Pod。
污点（Taint） 和 容忍（Toleration） 相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将 toleration 应用于 Pod 上，则表示这些 Pod 可以（但不一定）被调度到具有匹配 taint 的节点上。
当前 taint effect 支持如下三个选项：
●NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
●PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
●NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去
注意点：节点服务器肯定是需要维护的，服务器关机，此时节点上的pod将会失效。在工作中我们主要部署pod的方式控制器部署。尤其是deployment用的最多。一旦节点使用的是驱逐。控制器创建的pod会在其他节点重新部署。所以驱逐的应用场景：资源迁移。
1.所有的pod都会被驱逐，和命名空间无关（包括flannel等），kube-proxy是节点组件，所以他还存在。
2.不论你的创建方式是什么，都会被驱逐
污点的基本操作
格式：kubectl describe nodes <节点名称> | grep Taints
或者是kubectl describe nodes <节点名称> | grep -i taints
eg：查看master01的污点
kubectl describe nodes master01 |grep -i taints
如何设置污点
kubectl taint node node01 key=1:NoSchedule
kubectl taint node node名称 名称
污点的容忍机制
容忍：即使集群上设置了污点，有了容忍机制，依然可以在设置为污点的节点上部署pod。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx2
name: nginx2
spec:
replicas: 1
selector:
matchLabels:
app: nginx2
template:
metadata:
labels:
app: nginx2
spec:
containers:
- image: nginx:1.22
name: nginx2
tolerations:
- key: key
operator: Equal
value: "1"
effect: NoSchedule
容忍策略：容忍节点上的标签key，对应的标签值是1，effect就是对应的污点的类型其他都是NoSchedule，所以无法匹配，就是pending。
污点---NoExcute
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx2
name: nginx2
spec:
replicas: 1
selector:
matchLabels:
app: nginx2
template:
metadata:
labels:
app: nginx2
spec:
containers:
- image: nginx:1.22
name: nginx2
tolerations:
- key: key
operator: Equal
value: "2"
effect: NoExecute
tolerationSeconds: 10
到时间就会销毁，反复循环
特殊情况：NotExecute依然可以部署pod，但是有生命周期，时间一到，pod会被销毁，生命周期结束之后会驱逐一部分pod到其他节点
tolerations: - key: key operator: Exists effect: NoSchedule 指定key的值（节点的标签值），但是不指定污点的类型，所有节点上只要包含了指定的标签名，可以容忍所有的污点 tolerations: - operator: Exists effect: NoSchedule 没有key，不匹配节点的标签，容忍所有污点，但是类型是指定的类型（只要是effect指定的，我都能容忍）
总结：
多个master节点：
kubelet taint node master节点名称 node-role.kubernetes.io/master=PreferNoSchedule
尽量不往master节点上部署pod，但是不是一定的，防止资源浪费。自定义一个标签。
业务维护： node02需要维护两个小时，但是这个业务上还有pod在运行，此时就需要将这个节点的污点设置成NoExecute。
我们部署pod一般都使用deployment部署，会在其他的节点重新部署，并不是被杀死
自主式的pod会被杀死。
一旦节点恢复，一定要把污点驱逐
cordon和drain
cordon：可以直接把节点标记为不可用的状态。
kubectl get node
kubectl cordon master01
kkubectl get node
kubectl uncordon master01
drain
排水，把该节点下的节点全部转移到其他的node节点上运行。
1.一旦执行drain，被执行的节点会变成不可调度状态。
2.会驱逐该节点上的所有pod。
kubectl drain node02 --ignore-daemonsets --delete-local-data --force
drain：排水，标记node节点为不可调度，然后驱逐pod
--ignore-daemonsets：无视daemonsets部署的pod，daemonsets部署的pod还在节点
--delete-local-data：有本地挂载卷的pod会被强制杀死
--force：强制释放不是控制器管理的pod。
还是如何管理和部署pod
