云原生Kubernetes：pod亲和性与反亲和性

已于 2023-09-20 08:54:16 修改
阅读量1.4k 收藏 1
点赞数
分类专栏： 云原生Kubernetes 文章标签： 云原生 kubernetes 容器
于 2023-09-19 15:58:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cronaldo91/article/details/133022082
版权

目录

一、理论

1.调度策略

2.Pod 拓扑分布约束

3.调度场景详解

4.亲和性与反亲和性案例

二、实验

1.亲和性与反亲和性

三、问题

1.节点批次打标签错误

2.for循环批量创建pod报错

3.比较 podAffinity 和 podAntiAffinity

四、总结

一、理论

1.调度策略

（1）对比

2.Pod 拓扑分布约束

（1）概念

使用 拓扑分布约束（Topology Spread Constraints） 来控制 Pod在集群内故障域之间的分布， 例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。 这样做有助于实现高可用并提升资源利用率。

（2）拓扑分布约束 （涉及K8S v1.25及以上版本）

Pod 拓扑分布约束使你能够以声明的方式进行配置。

topologySpreadConstraints 字段，Pod API 包括一个 spec.topologySpreadConstraints 字段。这个字段的用法如下所示：

---
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # 配置一个拓扑分布约束
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # 可选；自从 v1.25 开始成为 Beta
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # 可选；自从 v1.27 开始成为 Beta
      nodeAffinityPolicy: [Honor|Ignore] # 可选；自从 v1.26 开始成为 Beta
      nodeTaintsPolicy: [Honor|Ignore] # 可选；自从 v1.26 开始成为 Beta
  ### 其他 Pod 字段置于此处

(3) 示例

① 节点标签

拓扑分布约束依赖于节点标签来标识每个节点所在的拓扑域。 例如，某节点可能具有标签：

说明：
为了简便，此示例未使用众所周知的标签键 topology.kubernetes.io/zone 和 topology.kubernetes.io/region。 但是，建议使用那些已注册的标签键，而不是此处使用的私有（不合格）标签键 region 和 zone。

无法对不同上下文之间的私有标签键的含义做出可靠的假设。

②有一个 4 节点的集群且带有以下标签

③从逻辑上看集群如下

④一致性

应该为一个组中的所有 Pod 设置相同的 Pod 拓扑分布约束。

通常，如果正使用一个工作负载控制器，例如 Deployment，则 Pod 模板会帮你解决这个问题。 如果混合不同的分布约束，则 Kubernetes 会遵循该字段的 API 定义； 但是，该行为可能更令人困惑，并且故障排除也没那么简单。

运维人员需要一种机制来确保拓扑域（例如云提供商区域）中的所有节点具有一致的标签。 为了避免运维人员需要手动为节点打标签，大多数集群会自动填充知名的标签， 例如 kubernetes.io/hostname。检查运维人员的集群是否支持此功能。

⑤一个拓扑分布约束

假设拥有一个 4 节点集群，其中标记为 foo: bar 的 3 个 Pod 分别位于 node1、node2 和 node3 中：

希望新来的 Pod 均匀分布在现有的可用区域，则可以按如下设置其清单：

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

从此清单看，topologyKey: zone 意味着均匀分布将只应用于存在标签键值对为 zone: <any value> 的节点 （没有 zone 标签的节点将被跳过）。如果调度器找不到一种方式来满足此约束， 则 whenUnsatisfiable: DoNotSchedule 字段告诉该调度器将新来的 Pod 保持在 pending 状态。

如果该调度器将这个新来的 Pod 放到可用区 A，则 Pod 的分布将成为 [3, 1]。 这意味着实际偏差是 2（计算公式为 3 - 1），这违反了 maxSkew: 1 的约定。 为了满足这个示例的约束和上下文，新来的 Pod 只能放到可用区 B 中的一个节点上：

或者：

可以调整 Pod 规约以满足各种要求：

