k8s 中的亲和性和反亲和性

k8s 中的亲和性和反亲和性

通常情况下，Pod分配到哪些Node是不需要管理员操心的，这个过程会由scheduler自动实现，因为调度程序会自动进行合理的调度（如通过一系列的评分机制将 pods 合理分配到最优节点上，而不会将 pod 分配在没有足够资源的节点上等）。但有时，我们需要指定一些调度的限制，例如某些应用应该跑在具有SSD存储的节点上，或者将两个通信比较频繁的不同服务 pod 调度到同一个可用域等等。

​​labels​​​ 在 K8s 中是一个很重要的概念，作为一个标识，Service、Deployments 和 Pods 之间的关联都是通过 ​​label​​​ 来实现的。而每个节点也都拥有 ​​label​​​ ，通过设置 ​​label​​​ 相关的策略可以使得 pods 关联到对应 ​​label​​ 的节点上。

nodeSelector

首先我们为Node规划标签，然后在创建部署的时候，通过使用​​nodeSelector​​标签来指定Pod运行在哪些节点上。

​​nodeSelector​​​ 是最简单的约束方式。 ​​nodeSelector​​ 是 PodSpec 的一个字段。

通过 ​​--show-labels​​​ 可以查看当前 nodes 的 ​​labels​​

$ kubectl get nodes --show-labelsNAME STATUS ROLES AGE VERSION LABELSminikube Ready 1m v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=minikube

如果没有额外添加 nodes ​​labels​​​ ，那么看到的如上所示的默认标签。我们可以通过 ​​kubectl label node​​​ 命令给指定 node 添加 ​​labels​​ ：

$ kubectl label node minikube disktype=ssdnode/minikube labeled$ kubectl get nodes --show-labelsNAME STATUS ROLES AGE VERSION LABELSminikube Ready 5m v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/hostname=minikube

当然，你也可以通过 ​​kubectl label node​​​ 删除指定的 ​​labels​​​ （标签 key 接 ​​-​​ 号即可）

$ kubectl label node minikube disktype-node/minikube labeled$ kubectl get node --show-labelsNAME STATUS ROLES AGE VERSION LABELSminikube Ready 23m v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=minikube

创建测试 pod 并指定 ​​nodeSelector​​ 选项绑定节点：

apiVersion: v1kind: Podmetadata: name: nginx labels: env: testspec: containers: - name: nginx image: docker.io/nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd

​​nodeSelector​​​ 可以很方便的解决以上比较简单的需求，但是它还不够灵活。比如我想部署的服务可以很好的分散在不同机架的服务器上，此时 ​​nodeSelector​​ 就并不是那么管用了。因此，Kubernetes 引入了亲和性和反亲和性概念。

Affinity and anti-affinity

nodeSelector的调度方式略显简单，通过亲和和反亲和配置，能够为调度提供更灵活的策略，主要有以下几点增强：

更多的表达式支持，不仅仅是ADD和精确匹配了可以设置soft/preference的调度策略，而不是刚性的要求可以通过Pod的标签进行调度约束，不仅仅是Node的标签

affinity 特性拥有两种类型，一种是 node affinity，一种是 pod affinity/anti-affinity。

node affinity 类似 ​​nodeSelector​​ ，但同时拥有上文提到的 1、2 两点优势

pod affinity/anti-affinity 针对 pods 指定 ​​labels​​ ，同时拥有以上三点优势。

Node affinity

Node affinity 是 Kubernetes 1.2版本后引入的新特性，类似于nodeSelector，允许我们指定一些Pod在Node间调度的约束。

Node affinity 支持两种形式：

​​requiredDuringSchedulingIgnoredDuringExecution (硬限制， 同nodeSelector)​​​​preferredDuringSchedulingIgnoredDuringExecution（软限制）​​

可以认为前一种是必须满足，如果不满足则不进行调度，后一种是倾向满足，不满足的情况下会调度的不符合条件的Node上。

​​IgnoreDuringExecution​​表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。

下面看一个例子

apiVersion: v1kind: Podmetadata: name: nginxspec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 //取值范围1-100 preference: matchExpressions: - key: another-node-label-key operator: In values: - another-node-label-value containers: - name: nginx image: docker.io/nginx

以上规则表达的意思是，该 Pod 只能被调度到拥有 ​​kubernetes.io/e2e-az-name=e2e-az1​​​ 或者 ​​kubernetes.io/e2e-az-name=e2e-az2​​​ 标签的节点上，其中在满足之前标签条件的同时更倾向于调度在拥有 ​​another-node-label-key=another-node-label-value​​ 标签的节点上。

标签判断的操作符除了使用​​In​​​之外，还可以使用​​NotIn​​​、​​Exists​​​、​​DoesNotExist​​​、​​Gt​​​、​​Lt​​​ 操作符， 也可以使用 ​​NotIn​​​ 、 ​​DoesNotExist​​ 来实现反亲和性，也可以通过​ node taints ​来实现。

