美文网首页
Kubernetes Service原理解析

Kubernetes Service原理解析

作者: 伊凡的一天 | 来源:发表于2020-01-20 11:51 被阅读0次

    Service 是为一组具有相同功能的Pod提供一个统一的入口地址,并将请求进行负载均衡地分发到各个Pod上。

    Service 类型

    ClusterIP

    ClusterIP类型的Service是Kubernetes集群默认的Service, 它只能用于集群内部通信。不能用于外部通信。K8s会为每个Service分配一个虚拟IP,即ClusterIP。这个虚拟IP只能在集群内部访问。


    clusterIP.png

    NodePort

    。NodePort类型的Service会在集群内部的所有Node节点打开一个指定的端口。之后所有的流量直接发送到这个端口之后,就会转发的Service去对真实的服务进行访问。


    nodeport.png

    LoadBalancer

    LoadBalancer类型的Service通常和云厂商的LB结合一起使用,用于将集群内部的服务暴露到外网,云厂商的LoadBalancer会给用户分配一个IP,之后通过该IP的流量会转发到你的Service。


    loadbalancer.png

    Ingress

    Ingress 其实不是Service的一个类型,但是它可以作用于多个Service,作为集群内部服务的入口。Ingress 能做许多不同的事,比如根据不同的路由,将请求转发到不同的Service上等等。


    ingress.png

    Service 服务发现的方式

    虽然Service解决了Pod的服务发现问题,但不提前知道Service的IP,怎么发现service服务呢?k8s提供了两种方式进行服务发现:

    • 环境变量: 当创建一个Pod的时候,kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意的是,要想一个Pod中注入某个Service的环境变量,则必须Service要先比该Pod创建。这一点,几乎使得这种方式进行服务发现不可用。
    • DNS:可以在集群中部署CoreDNS服务(旧版本的kubernetes集群使用的是kubeDNS), 来达到集群内部的Pod通过DNS的方式进行集群内部各个服务之间的通讯。

    服务发现原理

    Endpoint

    endpoint是k8s集群中的一个资源对象,存储在etcd中,用来记录一个service对应的所有pod的访问地址。service配置selector,endpoint controller才会自动创建对应的endpoint对象;否则,不会生成endpoint对象。
    例如,k8s集群中创建一个名为k8s-classic-1113-d3的service,就会生成一个同名的endpoint对象,如下图所示。其中ENDPOINTS就是service关联的pod的ip地址和端口。


    endpoint.png

    endpoint controller是k8s集群控制器的其中一个组件,其功能如下:

    • 负责生成和维护所有endpoint对象的控制器
    • 负责监听service和对应pod的变化
    • 监听到service被删除,则删除和该service同名的endpoint对象
    • 监听到新的service被创建,则根据新建service信息获取相关pod列表,然后创建对应endpoint对象
    • 监听到service被更新,则根据更新后的service信息获取相关pod列表,然后更新对应endpoint对象
    • 监听到pod事件,则更新对应的service的endpoint对象,将podIp记录到endpoint中

    负载均衡

    kube-proxy负责service的实现,即实现了k8s内部从pod到service和外部从node port到service的访问。
    kube-proxy作为一个控制器,作为k8s和Linux kernel Netfilter交互的一个枢纽。监听kubernetes集群Services和Endpoints对象的变化,并根据kube-proxy不同的模式(iptables or ipvs), 对内核设置不同的规则,来实现路由转发。

    如果kube-proxy采用iptables的方式配置负载均衡,基于iptables的kube-proxy的主要职责包括两大块:一块是侦听service更新事件,并更新service相关的iptables规则,一块是侦听endpoint更新事件,更新endpoint相关的iptables规则(如 KUBE-SVC-链中的规则),然后将包请求转入endpoint对应的Pod。如果某个service尚没有Pod创建,那么针对此service的请求将会被drop掉。

    iptable的使用

    在Iptables模式下,kube-proxy通过在目标node节点上的Iptables中的NAT表的PREROUTIN和POSTROUTING链中创建一系列的自定义链(这些自定义链主要是”KUBE-SERVICE”链, “KUBE-POSTROUTING”链,每个服务对应的”KUBE-SVC-XXXXXX”链和”KUBE-SEP-XXXX”链),然后通过这些自定义链对流经到该Node的数据包做DNAT和SNAT操作从而实现路由,负载均衡和地址转化。

    NAT(Network Address Translation,网络地址转换)是将IP 数据包头中的IP 地址转换为另一个IP 地址的过程。SNAT: Source Network Address Translation,是修改网络包源ip地址的。DNAT: Destination Network Address Translation,是修改网络包目的ip地址的。

    kube-proxy中,客户端的请求数据包在Iptables规则中具体的匹配过程为:

    1. PREROUTING链或者OUTPUT链(集群内的Pod通过clusterIP访问Service时经过OUTPUT链, 而当集群外主机通过NodePort方式访问Service时,通过PREROUTING链,两个链都会跳转到KUBE-SERVICE链)

    2. KUBE-SERVICES链(每一个Service所暴露的每一个端口在KUBE-SERVICES链中都会对应一条相应的规则,当Service的数量达到一定规模时,KUBE-SERVICES链中的规则的数据将会非常的大,而Iptables在进行查找匹配时是线性查找,这将耗费很长时间,时间复杂度O(n))。

    3. KUBE-SVC-XXXXX链 (在KUBE-SVC-XXXXX链中(后面那串 hash 值由 Service 的虚 IP 生成),会以一定的概率匹配下面的某一条规则执行,通过statistic模块为每个后端设置权重,已实现负载均衡的目的,每个KUBE-SEP-XXXXX链代表Service后面的一个具体的Pod(后面那串 hash 值由后端 Pod 实际 IP 生成),这样便实现了负载均衡的目的)

    4. KUBE-SEP-XXXX链 (通过DNAT,将数据包的目的IP修改为服务端的Pod IP)

    通过上面的这个设置便实现了基于Iptables实现了负载均衡。但是Iptbles做负载均衡存在一些问题:

    • 规则线性匹配时延: KUBE-SERVICES链挂了一长串KUBE-SVC-*链,访问每个service,要遍历每条链直到匹配,时间复杂度O(N)
    • 规则更新时延: 非增量式,需要先iptables-save拷贝Iptables状态,然后再更新部分规则,最后再通过 iptables-restore写入到内核。当规则数到达一定程度时,这个过程就会变得非常缓慢。
    • 可扩展性: 当系统存在大量的Iptables规则链时,增加/删除规则会出现kernel lock,这时只能等待。
    • 可用性: 服务扩容/缩容时, Iptables规则的刷新会导致连接断开,服务不可用。

    更多iptable的实现,请参考:https://xigang.github.io/2019/07/21/kubernetes-service/

    为了解决Iptables当前存在的这些问题,华为开源团队的同学为社区贡献了IPVS模式。请参考:https://xigang.github.io/2019/07/21/kubernetes-service/

    参考文章

    相关文章

      网友评论

          本文标题:Kubernetes Service原理解析

          本文链接:https://www.haomeiwen.com/subject/rnkjzctx.html