引子
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。
评论区