做3d兼职网站,安装完wordpress主题,天津网站建设软件开发招聘,上海网站建站建设服务Kubernetes中的调度策略可以大致分为两种 一种是全局的调度策略#xff0c;要在启动调度器时配置#xff0c;包括kubernetes调度器自带的各种predicates和priorities算法#xff0c;具体可以参看上一篇文章#xff1b; 另一种是运行时调度策略#xff0c;包括nodeAffinity…Kubernetes中的调度策略可以大致分为两种 一种是全局的调度策略要在启动调度器时配置包括kubernetes调度器自带的各种predicates和priorities算法具体可以参看上一篇文章 另一种是运行时调度策略包括nodeAffinity主机亲和性podAffinityPOD亲和性以及podAntiAffinityPOD反亲和性。 nodeAffinity 主要解决POD要部署在哪些主机以及POD不能部署在哪些主机上的问题处理的是POD和主机之间的关系。 podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题拓扑域用主机标签实现可以是单个主机也可以是多个主机组成的cluster、zone等。 podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。 三种亲和性和反亲和性策略的比较如下表所示 策略名称匹配目标支持的操作符支持拓扑域设计目标nodeAffinity主机标签InNotInExistsDoesNotExistGtLt不支持决定Pod可以部署在哪些主机上podAffinityPod标签InNotInExistsDoesNotExist支持决定Pod可以和哪些Pod部署在同一拓扑域PodAntiAffinityPod标签InNotInExistsDoesNotExist支持决定Pod不可以和哪些Pod部署在同一拓扑域亲和性应用A与应用B两个应用频繁交互所以有必要利用亲和性让两个应用的尽可能的靠近甚至在一个node上以减少因网络通信而带来的性能损耗。 反亲和性当应用的采用多副本部署时有必要采用反亲和性让各个应用实例打散分布在各个node上以提高HA。 主要介绍kubernetes的中调度算法中的Node affinity和Pod affinity用法 实际上是对前文提到的优选策略中的NodeAffinityPriority策略和InterPodAffinityPriority策略的具体应用。 kubectl explain pods.spec.affinity 亲和性策略Affinity能够提供比NodeSelector或者Taints更灵活丰富的调度方式例如 丰富的匹配表达式In, NotIn, Exists, DoesNotExist. Gt, and Lt软约束和硬约束Required/Preferred以节点上的其他Pod作为参照物进行调度计算亲和性策略分为NodeAffinityPriority策略和InterPodAffinityPriority策略。 先回顾一下之前的节点选择器 节点选择器 nodeSelector nodeName创建一个Pod 节点选择器标签nodeSelector: disktype: ssd 默认节点没这个标签所以会调度失败 [rootk8s-master schedule]# kubectl get node --show-labels|egrep disktype[rootk8s-master schedule]# kubectl get podsNAME READY STATUS RESTARTS AGEpod-demo 0/1 Pending 0 11s[rootk8s-master schedule]# kubectl describe pod pod-demoWarning FailedScheduling 28s (x2 over 28s) default-scheduler 0/3 nodes are available: 3 node(s) didnt match node selector. 给一个节点打上标签[rootk8s-master schedule]# kubectl label nodes k8s-node2 disktypessdnode/k8s-node2 labeled [rootk8s-master schedule]# kubectl get node --show-labels|egrep disktypek8s-node2 Ready none 63d v1.14.1 beta.kubernetes.io/archamd64,beta.kubernetes.io/oslinux,disktypessd,kubernetes.io/archamd64,kubernetes.io/hostnamek8s-node2,kubernetes.io/oslinux [rootk8s-master schedule]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESpod-demo 1/1 Running 0 45s 10.244.1.14 k8s-node2 none none Node affinity节点亲和性 kubectl explain pods.spec.affinity.nodeAffinity 据官方说法未来NodeSeletor策略会被废弃由NodeAffinityPriority策略中requiredDuringSchedulingIgnoredDuringExecution替代。 NodeAffinityPriority策略和NodeSelector一样通过Node节点的Label标签进行匹配匹配的表达式有In, NotIn, Exists, DoesNotExist. Gt, and Lt。 定义节点亲和性规则有2种硬亲和性require和软亲和性preferred 硬亲和性requiredDuringSchedulingIgnoredDuringExecution软亲和性preferredDuringSchedulingIgnoredDuringExecution 硬亲和性实现的是强制性规则是Pod调度时必须满足的规则否则Pod对象的状态会一直是Pending软亲和性实现的是一种柔性调度限制在Pod调度时可以尽量满足其规则在无法满足规则时可以调度到一个不匹配规则的节点之上。需要注意的是preferred和required后半段字符串IgnoredDuringExecution表示 在Pod资源基于节点亲和性规则调度到某个节点之后如果节点的标签发生了改变调度器不会讲Pod对象从该节点上移除因为该规则仅对新建的Pod对象有效。 硬亲和性 kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution apiVersion: v1kind: Podmetadata: name: nodeaffinity-required spec: containers: - name: myapp image: ikubernetes/myapp:v1 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: # - {key: zone,operator: In,values: [ssd,hard]} - key: disktype operator: In values: - ssd - hard [rootk8s-master schedule]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESpod-affinity-required 1/1 Running 0 7s 10.244.1.16 k8s-node2 none none 发现和上面定义的节点选择器效果一样未来是要取代节点选择器的。 注意 nodeSelectorTerms可以定义多条约束只需满足其中一条。 matchExpressions可以定义多条约束必须满足全部约束。 如下配置清单必须存在满足标签zonefoo和ssdtrue的节点才能够调度成功affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - {key: zone, operator: In, values: [foo]} - {key: ssd, operator: Exists, values: []} #增加一个规则 [rootk8s-master ~]# kubectl get pods pod-affinity-requiredNAME READY STATUS RESTARTS AGEpod-affinity-required 0/1 Pending 0 16s[rootk8s-master ~]# kubectl label node k8s-node1 ssdtrue [rootk8s-master ~]# kubectl get pods pod-affinity-required NAME READY STATUS RESTARTS AGE pod-affinity-required 1/1 Running 0 2m 软亲和性 kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 60 preference: matchExpressions: - {key: zone, operator: In, values: [foo]} - weight: 30 preference: matchExpressions: - {key: ssd, operator: Exists, values: []} 总结 同时指定nodeSelector and nodeAffinitypod必须都满足nodeAffinity有多个nodeSelectorTerms pod只需满足一个nodeSelectorTerms多个matchExpressions pod必须都满足由于IgnoredDuringExecution所以改变labels不会影响已经运行pod总的来说node亲和性与nodeSelector类似是它的扩展节点是否配置合乎需求的标签或者Pod对象定义合理的标签选择器这样才能够基于标签选择出期望的目标节点 Pod affinityPod 亲和性 kubectl explain pods.spec.affinity.podAffinity 在出于高效通信的需求有时需要将一些Pod调度到相近甚至是同一区域位置比如同一节点、机房、区域等等比如业务的前端Pod和后端Pod 此时这些Pod对象之间的关系可以叫做亲和性。同时出于安全性的考虑也会把一些Pod之间进行隔离此时这些Pod对象之间的关系叫做反亲和性。 调度器把第一个Pod放到任意位置然后和该Pod有亲和或反亲和关系的Pod根据该动态完成位置编排这就是Pod亲和性和反亲和性调度的作用。 Pod的亲和性定义也存在硬亲和性和软亲和性的区别其约束的意义和节点亲和性类似。 requiredDuringSchedulingIgnoredDuringExecution 硬约束一定要满足Pod的亲和性调度必须要满足后续定义的约束条件。preferredDuringSchedulingIgnoredDuringExecution软约束不一定满足Pod的亲和性调度会尽量满足后续定义的约束条件。 Pod的亲和性调度要求各相关的Pod对象运行在同一位置而反亲和性则要求它们不能运行在同一位置。这里的位置实际上取决于节点的位置拓扑拓扑的方式不同Pod是否在同一位置的判定结果也会有所不同。 如果基于各个节点的kubernetes.io/hostname标签作为评判标准那么会根据节点的hostname去判定是否在同一位置区域。 根据节点上正在运行的pod的标签来调度而非node的标签要求对节点和Pod两个条件进行匹配其规则为如果在具有标签X的Node上运行了一个或多个符合条件Y的Pod那么Pod应该运行在此Node上 如果是互斥则拒绝运行在此Node上。 也就是说根据某个已存在的pod来决定要不要和此pod在一个Node上在一起就需要设置亲和性不和它在一起就设置互斥性。 Pod亲和性调度请使用podAffinity非亲和性调度请使用podAntiAffinity。 InterPodAffinityPriority策略有podAffinity和podAntiAffinity两种配置方式。 InterPodAffinityPriority是干嘛的呢简单来说就说根据Node上运行的Pod的Label来进行调度匹配的规则匹配的表达式有In, NotIn, Exists, DoesNotExist通过该策略可以更灵活地对Pod进行调度。 例如将多实例的Pod分散到不通的Node、尽量调度A-Pod到有B-Pod运行的Node节点上等等。另外与Node-affinity不同的是该策略是依据Pod的Label进行调度所以会受到namespace约束。 硬亲和性 通过Kubernetes内置节点标签中的key来进行声明这个key的名字为topologyKey用来表达节点所属的拓朴结构之下。 pod的亲和性表达方式与Node亲和性是一样的表达方式。 kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution 参数配置说明 kubectl -get nodes --show-labels kubernetes内置标签 ○ kubernetes.io/hostname ○ failure-domain.beta.kubernetes.io/zone ○ failure-domain.beta.kubernetes.io/region ○ beta.kubernetes.io/instance-type ○ beta.kubernetes.io/os ○ beta.kubernetes.io/arch topologyKey: 对于亲和性和软反亲和性不允许空topologyKey;对于硬反亲和性LimitPodHardAntiAffinityTopology控制器用于限制topologyKey只能是kubernetes.io/hostname;对于软反亲和性空topologyKey被解读成kubernetes.io/hostname, failure-domain.beta.kubernetes.io/zone and failure-domain.beta.kubernetes.io/region的组合kubernetes.io/hostname标签是Kubernetes集群节点的内建标签它的值为当前节点的主机名对于各个节点来说都是不同的 1:创建参照Pod #查看调度到哪个Node之上kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE pod-flag 1/1 Running 0 4m 10.244.1.16 k8s-node1 2:创建一个pod的硬亲和性 # 因为pod是属于某个命名空间的所以设置符合条件的目标Pod时还可以指定哪个命名空间或全部命名空间里的Pod# namespace的定义与labelSelector同级如果不指定命名空间则与此处创建的pod在一个namespace之中kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODEwith-pod-affinity 1/1 Running 0 11s 10.244.1.16 k8s-node1pod-flag 1/1 Running 0 1h 10.244.1.17 k8s-node1的确是在同一个Node上。如果在创建时pod状态一直处于Pending状态很有可能是因为找不到满足条件的Node基于单一节点的Pod亲和性相对来说使用的情况会比较少通常使用的是基于同一地区、区域、机架等拓扑位置约束。 比如部署应用程序myapp和数据库db服务相关的Pod时这两种Pod应该部署在同一区域上可以加速通信的速度 3:创建一个pod的反硬亲和性 kubectl explain pods.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODEpod-flag 1/1 Running 0 1h 10.244.1.16 k8s-node1with-pod-affinity 1/1 Running 0 1h 10.244.1.17 k8s-node1with-pod-antiffinity 1/1 Running 0 1m 10.244.2.11 k8s-node2#可以看到与参照pod不在同一个node之上,达到了互斥的作用 实例 1.借助反硬特性我们可以部署3个redis实例并且为了提升HA部署在不同的节点 apiVersion: apps/v1
kind: Deployment metadata: name: redis-cache spec: selector: matchLabels: app: store replicas: 3 template: metadata: labels: app: store spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: kubernetes.io/hostname containers: - name: redis-server image: redis:3.2-alpine 2部署三个web实例为了提升HA都不在一个node并且为了方便与redis交互尽量与redis在同一个node硬特性和反硬特性的结合应用。 apiVersion: apps/v1
kind: Deployment metadata: name: web-server spec: selector: matchLabels: app: web-store replicas: 3 template: metadata: labels: app: web-store spec: affinity: podAntiAffinity: #反亲和性 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - web-store topologyKey: kubernetes.io/hostname podAffinity: #亲和性 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: kubernetes.io/hostname containers: - name: web-app image: nginx:1.12-alpine 软亲和性 kubectl explain pods.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution 上述的清单配置当中pod的软亲和调度需要将Pod调度到标签为appcache并在区域zone当中或者调度到appdb标签节点上的但是我们的节点上并没有类似的标签 所以调度器会根据软亲和调度进行随机调度到k8s-node1节点之上。如下 [rootk8s-master ~]# kubectl get pods -o wide |grep myapp-with-preferred-pod-affinity myapp-with-preferred-pod-affinity-5c44649f58-cwgcd 1/1 Running 0 1m 10.244.1.40 k8s-node01 myapp-with-preferred-pod-affinity-5c44649f58-hdk8q 1/1 Running 0 1m 10.244.1.42 k8s-node01 myapp-with-preferred-pod-affinity-5c44649f58-kg7cx 1/1 Running 0 1m 10.244.1.41 k8s-node01 pod的反软亲和度 kubectl explain pods.spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: securityoperator: Invalues:- S2topologyKey: kubernetes.io/hostname 如果该节点已经运行着具有“securityS2”标签的pod将不会优先调度到该节点。 如果topologyKey是failure-domain.beta.kubernetes.io/zone该pod也不会被优先调度到具有“securityS2”标签的节点所在的zone 实例 使用该配置模板创建三个pod可以发现pod依旧分配到了不同的节点上。当创建第四个pod时第四个pod能够被顺利创建 说明preferredDuringScheduling在podAntiAnffinity下也是不严格匹配规则如果是硬约束会有一个处于 Pending 对称性考虑一个场景两个应用S1和S2。现在严格要求S1 pod不能与S2 pod运行在一个node如果仅设置S1的hard反亲和性是不够的必须同时给S2设置对应的hard反亲和性。即调度S1 pod时考虑node没有S2 pod同时需要在调度S2 pod时考虑node上没有S1 pod。考虑下面两种情况1.先调度S2后调度S1可以满足反亲和性2.先调度S1后调度S2违反S1的反亲和性规则因为S2没有反亲和性规则所以在schedule-time可以与S1调度在一个拓扑下。这就是对称性即S1设置了与S2相关的hard反亲和性规则就必须对称地给S2设置与S1相关的hard反亲和性规则以达到调度预期。 反亲和性soft/hard具备对称性上面已经举过例子了hard亲和性不具备对称性例如期望test1、test2亲和那么调度test2的时候没有必要node上一定要有test1但是有一个隐含规则node上有test1更好soft亲和性具备对称性不是很理解遗留 总结 1.Pod间的亲和性和反亲和性需要大量的处理需要消耗大量计算资源会增加调度时间,这会显着减慢大型集群中的调度。 我们不建议在大于几百个节点的群集中使用它们。 2.Pod反亲和性要求Node一致地标记,集群中的每个节点必须具有匹配topologyKey的标签,Pod反亲和性需要制定topologyKey如果某些或所有节点缺少指定的topologyKey标签则可能导致意外行为。 3.在反亲和性中空的selector表示不与任何pod亲和。 4.由于hard规则在预选阶段处理所以如果只有一个node满足hard亲和性但是这个node又不满足其他预选判断比如资源不足那么就无法调度。所以何时用hard何时用soft需要根据业务考量。 5.如果所有node上都没有符合亲和性规则的target pod那么pod调度可以忽略亲和性 6.如果labelSelector和topologyKey同级还可以定义namespaces列表表示匹配哪些namespace里面的pod默认情况下会匹配定义的pod所在的namespace如果定义了这个字段但是它的值为空则匹配所有的namespaces。 7.所有关联requiredDuringSchedulingIgnoredDuringExecution的matchExpressions全都满足之后系统才能将pod调度到某个node上。 转载于:https://www.cnblogs.com/centos-python/articles/10886525.html