将 maxSkew 更改为更大的值，例如 2，这样新来的 Pod 也可以放在可用区 A 中。
将 topologyKey 更改为 node，以便将 Pod 均匀分布在节点上而不是可用区中。 在上面的例子中，如果 maxSkew 保持为 1，则新来的 Pod 只能放到 node4 节点上。
将 whenUnsatisfiable: DoNotSchedule 更改为 whenUnsatisfiable: ScheduleAnyway， 以确保新来的 Pod 始终可以被调度（假设满足其他的调度 API）。但是，最好将其放置在匹配 Pod 数量较少的拓扑域中。 请注意，这一优先判定会与其他内部调度优先级（如资源使用率等）排序准则一起进行标准化。

3.调度场景详解

kube-scheduler 给一个 pod 做调度选择包含两个步骤： 1.过滤(节点预选),2.打分（节点优选，节点选定）

（1）Deployment/RC：全自动调度

Deployment/RC主要是自动部署应用的多个副本，并持续监控，以维持副本的数量。默认是使用系统Master的Scheduler经过一系列算法计算来调度，用户无法干预调度过程与结果。

（2）NodeSelector：定向调度
通过Node的标签和Pod的nodeSelector属性相匹配，可以达到将pod调度到指定的一些Node上。

 

（3）Node亲和性调度
 目前有两种亲和性表达，NodeAffinity语法支持的操作符包括In/NotIn/Exists/DoesNotExist/Gt/Lt。
 

 

 

该pod可以被调度到key为“env”，值为“node01”或“node02”的节点。另外，在满足该条件的节点中，优先使用具有“disk”标签，且值为“ssd”的节点。
 

（4）POD亲和性调度
 

POD亲和性表示POD部署到满足某些label的pod所在的NODE上。pod需要被调度到某个NODE节点上，该节点属于kubernetes.io/hostname 这个域，并且上面运行了这样的 pod：这个pod 有一个app=nginx的 label。
 

 

（5）POD反亲和性调度
 

POD反亲和性表示POD不能部署到满足某些label的pod所在的NODE上。
 

该pod不能被调度到某个NODE节点上，该节点属于kubernetes.io/hostname 这个域，并且上面运行了这样的 pod：这个pod 有一个app=nginx的 label。
 

（6） Taints与Tolerations（污点与容忍）
 Taints与前面的Affinity相反，它让Node拒绝Pod的运行。为node添加一个Taint，效果是NoSchedule(除了NoSchedule还可以取值PreferNoSchedule/NoExecute)。意味着除非Pod明确声明可以容忍这个Taint，否则不会被调度到该Node上。使用PodToleratesNodeTaints预选策略和TaintTolerationPriority优选函数完成该机制。
 

 

该pod容忍env=node02 且 effect 为 NoExecute的节点。可以进行调度
 

（7）DaemonSet调度
 

在每个Node上调度一个Pod，管理集群中每个Node上仅运行一份Pod的副本实例。
 

 

该pod会在每一个符合调度的node 节点上启动一个实例。该节点必须存在fluentd=true 的标签。
 

 

4.亲和性与反亲和性案例
 

（1）环境准备
 

node01、 node02 都有标签 test=a，有个pod1 运行在node01上， 标签为app=myapp01
 

#设置node01和node02节点，拥有标签 test=a
[root@master demo]# kubectl  label nodes node{01,02} test=a --overwrite
node/node01 labeled
node/node02 labeled

#查看拥有标签test=a的节点
[root@master demo]# kubectl  get nodes -l test=a
NAME     STATUS   ROLES    AGE    VERSION
node01   Ready    <none>   7d6h   v1.15.1
node02   Ready    <none>   7d6h   v1.15.1

 

[root@master demo]# vim test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp01
  labels:
    app: myapp01
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1

 

#声明式创建pod 
[root@master demo]# kubectl  apply  -f test.yaml 
pod/myapp01 created

#查看pod myapp01的详细信息的标签
[root@master demo]# kubectl  get pods  myapp01  -o wide --show-labels 
NAME      READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES   LABELS
myapp01   1/1     Running   0          26s   10.244.1.112   node01   <none>           <none>            app=myapp01

 

