当前位置:   article > 正文

k8s clusterip 方式service负载均衡实现三种方式及原理_clusterip 原理

clusterip 原理

k8s Service详解(概念、原理、流量分析、代码) - sucre_tan - 博客园

补充说明:

ClusterIP方式原理

kubernetes中kube-proxy的工作原理是什么 - 云计算 - 亿速云

Kubernetes中的负载均衡原理————以iptables模式为例 | CITAHub技术团队

kube-proxy & service

  • kube-proxy其实就是管理service的访问入口,包括集群内Pod到Service的访问和集群外访问service。

  • kube-proxy管理sevice的Endpoints,该service对外暴露一个Virtual IP,也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的serivce下的Pod。

  • service是通过Selector选择的一组Pods的服务抽象,其实就是一个微服务,提供了服务的LB和反向代理的能力,而kube-proxy的主要作用就是负责service的实现。

  • service另外一个重要作用是,一个服务后端的Pods可能会随着生存灭亡而发生IP的改变,service的出现,给服务提供了一个固定的IP,而无视后端Endpoint的变化。

服务发现

k8s提供了两种方式进行服务发现:

  • 环境变量: 当你创建一个Pod的时候,kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意的是,要想一个Pod中注入某个Service的环境变量,则必须Service要先比该Pod创建。这一点,几乎使得这种方式进行服务发现不可用。

    比如,一个ServiceName为redis-master的Service,对应的ClusterIP:Port为10.0.0.11:6379,则其对应的环境变量为:

 
  1. REDIS_MASTER_SERVICE_HOST=10.0.0.11

  2. REDIS_MASTER_SERVICE_PORT=6379

  3. REDIS_MASTER_PORT=tcp://10.0.0.11:6379

  4. REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379

  5. REDIS_MASTER_PORT_6379_TCP_PROTO=tcp

  6. REDIS_MASTER_PORT_6379_TCP_PORT=6379

  7. REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

  • DNS:这也是k8s官方强烈推荐的方式。可以通过cluster add-on的方式轻松的创建KubeDNS来对集群内的Service进行服务发现。更多关于KubeDNS的内容,请查看:Kubernetes DNS Service技术研究 - 爱码网 。

服务发布类型ServiceType

k8s原生的,一个Service的ServiceType决定了其发布服务的方式。

  • ClusterIP在集群内发布服务,这是k8s默认的ServiceType。通过集群内的ClusterIP在内部发布服务,只能够在集群内部访问服务。

  • ExternalName用于集群内不同命名空间内的服务通过名称可直接访问,以及将在k8s集群外部的服务引入到k8s集群内通过服务名称访问场景。需要借助KubeDNS(version >= 1.7)的支持,就是用KubeDNS将该service和ExternalName做一个Map,KubeDNS返回一个CNAME记录。
    ExternalName的用途(业务场景),有两个:
    (1)将k8s集群内在某个namespace内的服务暴露到另外一个namespace内,实现两个不同的namespace之间的不同pod可以通过name的形式访问。假如集群内有两个服务服务a和b,a服务访问b服务。若两个服务都定义在同一个namespaceA下,则a可以通过b的名称http://b/访问b服务,k8s会将http://b/转为http://b.namespaceA.svc.cluster.local/ svc.cluster.local 是整个k8s集群的域),若将b定义在namespaceB访问,则A无法直接通过b的名称http://b/访问服务b,因为b的namespace不是namespaceA。若想仍然通过http://b访问,可以在namespaceA下定义一个type为ExternalName的服务b,其externalName属性的值为b.namespaceB.svc.cluster.local即可,相当于在namespaceA下为定义在namespaceB下的服务b建了一个链接,连接名为b。namespaceA下的ExternalName服务b定义如下:

     
      
    1. apiVersion: v1

    2. kind: Service

    3. metadata:

    4. name: b

    5. namespace: namespaceA

    6. spec:

    7. type: ExternalName

    8. externalName: b.namespaceB.svc.cluster.local

      (2)将k8s集群外的服务引入到k8s内部,供内部的pod访问,就像使用集群内的服务一样使用外部服务,利用ExternalName的Service访问的外部服务地址必须是域名,不支持IP地址。举例参见下方k8s集群内部与外部之间互联互通#通过ExternalName Service访问域名方式的外部服务

  • NodePort用来对集群外暴露k8s内部的Service。NodePort 服务会路由到 ClusterIP 服务,这个 ClusterIP 服务会自动创建,同时,k8s会在集群内所有node上,为集群内的所有NodePort类型的服务暴露其NodePort,这样集群外部可以连接到集群内任何一个node的ip:nodePort即可以访问该服务。这种方式的缺点比较多:每个端口只能是一种服务;端口范围只能是 30000-32767,不推荐采用这种方式对集群外暴露服务NodePort 需要借助真实存在的ip,是一个公共的ip,任何人都可以访问,而ClusterIP可以理解成不对外开放,仅限于集群内的节点之间特定的一个范围。
  • LoadBalancer: 也是用来对集群外暴露k8s内部的Service。使用云提供商的负载局衡器,可以路由到 NodePort 服务和 ClusterIP 服务,这个需要结合具体的云厂商进行操作。所有通往指定的端口的流量都会被转发到对应的服务。它没有过滤条件,没有路由等。这意味着你几乎可以发送任何种类的流量到该服务,像 HTTP,TCP,UDP,Websocket,gRPC 或其它任意种类。这个方式的最大缺点是每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址,每个用到的 LoadBalancer 都需要付费,这将是非常昂贵的。

