摘要:使用场景将一个服务的分散在不同的主机或者拓扑域中,提高服务本身的稳定性。示例解读使用作为拓扑域查看匹配规则,即同一打有同样标签的会调度到不同的节点。
externalTrafficPolicy 简介
如果服务需要将外部流量路由到 本地节点或者集群级别的端点,即service type 为LoadBalancer或NodePort,那么需要指明该参数。存在两种选项:”Cluster”(默认)和 “Local”。 “Cluster” 隐藏源 IP 地址,可能会导致第二跳(second hop)到其他节点,但是全局负载效果较好。”Local” 保留客户端源 IP 地址,避免 LoadBalancer 和 NodePort 类型服务的第二跳,但是可能会导致负载不平衡。
在实际的业务中,诸多业务是需要保留客户端源 IP,所以需要通过将服务的配置文件中的 externalTrafficPolicy 参数设置为 “Local” 来激活这个特性。
{ "kind": "Service", "apiVersion": "v1", "metadata": { "name": "example-service", }, "spec": { "ports": [{ "port": 8765, "targetPort": 9376 }], "selector": { "app": "example" }, "type": "LoadBalancer", "externalTrafficPolicy": "Local" } }使用保留源 IP 的警告和限制
新功能中,外部的流量不会按照 pod 平均分配,而是在节点(node)层面平均分配(因为 GCE/AWS 和其他外部负载均衡实现没有能力做节点权重, 而是平均地分配给所有目标节点,忽略每个节点上所拥有的 pod 数量)。
然而,在 pod 数量(NumServicePods) « 节点数(NumNodes)或者 pod 数量(NumServicePods) » 节点数(NumNodes)的情况下,即使没有权重策略,我们也可以看到非常接近公平分发的场景。
内部 pod 对 pod 的流量应该与 ClusterIP 服务类似,流量对于所有 pod 是均分的。
ps设置了externalTrafficPolicy:Local以后svc死活都不能访问,后来经过一系列排查iptables和kube-proxy终于发现了解决办法。
在kube-proxy启动参数里面需要设置--hostname-override:
- --hostname-override=$(NODE_NAME) env: - name: NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName通过podAntiAffinity 避免pod 流量不均衡
竟然外部的流量不会按照 pod 平均分配,而是在节点(node)层面平均分配 ,那么我们能做的只有保证同一业务的pod调度到不同的node节点上。
podAntiAffinity使用场景:
将一个服务的POD分散在不同的主机或者拓扑域中,提高服务本身的稳定性。
给POD对于一个节点的独占访问权限来保证资源隔离,保证不会有其它pod来分享节点资源。
把可能会相互影响的服务的POD分散在不同的主机上
对于亲和性和反亲和性,每种都有三种规则可以设置:
RequiredDuringSchedulingRequiredDuringExecution :在调度期间要求满足亲和性或者反亲和性规则,如果不能满足规则,则POD不能被调度到对应的主机上。在之后的运行过程中,如果因为某些原因(比如修改label)导致规则不能满足,系统会尝试把POD从主机上删除(现在版本还不支持)。
RequiredDuringSchedulingIgnoredDuringExecution :在调度期间要求满足亲和性或者反亲和性规则,如果不能满足规则,则POD不能被调度到对应的主机上。在之后的运行过程中,系统不会再检查这些规则是否满足。
PreferredDuringSchedulingIgnoredDuringExecution :在调度期间尽量满足亲和性或者反亲和性规则,如果不能满足规则,POD也有可能被调度到对应的主机上。在之后的运行过程中,系统不会再检查这些规则是否满足。
那我们的使用场景只能使用RequiredDuringSchedulingIgnoredDuringExecution,要严格保证同一业务pod调度到不同的主机。当然这样可能出现一种问题:不满足条件的pod,会pending。这个时候我们运维会接受到通知,去增加node节点或是驱赶业务不重要的pod。
示例解读apiVersion: v1 kind: Pod metadata: name: with-pod-affinity spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: podAffinityTerm: labelSelector: matchExpressions: - key: name operator: In values: - frontend topologyKey: kubernetes.io/hostname containers: - name: with-pod-affinity image: gcr.io/google_containers/pause:2.0
使用kubernetes.io/hostname作为拓扑域,查看匹配规则,即同一打有同样标签name=frontend的pod会调度到不同的节点。
亲和性/反亲和性调度策略比较调度策略 | 匹配标签 | 操作符 | 拓扑域支持 | 调度目标 |
---|---|---|---|---|
nodeAffinity | 主机 | In, NotIn, Exists, DoesNotExist, Gt, Lt | 否 | pod到指定主机 |
podAffinity | Pod | In, NotIn, Exists, DoesNotExist | 是 | pod与指定pod同一拓扑域 |
PodAntiAffinity | Pod | In, NotIn, Exists, DoesNotExist | 是 | pod与指定pod非同一拓扑域 |
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/32700.html
摘要:使用场景将一个服务的分散在不同的主机或者拓扑域中,提高服务本身的稳定性。示例解读使用作为拓扑域查看匹配规则,即同一打有同样标签的会调度到不同的节点。 externalTrafficPolicy 简介 如果服务需要将外部流量路由到 本地节点或者集群级别的端点,即service type 为LoadBalancer或NodePort,那么需要指明该参数。存在两种选项:Cluster(默认)...
摘要:如何在启用的集群中设置的为关于的和两个值,在之前的文章中,我们已经讲过。首先保证启动参数里加入设置然后需要设置的为。参考资料当您创建时,我们会自动创建选项集,并将它们与相关联。 如何在启用cloud-provider=aws的k8s集群中设置service 的externalTrafficPolicy为local 关于externalTrafficPolicy的local和cluste...
摘要:如何在启用的集群中设置的为关于的和两个值,在之前的文章中,我们已经讲过。首先保证启动参数里加入设置然后需要设置的为。参考资料当您创建时,我们会自动创建选项集,并将它们与相关联。 如何在启用cloud-provider=aws的k8s集群中设置service 的externalTrafficPolicy为local 关于externalTrafficPolicy的local和cluste...
摘要:原因解释创建成功后,的将集群中的每个云主机节点作为自身的节点,端口为申明的值注意不是。如何获取源对于需要明确知道客户端来源地址的情况,我们需要显示地将的设置成如下修改。重新部署服务后,再用浏览器访问,可以发现正确获取了浏览器的访问。ULB属性修改的处理方法如没有实际需要,请避免修改ULB名称及注释根据cloudprovider插件使用提醒,由UK8S cloudprovider创建的ULB不...
摘要:的调度机制组件调度器会将调度到资源满足要求并且评分最高的上。这个特性的设计初衷是为了替代,并扩展更强大的调度策略。和完全相同,以进行强制的约束。软规则除了,,还有一条软规则配置后,没有相关污点策略的会尽量避免调度到该上。 k8s的调度机制 scheduler组件 k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们可以使用多种规则比如:1.设置cpu、内存的使用要求;...
阅读 2081·2021-10-14 09:43
阅读 2178·2019-08-30 15:55
阅读 713·2019-08-30 14:23
阅读 1994·2019-08-30 13:21
阅读 1218·2019-08-30 12:50
阅读 2178·2019-08-29 18:46
阅读 2263·2019-08-29 17:28
阅读 2336·2019-08-29 17:21