（2） 亲和性+ In 测试
 

[root@master demo]# vim a.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp10
  labels:
    app: myapp03
spec:
  containers:
  - name: myapp03
    image: soscscs/myapp:v1
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp01
        topologyKey: test

 

pod拥有app=myapp01 标签（设这个pod为x），则把新pod调度到和 pod x 拥有同一个拓扑域test=a 的 节点上。
 

[root@master demo]# for i in myapp{11..15}; do kubectl apply -f a.yaml; sed -ri "4s#myapp1[0-9]#$i#" a.yaml; done
pod/myapp10 created
pod/myapp11 created
pod/myapp12 created
pod/myapp13 created
pod/myapp14 created
[root@master demo]# kubectl  get pods -o wide --show-labels 
NAME      READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES   LABELS
myapp01   1/1     Running   0          88m   10.244.1.112   node01   <none>           <none>            app=myapp01
myapp10   1/1     Running   0          6s    10.244.2.104   node02   <none>           <none>            app=myapp03
myapp11   1/1     Running   0          6s    10.244.1.138   node01   <none>           <none>            app=myapp03
myapp12   1/1     Running   0          5s    10.244.2.105   node02   <none>           <none>            app=myapp03
myapp13   1/1     Running   0          5s    10.244.1.139   node01   <none>           <none>            app=myapp03
myapp14   1/1     Running   0          5s    10.244.2.106   node02   <none>           <none>            app=myapp03

 

因为拓扑域test=a内，已经有了pod存在于node01节点上，所以把新pod调度到和 pod x 拥有同一个拓扑域test=a 的 节点上。
 

（3）亲和性+NotIn 测试
 

[root@master demo]# vim a.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp10
  labels:
    app: myapp03
spec:
  containers:
  - name: myapp03
    image: soscscs/myapp:v1
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: NotIn
            values:
            - myapp01
        topologyKey: test

 

[root@master demo]# kubectl delete pod myapp{10..14};for i in myapp{11..15}; do kubectl apply -f a.yaml; sed -ri "4s#myapp1[0-9]#$i#" a.yaml; done
pod "myapp10" deleted
pod "myapp11" deleted
pod "myapp12" deleted
pod "myapp13" deleted
pod "myapp14" deleted
pod/myapp10 created
pod/myapp11 created
pod/myapp12 created
pod/myapp13 created
pod/myapp14 created
[root@master demo]# kubectl  get pods -o wide --show-labels 
NAME      READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES   LABELS
myapp01   1/1     Running   0          91m   10.244.1.112   node01   <none>           <none>            app=myapp01
myapp10   1/1     Running   0          5s    10.244.1.140   node01   <none>           <none>            app=myapp03
myapp11   1/1     Running   0          5s    10.244.2.107   node02   <none>           <none>            app=myapp03
myapp12   1/1     Running   0          4s    10.244.1.141   node01   <none>           <none>            app=myapp03
myapp13   1/1     Running   0          4s    10.244.2.108   node02   <none>           <none>            app=myapp03
myapp14   1/1     Running   0          4s    10.244.1.142   node01   <none>           <none>            app=myapp03

 

（4）非亲和性+In 测试
 

[root@master demo]# vim a.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp10
  labels:
    app: myapp03
spec:
  containers:
  - name: myapp03
    image: soscscs/myapp:v1
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp01
        topologyKey: test

 

