Kubernetes——浅聊 Affinity，就这么点东西

Posted 2023-04-28 左扬(你们的胃叫胃，孤的叫胃PLUS)

浅聊 Affinity，就这么点东西

在 Kubernetes 中，Affinity 是指用于控制 Pod 调度的策略，包括亲和性（Affinity）和反亲和性（Anti-Affinity）2种。

亲和性（Affinity）包括 NodeAffinity 和 PodAffinity 2种。

 

• 亲和性（Affinity）表示 Pod 需要部署在哪些节点上，比如需要部署在某些特定的节点或者跟其他某些节点上的 Pod 在同一个节点上。
  • NodeAffinity：用于将 Pod 调度到特定的节点上，可以指定 Pod 可调度的节点的标签要求。nodeAffinity 又包含以下两个方面：

    • 硬亲和 requiredDuringSchedulingIgnoredDuringExecution：表示 Pod 只能调度到满足指定标签要求的节点上。

    • 软亲和 preferredDuringSchedulingIgnoredDuringExecution：表示如果有多个节点同时满足指定标签要求，优先调度 Pod 到这些节点上。
  • PodAffinity：用于将 Pod 部署到与其他 Pod 所在节点相同的节点上，可以指定其他 Pod 的标签要求。podAffinity 包含以下三个方面：

    • requiredDuringSchedulingIgnoredDuringExecution：表示 Pod 只能调度到其他 Pod 所在节点上，这些节点需要满足指定标签的要求。

    • preferredDuringSchedulingIgnoredDuringExecution：表示 Pod 优先调度到其他 Pod 所在节点上，这些节点需要满足指定标签的要求。

    • requiredDuringSchedulingRequiredDuringExecution：表示 Pod 必须调度到与其他 Pod 所处节点相同的节点上

• 反亲和性（Anti-Affinity）与亲和性则相反，表示 Pod 不能部署在哪些节点上，如不能与某些特定的节点或者跟某些 Pod 在同一个节点上。

 

 

 

 

nodeAffinity 中的硬亲和和反亲和分别表示要求 Pod 与指定标签的节点具有亲和或反亲和关系，简单来说，要求 Pod 部署在哪个 Node 上。

　　具体来说，硬亲和性要求 Pod 必须部署到具有指定标签的节点上。可以通过 nodeSelector 和 nodeSelectorTerms 字段来实现节点的标记和选择，以满足硬亲和关系的要求。

　　反亲和性则是要求 Pod 不能部署到一些指定的节点上（即与这些节点具有反亲和关系）。这一方面可以通过 nodeSelector 和 nodeSelectorTerms 字段实现标记和选择，另一方面也可以使用 requiredDuringSchedulingIgnoredDuringExecution 字段，来具体指定不能部署的节点。

　　需要注意的是，硬亲和性要求必须严格满足，否则 Pod 无法运行。而反亲和性的要求可以松散，即如果没有指定标签的节点可用，Pod 仍可部署到该节点上。

 

如何在对 Kubernetes 服务的请求上使用 Session Affinity？

【中文标题】如何在对 Kubernetes 服务的请求上使用 Session Affinity？

【英文标题】：How to use Session Affinity on requests to Kubernetes service?

【发布时间】：2020-03-16 05:36:34

【问题描述】：

我找不到指定在关联部署使用多个副本进行扩展时 Kubernetes 服务的行为方式的文档。

我假设存在某种负载平衡。和服务类型有关系吗？

另外，我希望在服务转发的请求中具有一些亲和力（即，如果可能，所有具有特定后缀的请求都应始终映射到同一个 pod，等等）。这是可以实现的吗？我看到的关闭是 Ambassador，但这是服务级别的亲和力，而不是 pod 级别。

【参考方案1】：

部署：无状态工作负载

我找不到指定在关联部署使用多副本扩展时 Kubernetes 服务的行为方式的文档。

使用Deployment 部署的 Pod 应该是无状态的。

入口到服务路由

当使用Ingress，L7-proxy 时，路由可以基于 http 请求内容，但这取决于你使用的 IngressController 的实现。例如。 Ingress-nginx 有一些对粘性会话的支持，其他实现可能有你想要的。例如。 Istio 支持类似的设置。

大使

您所写的

Ambassador 也一些支持会话亲和/粘性会话。

配置粘性会话会使 Ambassador 将请求路由到给定会话中的同一后端服务。换句话说，会话中的请求由同一个 Kubernetes pod

提供服务

Pod 到 Service 路由

当集群中的 pod 向集群中的 Service 发出 http 请求时，kube-proxy does routing 默认以 循环 方式。

默认情况下，用户空间模式下的 kube-proxy 通过循环算法选择后端。

如果您希望 pod 到服务路由的会话亲和性，您可以在 Service 对象上设置 SessionAffinity: ClientIP 字段。

如果您想确保来自特定客户端的连接每次都传递到同一个 Pod，您可以通过将 service.spec.sessionAffinity 设置为“ClientIP”（默认为“无”）。