前情回顾
预算策略:过滤出合适的节点
优选策略:选择部署的节点
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,被执行的节点会变成不可调度状态。文章来源:https://www.toymoban.com/news/detail-825260.html
2.会驱逐该节点上的所有pod。文章来源地址https://www.toymoban.com/news/detail-825260.html
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
到了这里,关于k8s的集群调度---下的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!