[root@master demo]# kubectl delete pod myapp{10..14};for i in myapp{11..15}; do kubectl apply -f a.yaml; sed -ri "4s#myapp1[0-9]#$i#" a.yaml; done
pod "myapp10" deleted
pod "myapp11" deleted
pod "myapp12" deleted
pod "myapp13" deleted
pod "myapp14" deleted
pod/myapp10 created
pod/myapp11 created
pod/myapp12 created
pod/myapp13 created
pod/myapp14 created
[root@master demo]# kubectl  get pods -o wide --show-labels 
NAME      READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES   LABELS
myapp01   1/1     Running   0          96m   10.244.1.112   node01   <none>           <none>            app=myapp01
myapp10   0/1     Pending   0          4s    <none>         <none>   <none>           <none>            app=myapp03
myapp11   0/1     Pending   0          3s    <none>         <none>   <none>           <none>            app=myapp03
myapp12   0/1     Pending   0          3s    <none>         <none>   <none>           <none>            app=myapp03
myapp13   0/1     Pending   0          3s    <none>         <none>   <none>           <none>            app=myapp03
myapp14   0/1     Pending   0          3s    <none>         <none>   <none>           <none>            app=myapp03


[root@master demo]# kubectl  describe  pod myapp10

 

（5）非亲和性 + NotIn 测试
 

[root@master demo]# vim a.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp10
  labels:
    app: myapp03
spec:
  containers:
  - name: myapp03
    image: soscscs/myapp:v1
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: NotIn
            values:
            - myapp01
        topologyKey: test

 

[root@master demo]# kubectl delete pod myapp{10..14};for i in myapp{11..15}; do kubectl apply -f a.yaml; sed -ri "4s#myapp1[0-9]#$i#" a.yaml; done
pod "myapp10" deleted
pod "myapp11" deleted
pod "myapp12" deleted
pod "myapp13" deleted
pod "myapp14" deleted
pod/myapp10 created
pod/myapp11 created
pod/myapp12 created
pod/myapp13 created
pod/myapp14 created
[root@master demo]# kubectl  get pods -o wide --show-labels 
NAME      READY   STATUS    RESTARTS   AGE    IP             NODE     NOMINATED NODE   READINESS GATES   LABELS
myapp01   1/1     Running   0          102m   10.244.1.112   node01   <none>           <none>            app=myapp01
myapp10   1/1     Running   0          8s     10.244.2.109   node02   <none>           <none>            app=myapp03
myapp11   0/1     Pending   0          8s     <none>         <none>   <none>           <none>            app=myapp03
myapp12   0/1     Pending   0          7s     <none>         <none>   <none>           <none>            app=myapp03
myapp13   0/1     Pending   0          7s     <none>         <none>   <none>           <none>            app=myapp03
myapp14   0/1     Pending   0          7s     <none>         <none>   <none>           <none>            app=myapp03


[root@master demo]# kubectl  describe  pod myapp11

 

 

二、实验
 

1.亲和性与反亲和性
 

（1）环境准备
 

node01、 node02 都有标签 test=a，有个pod1 运行在node01上， 标签为app=myapp01
 

 

编写资源清单
 

 

 

声明式创建pod
 

 

查看pod myapp01的详细信息的标签
 

pod myapp01 拥有标签app=myapp01,且被调度到了node01上
 

 

 

（2） 亲和性+ In 测试
 

 

 

pod拥有app=myapp01 标签（设这个pod为x），则把新pod调度到和 pod x 拥有同一个拓扑域test=a 的 节点上。
 

创建pod myapp10-myapp14
 

 

因为拓扑域test=a内，已经有了pod存在于node01节点上，所以把新pod调度到和 pod x 拥有同一个拓扑域test=a 的 节点上。
 

pod从node01节点开始在两个节点上依次循环创建pod
 

 

查看资源清单文件，最后一次更改为15后，执行了14，然后修改为15结束for循环，实际是创建pod myapp10-myapp14就结束了
 

 

 

（3）亲和性+NotIn 测试
 

先修改资源清单文件
 

 

 

批量删除之前的pod myapp10-myapp14，并创建pod myapp10-myapp14
 

 

pod从node01节点开始，在两个节点上依次循环创建pod
 

 

（4）非亲和性+In 测试
 

先修改资源清单文件
 

 

 

批量删除之前的pod myapp10-myapp14，并创建pod myapp10-myapp14
 

 

查看信息，新创建的pod都处于Pending状态
 

 

查看详细信息
 

 

两个节点都不匹配pod非亲和规则，又因为使用的是硬限制，因此当找不到合适的node节点调度pod时，就会处于Pending状态
 

 

