侧边栏壁纸
博主头像
问道

问道的小花园,总能给你带来惊喜

  • 累计撰写 33 篇文章
  • 累计创建 22 个标签
  • 累计收到 3 条评论

kubernetes核心对象辨析:service和kube-proxy的理解与区别

问道
2022-08-12 / 1 评论 / 0 点赞 / 476 阅读 / 2,980 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-08-12,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

引子

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。

区别

  1. kube-proxy是kubernetes的核心组件,也就是集群安装了就会有的,而service是kubernetes的资源对象,是要操作生成的。
  2. 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。

0

评论区