从服务的externalTrafficPolicy到podAntiAffinity(service dao servlet)

总结：一种使用场景是将服务分布在不同的主机或者拓扑域之间，以提高服务本身的稳定性。 本示例的解释使用此作为拓扑域来显示匹配规则。 即相同标签的相同规则会被调度到不同的节点上。

ExternalTrafficPolicy 概述

如果您的服务需要将外部流量路由到本地节点或集群级端点，即您的服务类型为 For LoadBalancer或者NodePort，必须指定该参数。 有两个选项：集群（默认）和本地。 “集群”隐藏了源IP地址，可能会产生到其他节点的第二跳，但全局负载效果更好。 “本地”保留客户端的源 IP 地址并避免 LoadBalancer 和 NodePort 类型服务的第二跳，但可能导致负载不平衡。

在实际业务中，很多公司需要保留客户端的源IP，因此必须将服务配置文件中的externalTrafficPolicy参数设置为“Local”才能启用此功能。

 { "kind": "Service", "apiVersion": "v1", "metadata": { "name": "example-service", }, "spec": { "端口": [{ "port": 8765, "targetPort": 9376 }], "selector": { "app": "example" }, "type": "LoadBalancer", "externalTrafficPolicy": "Local" } }

使用保留源 IP 的警告和限制

新功能现在在节点级别均匀分配外部流量，而不是按 Pod 均匀分配（GCE/AWS 和其他外部负载）平衡实现没有能力对节点进行加权，因此它们忽略每个节点上的 pod 数量，并将它们均匀分布在所有目标节点上。） p>

但是，对于 pod： 节点数量 (NumServicePods) « 数量节点数 (NumNodes) 或 Pod 数量 (NumServicePods) » 节点数量 (NumNodes)，即使没有加权策略，我看到的情况也非常接近公平分配 /p>

内部 Pod 之间的流量应该与 ClusterIP 类似。

ps

externalTrafficPolicy:Local之后，所有流量应该是相同的，经过一系列iptables和kube-proxy的排查，如果发现需要[。 k4]hostname-override 在 kube-proxy 启动参数中：

[ k4] --hostname-override= $(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef : apiVersion: v1 fieldPath: spec.nodeName

podAntiAffinity 通过 Unbalance 避免 pod 流量

外部流量 我们可以看到它并不是按照 pod 均匀分布，而是均匀分布那么我们能做的就是确保完成相同的业务。d 被调度到不同的节点。

PodAntiAffinity的使用场景：

将服务的POD分布在不同的主机或拓扑域上，以提高服务本身的稳定性。

授予POD对节点的独占访问权限，保证资源隔离，防止其他Pod共享节点资源。

将潜在交互服务的 POD 分发到不同的主机

您可以为亲和性和反亲和性设置三种规则。

p>

RequiredDuringSchedulingRequiredDuringExecution：调度期间必须满足亲和性或反亲和性规则。 如果不满足规则，POD就无法调度到对应的主机上。 在后续的执行过程中，如果由于某种原因（例如标签改变）无法满足规则，系统会尝试将POD从主机上移除（当前版本不支持）。

RequiredDuringSchedulingIgnoredDuringExecution：调度期间必须满足亲和性或反亲和性规则。 如果不满足规则，POD就无法调度到对应的主机上。 在后续运行中，系统将不再检查是否满足这些规则。

PreferredDuringSchedulingIgnoredDuringExecution：确保调度期间满足亲和性或反亲和性规则。 如果不满足规则，POD也可能被调度到相应的主机。 在后续运行中，系统将不再检查是否满足这些规则。

接下来，您的使用场景只能使用RequiredDuringSchedulingIgnoredDuringExecution，并且必须严格保证相同的业务Pod被调度到不同的主机上。 当然，这可能会导致问题。 不符合条件的 Pod 将被搁置。 目前，运维会收到添加节点或删除对业务不重要的 Pod 的通知。

解释示例

apiVersion: v1kind: Podmetadata: name: with-pod-affinityspec:affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: podAffinityTerm: labelSelector: matchExpressions: - key: name operator: In值：- 前端拓扑键：kubernetes.io/hostname 容器：- 名称：with-pod-affinity 镜像：gcr.io/google_containers/pause:2.0

使用 kubernetes 。 使用io/hostname作为拓扑域并显示匹配规则。 即同一个标签name=frontend的同一个pod会被调度到不同的节点上。

亲和/反亲和调度策略比较

标签匹配

算子

拓扑域支持

目标调度

th>

主机

在、不在、存在、DoesNotExist、Gt、Lt

否

Pod 到指定主机

Pod

In、NotIn、Exists、DoesNotExist

是

Pod 与指定 Pod 位于同一拓扑域中

Pod

在、不在、存在、 DoesNotExist

是

Pod 与指定 Pod 不在同一个拓扑域