（5）非亲和性 + NotIn 测试
 

先修改资源清单文件
 

 

批量删除之前的pod myapp10-myapp14，并创建pod myapp10-myapp14
 

 

查看信息，只有第一个myapp10成功在node02上创建，剩余的4个pod都处于Pending状态
 

 

查看详细信息
 

 

两个节点都不满足现有的pod反亲和性特征
 

 

 

三、问题
 

1.节点批次打标签错误
 

（1）报错
 

 

（2）原因分析
 

语法错误
 

（3）解决方法
 

将括号（）修改为花括号 { }
 

修改前：
 

 

修改后：
 

 

成功：
 

 

 

2.for循环批量创建pod报错
 

（1）报错
 

 

（2）原因分析
 

“s”命令缺少终止符合#
 

（3）解决方法
 

添加终止符#
 

修改前：
 

 

修改后：
 

 

成功：
 

 

 

3.比较 podAffinity 和 podAntiAffinity
 

（1）比较
 

在 Kubernetes 中， Pod亲和性和反亲和性控制 Pod 彼此的调度方式（更密集或更分散）。
 

podAffinity
吸引 Pod；你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。

podAntiAffinity
驱逐 Pod。如果将此设为 requiredDuringSchedulingIgnoredDuringExecution 模式， 则只有单个 Pod 可以调度到单个拓扑域；如果你选择 preferredDuringSchedulingIgnoredDuringExecution， 则你将丢失强制执行此约束的能力。
 

要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，从而实现高可用性或节省成本。 这也有助于工作负载的滚动更新和平稳地扩展副本规模。
 

 

四、总结
 

批量删除之前的pod myapp10-myapp14，并创建pod myapp10-myapp14
 

[root@master]# kubectl delete pod myapp{10..14};for i in myapp{11..15}; do kubectl apply -f a.yaml; sed -ri "4s#myapp1[0-9]#$i#" a.yaml; done


 


                

        

        

    




    

      

        

            

              
                
                  cronaldo91
                
              
            

            

                关注
              
            

        

        

          
    
            
  • 
              
                
                
                
                
                      0
                
              
              
    点赞
    
            
    • 
            
  • 
              
                
                
                
              
              
    踩
    
            
    • 
            
  • 
              
                
                
                
                
                    1
                
              
              
    
                
    
                  
                    收藏
                  
                
    
              
    
              
    
                
    
                  觉得还不错?
                  
                    一键收藏
                  
                 
                
    
              
    
            
    • 
          
  • 
            
    
              
              
            
    
              
              
              
                    0
              
            
            
    评论
    
          
    • 
          
  • 
          
    • 
          
  • 
            
              
            
              
    
            
              
                
            
    
          
    • 
        

      

      

            

                专栏目录
          










                



	

		

			

				
					
kubernetes：Kubernetes，从初学者到专家

				
			

			

				

					03-04
				

			

		

		

			
				
Kubernetes
 Kubernetes，从初学者到专家。

			
		

	



                

              
                



	

		

			

				
					
k8s之pod调度亲和性和反亲和性

				
			

			

				

					冻梨不是梨的博客
				

				

					01-04
					
					8363
					
				

			

		

		

			
				
目录

nodeSelector

亲和性和反亲和性调度

nodeAffinity 节点亲和性

podAffinity pod亲和性

podAntiAffinity pod反亲和性

欢迎关注壹家大数据，后台回复“k8s”,获取k8s权威指南下载链接。



正文

通常情况下，使用的都是k8s默认的调度调度方式，但是在有些情况下，我们需要将pod运行在具有特点的标签的node上才能都运行，...

			
		

	



                


  
              

                


	

		

			

				
					
Pod亲和性、Pod反亲和性、污点与容忍度、API资源对象PV和PVC和本地存储

					
最新发布

				
			

			

				

					Chauncey_Qin的博客
				

				

					07-15
					
					621
					
				

			

		

		

			
				
