每种类型的Service适合怎样的场景以及kube-proxy是如何实现Service负载均衡是本文的重点
Kube-Proxy运行机制详解
在Kubernetes集群中的每个Node上都会运行一个Kube-proxy服务进程,每个kube-proxy都充当一个负载均衡器,这是一个分布式的负载均衡器,我们可以把这个进程看作是透明代理兼负载均衡器,核心功能就是将访问到某个Service的请求转发到该Service对应的真实后端Pod上.
Service的ClusterIP和NodePort的实现方式都是kube-proxy服务通过iptables的NAT转换实现的
比如从Node1主机上访问Service和Node1上的Pod访问Service
1.每个Node上的kube-proxy都会绑定集群内所有Service的IP到本机的kube-ipvs0的网卡上,如下图
这个作用就是:让数据包经过本机的INPUT链
2.通过socket调用,创建IPVS的virtual server和real server,分别对应Kubernetes的Service和EndPoints
3.发起请求后,通过kube-proxy请求先到本机,因为kube-proxy为本机绑定了对应的ServiceIP
4.然后通过kube-proxy创建的规则,把请求直接转发到对应的Pod 进行处理
内部Node1节点上通过ClusterIP访问Service和Node1节点上的Pod通过ClusterIP访问Service:
由于Node1本机绑定了所有的ServiceIP,所以请求到达Node1本机的Kube-proxy,然后Node1本机的kube-Proxy创建的规则将请求转发到对应的后端真实Pod
内部Node2节点上通过ClusterIP访问Service和Node2节点上的Pod通过ClusterIP访问Service:
由于Node2本机绑定了所有的ServiceIP,所以请求到达Node2本机的Kube-proxy,然后Node2本机的kube-Proxy创建的规则将请求转发到对应的后端真实Pod
外部通过NodePort访问:
就是请求先到Node的端口,然后通过kube-proxy转发到对应的pod直接处理
Service和Kube-Proxy在Kubernetes集群中的工作原理
Kube-proxy在集群中的作用
1.运行在每个Node节点的Kube-Proxy会实时的watch Service和Endpoints对象
当用户在kubernetes集群中创建了含有label的Service之后,同时会在集群中创建出一个同名的Endpoints对象,用于存储该service下的Pod IP
2.每个运行在Node节点的Kube-Proxy感知到Service和Endpoints的变化之后,会在各自的Node节点设置相关的iptables或IPVS转发规则,用于之后用户通过Service的ClusterIP去访问该Service下的服务
3.当Kube-Proxy把需要的规则设置完成后,用户就可以在集群内的Node或客户端Pod上通过ClusterIP经过该节点下的Iptales或IPVS设置的规则进行路由和转发后 直接将请求发送到真实的后端Pod
Service类型
ClusterIP
ClusterIP 类型的 Service 是 Kubernetes 集群默认的 Service, 它只能用于集群内部通信(比如通过集群内Node节点访问Service或者Pod里访问Service);不能用于外部通信
NodePort
如果你想要在集群外访问集群内部的服务，你可以使用这种类型的 Service。NodePort 类型的 Service 会在集群内部的所有 Node 节点打开一个指定的端口。之后所有的流量直接发送到这个端口之后，就会转发的 Service 去对真实的服务进行访问