购物网站设计需要哪些模块,搜索引擎营销漏斗模型,网站开发重庆,wordpress 项目schedule的调度算法
预算策略
过滤出合适的节点
优先策略
选择部署的节点
nodeName:硬匹配#xff0c;不走调度策略。node01.
nodeSelector: 根据节点的标签选择#xff0c;会走调度的算法。
只要是走调度算法#xff0c;在不满足预算策略的情况下#xff0c;所有po…schedule的调度算法
预算策略
过滤出合适的节点
优先策略
选择部署的节点
nodeName:硬匹配不走调度策略。node01.
nodeSelector: 根据节点的标签选择会走调度的算法。
只要是走调度算法在不满足预算策略的情况下所有pod都是pending。
node节点的亲和性:
硬策略必须满足的条件。匹配原则也是根据节点的标签
软策略尽量满足要求不是一定满足
pod的亲和性和反亲和性 调度策略 匹配标签 操作符 拓扑域 调度目标 node的亲和性 主机标签 In/Notin/Exists/DoesNotExists/Gt/Lt 不支持 指定主机 pod的亲和性 pod的标签 In/Notin/Exists/DoesNotExists 支持 pod和指定标签的pod部署在同一拓扑域 pod的反亲和性 pod的标签 In/Notin/Exists/DoesNotExists 支持 pod和指定标签的pod部署不在同一拓扑域 拓扑域k8s集群节点当中的一个组织结构可以根据节点的物理关系或者逻辑关系进行划分可以用来表示节点之间的空间关系网络关系或者其他类型的关系。标签。主机标签。
pod
node1 node2 node3
nginx1 nginx2 nginx3
app1 app1 app1
app1 app2 app2 app3 app3 app4 topologyKey指定拓扑域的关键字段表示正在使用test1作为拓扑域的关键字。test1一般是节点标签表示希望把pod调度到包含有app标签的pod值为nginx1的在test1的拓扑域上的节点。 注意点
1、pod的亲和性策略在配置时必须要加上拓扑域的关键字topologyKey指向的是节点标签
2、pod亲和性的策略分为硬策略和软策略
3、pod亲和性的notin可以替代反亲和性
4、pod亲和性把相关联的pod组件部署在同一节点 你在进行部署时怎么考虑node节点
软硬策略、污点和容忍
污点和容忍可以配合node的亲和性一块使用
污点是node的调度机制不是pod
被设置为污点的节点不会部署pod
污点和亲和性相反亲和性是尽量或者一定选择。
污点的节点一定不被选择真否答案如下
taint三种
1、NoScheduler
k8s不会把pod调度到这个节点上
2、PreferNoSchedule
如果污点类型是这个那么就是尽量避免把pod部署在该节点上而不是一定(master节点的污点就是这个)
3、NoExecute
如果污点类型是这个那么K8S会把这个节点上的pod全部驱逐出去而且不会调度到这个节点
基于控制器创建的pod虽然被驱逐但是会在其他节点重新部署
自主pod会被直接杀死 ** 注意点节点服务器需要维护的服务器关机节点上pod将会失效在工作中我们主要部署pod的方式控制器部署。deployment最多的。一旦节点设置为驱逐控制器创建的pod会在其他节点重新部署。
所有的pod都会被驱逐和命名空间无关。所有的一切都会被驱逐
不论你的创建方式是什么都会被驱逐
系统集群组件不会被驱逐 ** 容忍即使节点上设置了污点有了容忍机制依然可以在设置为污点的节点上部署pod
特殊情况: NOExecute依然可以部pod,但是有生命周期时间一到pod会被销毁,生命周期结束之后会驱逐一部分pod到其他节点。
*有的节点还是会保留在污点节点上。
该节点维护完毕测试一下节点的工作是否正常
tolerations:
- key: key
operator : Exists
指定key的值指标节点的标签值但是不指定污点的类型那么所有节点上只要包含了这个指定的标签名可以容忍所有的污点 tolerations:
- operator: Exists
- effect: Noschedule
没有key,不匹配节点标签容忍所有污点但是类型是指定的类型 node的亲和性
pod的亲和性和反亲和性
污点和容忍
如何选择node节点部署pod.
选择一个期望的节点来部署pod 多个master节点
kubectl taint node master书点名称 node-role.kubernetesio/master:PreferNoSchedule
尽量不往master节点上部署pod,但是不是一定的。防止资源浪费。也可以自定义标签 业务维护
node02需要维护2个小时。但是这个节点还有业务pod在运行。就需要把这个节点的污点设置为NoExcute
我们部署pod一般都使用deployment部署会在其他的重新部署并不是被杀死。自主式的pod会被杀死。
一旦节点恢复一定要把污点去除 cordon和drain
cordon:可以直接把节点标记为不可用状态
drain: 排水。把该节点下的pod全部转移到其他的node节点上运行
1、一旦执行drain之后被执行的节点会变成不可调度状态
2、会驱逐该节点上的所有pod kubectl drain node02 --ignore-daemonsets --delete-local-data --force
drain为不可调度然后驱逐pod
--ignore-daemonsets无视daemonsets部署的pod,一并驱逐
--delete-local-data有本地挂载卷的pod会被强制杀死
--force强制释放不是控制器管理的pod
还是如何来管理和部署pod pod的亲和性和反亲和性
污点驱逐
NoExecute
cordon
drain
-ignore-daemonsets daemonset部罢的一股是重要后台运行的系统pod。所以不动。 node亲和性 软硬策略
pod亲和性
pod反亲和性
污点 NoExecute
容忍
cordon
drain 如何部署pod是比较重要的集群资源的调度机制合理的配置pod的调度机制可以使资源最大化利用
