资讯专栏INFORMATION COLUMN

从service的externalTrafficPolicy到podAntiAffinity

ztyzz / 418人阅读

摘要:使用场景将一个服务的分散在不同的主机或者拓扑域中,提高服务本身的稳定性。示例解读使用作为拓扑域查看匹配规则,即同一打有同样标签的会调度到不同的节点。

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

相关文章

  • serviceexternalTrafficPolicypodAntiAffinity

    摘要:使用场景将一个服务的分散在不同的主机或者拓扑域中,提高服务本身的稳定性。示例解读使用作为拓扑域查看匹配规则,即同一打有同样标签的会调度到不同的节点。 externalTrafficPolicy 简介 如果服务需要将外部流量路由到 本地节点或者集群级别的端点,即service type 为LoadBalancer或NodePort,那么需要指明该参数。存在两种选项:Cluster(默认)...

    JerryZou 评论0 收藏0
  • k8s与aws--如何在cloud-provider=awsk8s中设置externalTraff

    摘要:如何在启用的集群中设置的为关于的和两个值,在之前的文章中,我们已经讲过。首先保证启动参数里加入设置然后需要设置的为。参考资料当您创建时,我们会自动创建选项集,并将它们与相关联。 如何在启用cloud-provider=aws的k8s集群中设置service 的externalTrafficPolicy为local 关于externalTrafficPolicy的local和cluste...

    chanjarster 评论0 收藏0
  • k8s与aws--如何在cloud-provider=awsk8s中设置externalTraff

    摘要:如何在启用的集群中设置的为关于的和两个值,在之前的文章中,我们已经讲过。首先保证启动参数里加入设置然后需要设置的为。参考资料当您创建时,我们会自动创建选项集,并将它们与相关联。 如何在启用cloud-provider=aws的k8s集群中设置service 的externalTrafficPolicy为local 关于externalTrafficPolicy的local和cluste...

    zhoutk 评论0 收藏0
  • 【容器云 UK8S】服务发现:ULB属性修改处理方法和获取真实客户端IP

    摘要:原因解释创建成功后,的将集群中的每个云主机节点作为自身的节点,端口为申明的值注意不是。如何获取源对于需要明确知道客户端来源地址的情况,我们需要显示地将的设置成如下修改。重新部署服务后,再用浏览器访问,可以发现正确获取了浏览器的访问。ULB属性修改的处理方法如没有实际需要,请避免修改ULB名称及注释根据cloudprovider插件使用提醒,由UK8S cloudprovider创建的ULB不...

    Tecode 评论0 收藏0
  • kubernetes调度机制

    摘要:的调度机制组件调度器会将调度到资源满足要求并且评分最高的上。这个特性的设计初衷是为了替代,并扩展更强大的调度策略。和完全相同,以进行强制的约束。软规则除了,,还有一条软规则配置后,没有相关污点策略的会尽量避免调度到该上。 k8s的调度机制 scheduler组件 k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们可以使用多种规则比如:1.设置cpu、内存的使用要求;...

    selfimpr 评论0 收藏0

发表评论

0条评论

ztyzz

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<