1）如果同时指定 ​​nodeSelector​​​ 和 ​​nodeAffinity​​ ，两者同时满足才会被调度。

2）如果指定多个​​nodeSelectorTerms​​，则只要满足其中一个条件，就会被调度到相应的节点上。

3）如果指定多个​​matchExpressions​​，则所有的条件都必须满足，才会调度到对应的节点。

inter-pod affinity/anti-affinity

这个特性是Kubernetes 1.4后增加的，允许用户通过已经运行的Pod上的标签来决定调度策略，而不是节点的标签。 用文字描述就是“如果Node X上运行了一个或多个满足Y条件的Pod，那么这个Pod在Node应该运行在Pod X”，因为Node没有命名空间，Pod有命名空间，这样就允许管理员在配置的时候指定这个亲和性策略适用于哪个命名空间，可以通过​​topologyKey​​来指定。topology是一个范围的概念，可以是一个Node、一个机柜、一个机房或者是一个区域（如北美、亚洲）等，实际上对应的还是Node上的标签。

同 node affinity，pod 亲和性和反亲和性也有两种类型：

requiredDuringSchedulingIgnoredDuringExecution，硬性要求，必须精确匹配preferredDuringSchedulingIgnoredDuringExecution，软性要求

pod 亲和性和反亲和性需要大量的计算，会显著降低集群的调度速度，不建议在大于几百个节点的集群中使用。 pod 反亲和性要求集群中的所有节点必须具有 ​​topologyKey​​ 匹配的标签，否则可能会导致意外情况发生。

同的是，pod 通过 ​​podAntiAffinity​​ 设置反亲和性，如下例子：

apiVersion: v1kind: Podmetadata: name: with-pod-affinityspec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: kubernetes.io/hostname containers: - name: with-pod-affinity image: k8s.gcr.io/pause:2.0

以上示例表示，pod 必须调度在至少运行一个 ​​security=S1​​​ 标签的 pod 的节点上（更准确的说，这个 pod 可以运行在节点 N 上，如果该节点有标签 key 为 ​​failure-domain.beta.kubernetes.io/zone​​​ ，而且运行着标签为 ​​security=S1​​ 的实例）。

另外，反亲和规则表明最好不要调度到运行有 ​​security=S2​​​ 标签的 pod 的节点上（更准确的说，如果这个节点拥有标签 key 为 ​​failure-domain.beta.kubernetes.io/zone​​​ ，但运行有 ​​security=S2​​ 标签的 pod，那么这个节点就不会被优先选择调度）。

总结

​​podAffinity​​​ 和 ​​podAntiAffinity​​​ 支持 ​​In​​​ 、 ​​NotIn​​​ 、 ​​Exists​​​ 、 ​​DoesNotExist​​ 四种表达式。

原则上， ​​topologyKey​​ 可以为任何合法的键值对。但是因为性能和安全的原因，有以下限制：

针对​​podAffinity​​​ 和​​podAntiAffinity​​​ 中的​​requiredDuringSchedulingIgnoredDuringExecution​​​ ，​​topologyKey​​ 为空是不允许的针对​​podAntiAffinity​​​ 中的​​requiredDuringSchedulingIgnoredDuringExecution​​​ ，准入控制器选项​​LimitPodHardAntiAffinityTopology​​​ 可以把​​topologyKey​​​ 限制为​​kubernetes.io/hostname​​ ，如果想自定义值，可以修改准入控制器或者直接禁用针对​​podAntiAffinity​​​ 中的​​preferredDuringSchedulingIgnoredDuringExecution​​​ ，​​topologyKey​​​ 为空，则代表所有拓扑（仅限于​​kubernetes.io/hostname​​​ ,​​failure-domain.beta.kubernetes.io/zone​​​ and​​failure-domain.beta.kubernetes.io/region​​ ）除了以上情况，​​topologyKey​​ 可以为任意合法的键值对

除了 ​​labelSelector​​​ 和 ​​topologyKey​​​ ，还可以指定 namespace 的 ​​labelSelector​​​ 作为匹配。 ​​labelSelector​​​ 和 ​​topologyKey​​ 属于同一级别，如果未定义或设置为空值，那么默认为定义 pod affinity 和 anti-affinity 所在的空间。

实践案例

始终调度在同一个节点

在一个三个节点的集群中，一个 web 应用程序依赖内存存储，如 redis，我们想 web 程序尽可能的和缓存调度在同一个节点上。redis 的 Deployment 配置如下：

apiVersion: apps/v1kind: Deploymentmetadata: name: redis-cachespec: 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

上面的例子中，创建了一个具有三个实例的部署，采用了Pod间的反亲和策略，限制创建的实例的时候，如果节点上已经存在具有相同标签的实例，则不进行部署，避免了一个节点上部署多个相同的实例。

web-server 规则设置如下，表达 pod 不被调度在同一个节点上，并且必须调度在运行标签 ​​app=store​​ pod 的节点上。

apiVersion: apps/v1kind: Deploymentmetadata: name: web-serverspec: 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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。