引子
kubernetes中的概念比较多,对入门或理解kubernetes会造成一定的难度,尤其是有些概念有相近之处,更加让初学者摸不着头脑。
所以对于概念之间的联立比较,区别它们之间的异同,对清晰的理解kubernetes中的有关概念有很大的帮助。
service和kube-proxy是kubernetes中比较容易搞混的概念组了,两者好像都与负载均衡和流量转发有关,那本文就清晰的来辨析一下这两个概念
概念
kube-proxy
kube-proxy是Kubernetes的核心组件,部署在每个Node节点上,它是实现Kubernetes Service的通信与负载均衡机制的重要组件; kube-proxy负责为Pod创建代理服务,从apiserver获取所有server信息,并根据server信息创建代理服务,实现server到Pod的请求路由和转发,从而实现K8s层级的虚拟转发网络。
service
在k8s中,提供相同服务的一组pod可以抽象成一个service,通过service提供的统一入口对外提供服务,每个service都有一个虚拟IP地址(VIP)和端口号供客户端访问。kube-proxy存在于各个node节点上,主要用于Service功能的实现,具体来说,就是实现集群内的客户端pod访问service,或者是集群外的主机通过NodePort等方式访问service。
比如现在有podA,podB,podC和serviceAB。serviceAB是podA,podB的服务抽象(service)。那么kube-proxy的作用就是可以将pod(不管是podA,podB或者podC)向serviceAB的请求,进行转发到service所代表的一个具体pod(podA或者podB)上。请求的分配方法一般分配是采用轮询方法进行分配。另外,kubernetes还提供了一种在node节点上暴露一个端口,从而提供从外部访问service的方式。比如这里使用这样的yaml来创建service
apiVersion: v1
kind: Service
metadata:
labels:
name: mysql
role: service
name: mysql-service
spec:
ports:
- port: 3306
targetPort: 3306
nodePort: 30964
type: NodePort
selector:
mysql-service: "true"
上面配置的含义是在node上暴露出30964端口。当访问node上的30964端口时,其请求会转发到service对应的cluster IP的3306端口,并进一步转发到pod的3306端口。
访问Service的请求,不论是Cluster IP+TargetPort的方式;还是用Node节点IP+NodePort的方式,都被Node节点的Iptables规则重定向到Kube-proxy监听Service服务代理端口。kube-proxy接收到Service的访问请求后,根据负载策略,转发到后端的Pod。
区别
- kube-proxy是kubernetes的核心组件,也就是集群安装了就会有的,而service是kubernetes的资源对象,是要操作生成的。
- kube-proxy是部署在work节点上,service是根据master的调度来分配的。
联系
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡,它运行在每个Node计算节点上,负责Pod网络代理, 它会定时从etcd服务获取到service信息来做相应的策略,维护网络规则和四层负载均衡工作。在K8s集群中微服务的负载均衡是由Kube-proxy实现的,它是K8s集群内部的负载均衡器,也是一个分布式代理服务器,在K8s的每个节点上都有一个,这一设计体现了它的伸缩性优势,需要访问服务的节点越多,提供负载均衡能力的Kube-proxy就越多,高可用节点也随之增多。
Kube-proxy进程获取每个Service的Endpoints(实际上就是pod的ip加上端口),实现Service的负载均衡功能
Service 在 kubernetes 中的四种类型
- ClusterIp: 默认类型,自动分配一个仅 Cluster 内部可以访问的虚拟IP
- NodePort: 在 ClusterlP 基础上为 Service 在台机器上绑定一个端口,这样就叫以通过:NodePort来访问该服务
- LoadBalancer: 在 NodePort 的基础上,借肋 cloud provider 创建一个外部负载均衡器,将清求转发到:NodePort
- ExternalName: 把集群外部的服务引入到集群内部来,在集群内部直接使用。没有任何类型代理被创建,这只有 kubernetes 1.7 更高版本的 kube-dns 才支持。
kube-proxy的三种模式
kube-proxy当前实现了三种代理模式:userspace, iptables, ipvs。
其中userspace mode是v1.0及之前版本的默认模式,从v1.1版本中开始增加了iptables mode,在v1.2版本中正式替代userspace模式成为默认模式。也就是说kubernetes在v1.2版本之前是默认模式, v1.2版本之后默认模式是iptables。
iptables mode, 该模式完全利用内核iptables来实现service的代理和LB, 这是K8s在v1.2及之后版本默认模式.
ipvs mode. 在kubernetes 1.8以上的版本中,对于kube-proxy组件增加了除iptables模式和用户模式之外还支持ipvs模式。kube-proxy ipvs 是基于 NAT 实现的,通过ipvs的NAT模式,对访问k8s service的请求进行虚IP到POD IP的转发。当创建一个 service 后,kubernetes 会在每个节点上创建一个网卡,同时帮你将 Service IP(VIP) 绑定上,此时相当于每个 Node 都是一个 ds,而其他任何 Node 上的 Pod,甚至是宿主机服务(比如 kube-apiserver 的 6443)都可能成为 rs;
总结
从本文中可以理解kube-proxy和service是有区别有紧密联系的概念。
kube-proxy是kubernetes的核心组件,部署在work节点上。service是kubernetes的资源对象,跟据master的调度来分配的。
service更类似于一个域名一样的,接收流量进来,让kube-proxy具体干活。
service对外暴露一个Virtual IP,也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的serivce下的Pod。
service另外一个重要作用是,一个服务后端的Pods可能会随着生存灭亡而发生IP的改变,service的出现,给服务提供了一个固定的IP,而无视后端Endpoint的变化。
kube-proxy有三种代理模式:userspace, iptables, ipvs。
Service 有四种类型:ClusterIp,NodePort,LoadBalancer,ExternalName。
评论区