匹配到合适的资源后PVC和PV会进行绑定，它们两者是一一对应的；

			
		

	





	

		

			

				
					
资源调度（2）-----pod的亲和性和反亲和性

				
			

			

				

					qq_61843057的博客
				

				

					01-10
					
					1093
					
				

			

		

		

			
				
污点和容忍工作内容：任何选择node节点的部署pod多个master节点:kubectl taint node master节点名称 node-role.kubernetes.io/master=:PreferNoSchedule尽量不往master节点上部男pod,但是不是一定的。防止资源浪费。自定义一个标签业务维护：node02需要维护2小时，但这个节点的业务pod在运行。就需要把这个节点的污点设置为：NoExeccute。

			
		

	



		

			
		



	

		

			

				
					
6-3 Pod亲和与反亲和, 污点与容忍, 驱逐

				
			

			

				

					分享云原生，容器，运维等干货知识
				

				

					09-13
					
					352
					
				

			

		

		

			
				
在6-2 nodeSelector, nodeName, node亲和与反亲和中通过node打标签和部署文件匹配标签，实现pod可调度性。而Pod亲和与反亲和则通过node已经运行的pod作为调度标准。

			
		

	





	

		

			

				
					
pod亲和性和反亲和性

				
			

			

				

					xiongwenwu的专栏
				

				

					04-26
					
					2332
					
				

			

		

		

			
				
背景：
实际使用中，如果希望2个pod在一个node上，那么可以用到node的亲和性，或者使用pod亲和性。如果希望2个io密集型或者2个CPU密集型的pod不在一个node上，就可以用到pod的反亲和性。
一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们内部的一些服务 gitlab 之类的也是跑在Kubernetes集群上的，我们就不希望对外的一些服务和内部的服务跑在

			
		

	





	

		

			

				
					
Pod的亲和性和反亲和性

				
			

			

				

					m0_75209491的博客
				

				

					01-09
					
					1406
					
				

			

		

		

			
				
如何部署pod是重要的集群的调度机制，合理的配置pod调度机制可以实现资源最大化利用。拓扑域：k8s集群节点当中的一个组织结构，可以更具节点的物理关系或者逻辑关系进行划分。可以用来表示节点之间的空间关系。网络关系或者其他类型的关系。这里的亲和性反亲和性都指的是标签。node匹配的是主机的标签而pod匹配的是pod自己的标签。

			
		

	





	

		

			

				
					
pod的亲和性和反亲和性

				
			

			

				

					2301_79410672的博客
				

				

					01-09
					
					462
					
				

			

		

		

			
				
拓扑域：k8s集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分，可以用来表示节点之间的空间关系，网格关系或者其他类型的关系。pod和指定标签的pod部署在同一拓扑域。pod和指定标签的pod部署在不同拓扑域。

			
		

	





	

		

			

				
					
pod 的亲和性，反亲和性 实验

				
			

			

				

					qq_44135433的博客
				

				

					11-23
					
					361
					
				

			

		

		

			
				
xxxxx



			
		

	





	

		

			

				
					
云原生-k8s操作文档

				
			

			

				

					11-06
				

			

		

		

			
				
资源清单-pod进阶.pdf**：在深入Pod管理中，此文档涵盖了如何使用YAML文件定义更复杂的Pod和应用配置，包括环境变量、卷挂载、资源限制和亲和性规则等，这些都是实现应用部署自动化和优化的重要手段。  4. **05.资源...

			
		

	





	

		

			

				
					
【Cloud Native Lives】Kubernetes管理员实训 第2课：调度管理实训1

				
			

			

				

					08-03
				

			

		

		

			
				
- **affinity**：更复杂的亲和性和反亲和性规则，允许基于Pod间的相互关系进行调度。 - **tolerations**：让Pod能够容忍Node上的某些不可接受的条件，如taints，从而扩大调度范围。  在Kubernetes中，调度器的智能...

			
		

	





	

		

			

				
					
【技术分享】Kubernetes落地实践.pptx

				
			

			

				

					06-02
				

			

		

		

			
				