kube-proxy负载均衡原理

k8s借助kube-proxy实现负载均衡。

kube-proxy实现了三种代理模式:

  • userspace代理模式:v1.0及之前版本的默认模式,来回在用户空间和内核空间切换,存在严重的性能问题,不推荐
  • iptables代理模式:从v1.1版本中开始增加了iptables mode,在v1.2版本中正式替代userspace模式成为默认模式。将k8s整个集群的service和endpoints路由都写到iptables中,当service数量较大时,同样存在严重的性能问题,且负载均衡能力比较简单,不推荐
  • IPVS代理模式:v1.9之后引入,通过维护ipvs规则和ipset两种高效的数据结构,使得iptables规则不再随着service数量增加而增加,这也是ipvs模式在大规模场景下比iptables模式性能更优越的原因,且支持丰富的负载均衡算法。推荐。

以上三种方式,都是利用客户端的OS的网络内核(iptables规则)拦截到ClusterIP:ClusterPort的请求,因此是客户端实现的负载均衡。

userspace 代理模式

userspace是在用户空间,通过kube-proxy来实现service的代理服务,其原理如下如图所示:

iptables代理模式

这种方式完全利用内核iptables来实现service的代理和LB。是v1.2及之后版本默认模式,其原理图如下所示:

说明:

  • k8s集群中所有node的iptables规则中均配置了整个k8s集群中所有的Service的ClusterIP:ClusterPort到对应的endpoint列表的路由规则。
  • iptables规则会拦截client端发起的到ClusertIP:ClusterPort的请求,实现了请求转发到某个具体的Endpoint,同时实现了负载均衡和会话保持功能。
  • iptables规则借助statistic模块实现负载均衡,以random方式均衡的分发流量,也即负载均衡模式为简单的轮询无法实现复杂的如最小链接分发方式,鉴于此,K8S 1.9后续版本调整了kube-proxy服务,其可通过ipvs实现Service负载均衡功能
  • iptables规则借助recent模块,实现会话保持功能。可以通过Service对象的sessionAffinity属性配置 session 亲和,目前可以有两种取值,一种是 None,也是默认值,表示没有,会直接轮询 Pod。一种是 ClientIP,表示根据客户端 IP 亲和,同一个客户端 IP,会被发送到同一个 Pod 上。
  • 我们提到了kube-proxy iptables模式在大规模场景下会生成众多的iptables规则,而这些iptables规则是链式顺序匹配的,这样会大大降低网络访问性能。

iptables最初也不是为了负载均衡而设计,而纯粹是为了防火墙而设计。为了解决iptables模式下的性能问题,kube-proxy引入了一个更适合负载均衡场景且有更高效数据结构(散列表)的模块——ipvs。

IPVS代理模式

k8s网络原理-ipvs - 简书

kube-proxy ipvs模式原理分析 - 墨天轮