- **Affinity, NodeAffinity, PodAffinity, PodAntiAffinity**：定义 Pod 部署时的亲和性和反亲和性规则。 - **Rolling Update, Recreate**：更新策略，确保服务的连续性。 - **ResourceQuota**：全局资源配额限制。...

			
		

	





	

		

			

				
					
kube-slides:关于Kubernetes的演示

				
			

			

				

					03-27
				

			

		

		

			
				
3. **Scheduler**：负责将待调度的Pod（Kubernetes的基本调度单元）分配到合适的Node（运行在物理或虚拟机上的Kubernetes实例）上，基于各种策略如资源需求、硬件/软件亲和性等。  4. **Controller Manager**：运行...

			
		

	





	

		

			

				
					
【k8s】pod调度——亲和，反亲和，污点，容忍

				
			

			

				

					manyulanlanlu的博客
				

				

					11-05
					
					1636
					
				

			

		

		

			
				
但我们可以在 Pod 上设置容忍(Tolerations)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。//由于指定 Pod 所在的 node01 节点上具有带有键 kgc 和标签值 a 的标签，node02 也有这个kgc=a的标签，所以 node01 和 node02 是在一个拓扑域中，反亲和要求新 Pod 与指定 Pod 不在同一拓扑域，所以新 Pod 没有可用的 node 节点，即为 Pending 状态。调度器试图在每个拓扑域中放置数量均衡的 Pod。

			
		

	





	

		

			

				
					
OpenShift 4 - Pod的亲和性/反亲和性

				
			

			

				

					多恩斯基的博客
				

				

					10-01
					
					872
					
				

			

		

		

			
				
https://access.redhat.com/solutions/4165791



			
		

	





	

		

			

				
					
Kubernetes 之 Pod 之间的亲和性与反亲和性

				
			

			

				

					千度阿三的博客
				

				

					05-18
					
					510
					
				

			

		

		

			
				
Pod 反亲和性是与亲和性完全相反的定义，一旦发现它的约束条件匹配，那么这个 Pod 比与匹配 Pod 在不同的上的工作节点上。它主要可以用来保障不是热点区域和不需要高性能响应但很重要的业务不受干扰。

			
		

	





	

		

			

				
					
k8s中亲和性与反亲和性

				
			

			

				

					魏志标的博客
				

				

					04-29
					
					8051
					
				

			

		

		

			
				
k8s中亲和性与反亲和性
Kubernetes的默认调度器以预选、优选、选定机制完成将每个新的Pod资源绑定至为其选出的目标节点上，不过，它只是Pod对象的默认调度器，默认情况下调度器考虑的是资源足够，并且负载尽量平均。
在使用中，用户还可以自定义调度器插件，并在定义Pod资源配置清单时通过spec.schedulerName指定即可使
一、node亲和性
NodeAffinity意为Node节点亲和性的调度策略，是用于替换NodeSelector的全新调度策略。
定义节点亲和性规则时有两种类型的节点亲和性

			
		

	





	

		

			

				
					
Kubernetes集群Pod资源基于pod反亲和性调度配置（十九）

					
热门推荐

				
			

			

				

					江晓龙的博客
				

				

					08-03
					
					1万+
					
				

			

		

		

			
				
Kubernetes集群Pod资源基于pod反亲和性调度配置
1.pod反亲和性调度配置
所谓pod反亲和性调度就是将一个pod运行在与参照pod不是同一个node节点的其他节点上
pod反亲和性即使匹配的标签时不存在的，pod也会创建成功，因为反亲和性就是和匹配的标签pod不在同一个node上调度
反亲和性中只配置硬限制就可以实现效果了，因为pod标签不存在，也会创建pod，因为本质就是反着来的，软限制并不能起到什么独特的效果

pod反亲和性调度配置
[root@k8s-master ~]# kubec

			
		

	





	

		

			

				
					

				
			

			

				

					
				

			

		

		

			
				

			
		

	



              




          




        



    





    



      

      

        
      

      





	

		评论	
	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值