说明:

  • 通过创建kube-ipvs0 dummy网卡并绑定service ip,使得从外部进来的流量在PREROUTING后的路由决策中发往INPUT,从而能到达ipvs模块。

  • ipvs模式下通过维护ipvs规则和ipset两种高效的数据结构,使得iptables规则不再随着service数量增加而增加,这也是ipvs模式在大规模场景下比iptables模式性能更优越的原因。

  • 外部访问service ip的链路为:PREROUTING->route->INPUT->ipvs(DNAT)->OUTPUT->route->POSTROUTING

  • 宿主机上访问service ip的链路为:OUTPUT->ipvs(DNAT)->OUTPUT->route->POSTROUTING

  • ipvs只做了DNAT,部分场景下仍需要iptables做SNAT。

k8s集群内部与外部之间互联互通

从k8s集群外部访问k8s

可通过NodePort、LoadBalancer和Ingeress方式,从k8s集群外部访问k8s内部的服务。

区别参见:K8S ClusterIP、 NodePort、LoadBalancer和Ingress 区别 - 王叫兽 - 博客园

将k8s集群外部的服务接入k8s集群内部

 参见:【k8s学习】ExternalName Service介绍以及Endpoints+Headless Service介绍 - 简书 

有以下几种方式:

  • 利用ConfigMap+环境变量访问外部服务:ConfigMap配置外部服务的地址(ip或域名均可),在源端容器中定义环境变量,并从ConfigMap映射。这种方式的问题:需要编写额外的程序代码以从环境变量中读取外部服务地址,另外如果外部服务地址发生变化,需要重启所有正在运行的容器以获取更新后的服务地址,故不推荐这种方案
  • 通过ExternalName Service访问域名方式的外部服务。通过ExternalName Service定义k8s内部服务名到外部服务名的映射,即可在k8s内部访问外部服务,无需编写额外的程序代码读取环境变量,地址发生变更后,只需要ExternalName Service配置即可动态生效,不需要重启容器。这种方式的问题:外部服务名必须是域名,不支持IP地址。

    举例:以下配置可在集群内通过https://baidu-service/访问https://www.baidu.com/:
     
      
    1. apiVersion: v1

    2. kind: Service

    3. metadata:

    4. name: baidu-service

    5. namespace: namespaceA

    6. spec:

    7. type: ExternalName

    8. externalName: www.baidu.com

  • 通过无Pod选择器的Service+Endpoints访问外部服务。当外部服务的访问地址是ip地址时,无法通过ExternalName service访问外部服务。此时需要创建一个没有 Pod 选择器的Service和一个Endpoints,Endpoints对象通过subsets指向外部服务的ip和端口(若外部服务是一个集群,即有多个服务实例,均可以定义在subsets中,k8s会在所有服务地址之间进行流量的负载平衡)。

    例如一个外部游戏服务,其访问地址为http://192.168.3.175::8091/,想引入k8s集群内部,且希望通过http://games/访问(pod通过名称访问游戏服务,而非写死且可能会发生变更的ip地址),则对应的Headless Service和Endpoint定义如下:
     
     
      
    1. #Service定义,可以是Headless Service,也可以是普通的Service。

    2. #注意这里没有pod选择器,因此它不知道往哪里转发流量。

    3. #因此需手动创建一个将从此服务接收流量的 Endpoints 对象(见下方Endpoints定义)

    4. apiVersion: v1

    5. kind: Service

    6. metadata:

    7. name: games

    8. spec:

    9. #clusterIP: None表示headless service

    10. #clusterIP: None

    11. type: ClusterIP

    12. ports:

    13. - port: 80

    14. targetPort: 8091

    15. #EndPoints定义,接收上方Service转发的流量(name要与Service的name相同)

    16. #并将流量转发到真正的外部服务192.168.3.175:8091上

    17. #若相同的外部服务有多个ip:port,则可以都定义在subsets中

    18. #k8s会在所有服务地址之间进行流量的负载平衡

    19. apiVersion: v1

    20. kind: Endpoints

    21. metadata:

    22. name: games

    23. subsets:

    24. - addresses:

    25. - ip: 192.168.3.175

    26. ports:

    27. - port: 8091

client Pod访问服务的处理过程如下:

  1. clientPod访问serviceName:servicePort
  2. 服务发现:k8s的cube-dns服务,将serviceName:servicePort解析为serviceIP:servicePort
  3. 请求被cube-proxy
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/IT小白/article/detail/764476
推荐阅读
相关标签
  

闽ICP备14008679号