kube-proxy 三种模式分析
kubernetes 上面的 service 资源的实现方式是由 kube-proxy 提供的模式决定的
kube-proxy 提供三种模式:userspace (Kubernetes1.2版本之前)、iptables、ipvs(推荐的)
如果不满足ipvs时,会自动降为iptables模式
再讲三种模式前,先简单说下Service的工作原理;
在 kubernetes 平台之上,Pod 是由生命周期的,为了给客户端提供一个固定的访问端点,因此我们在客户端与服务端(pod)之间加了一层固定的中间层,这个中间层,我们称它为 Service,当某个 service 服务背后资源发生了改变时,service 根据标签选择器,会立即判断是 pod 多了一个还是少了一个,这种信息会立即反应到 API server 上,因为多个 pods 的信息是需要存在 kube-apiserver 的 etcd 中的,而 kube-proxy 能够 watch(监控) 到这种变化,并立即将其转化为 ipvs 规则或者 iptables 规则 ,它的转换是动态的,并且是实时的,同理如果一个pod 被删除了,它的状态信息也会反馈到 kube-apiserver 的 etcd 当中,而后这种变化会被kube-proxy watch监控到,它会立即将其转化为 iptables 或者 IPVS 规则,基本上都是立即同步的。
userspace
当client pod 访问某个服务时,会先到达当前节点的内核空间 iptables 规则(我们知道 iptables规则就是 service 的规则),这个 service 规则的工作方式是 ,请求到达 service 以后,由 service 把它转化为本地监听到某个套接字上面的用户空间程序 kube-proxy,然后由它来处理,处理完以后再转给 service IP,最终代理到这个 service 关联和各个 pod, 实现调度,大家发现,这个请求由 client Pod 发给 service,service 还要回到监听这个端口的 kube-proxy, 再由 kube-proxy 再进行分发,kube-proxy 是工作在用户空间的进程,所以被称为userspace,这种方式,效率很低,原因在于,先要到内核空间,回到 kube-proxy 的用户空间,由各种 kube-proxy 封装成报文代理完成以后,再推到内核空间,然后有 iptables 规则进行转发,需要在内核空间与用户空间来回转换 2 次,效率低下。
iptables
客户端 client Pod 发起请求时,直接请求 serviceIP,这个请求报文在本地内核空间中的serivce 规则所截取,直接调度到 server pod 上面,工作在内核空间,直接由 iptables 规则直接负责调度,前面哪种方式是由工作在 userspace 用户空间的 kube-proxy 方式进行调度,他们两个不同,而这种方式叫 iptables 实现;iptables 与之前 userspace 相比,完全工作在内核态而且不用在经过 kube-proxy 中转一次,不需要用户空间与内核空间来回调度,只需要在内核空间就完成了,iptables 模式性能更强,但这样有一个缺点,随着集群规模的扩大,iptables 数量会增加的比较快,不太适合大规模使用,所以就有了下面的 ipvs 模式。
IPVS
IPVS 知识点可以查看另外一篇文章:xxxxx客户端 client Pod 的请求到达内核空间以后,由 ipvs 规则来调度,内核空间直接调度给 pod 资源,所以第三种模型叫 IPVS 模型,ipvs 的工作过程上面已经讲的很清楚。
由于 kube-proxy 的 ipvs 模式需要提供 iptables 包过滤、SNAT、masquared(伪装)等,具体来说,ipvs 将使用 ipset 来存储需要 DROP 或 masquared 的流量的源或目标地址的规则集,以确保 iptables 规则的数量是恒定的,不会因为集群规模的扩大,而 iptables 条目增加,这里有一个关键是 SNAT,端口转换,通过上面的分析,我们只能使用 ipvs 的 NAT 模式。
很显然我们在安装并配置 kubernetes 的时候,你设定service工作在什么模式下,它就应该会生成对应的模式的规则,kubernetes 1.10 之前的版本,使用的是 iptables 规则,Kubernetes 1.2 版本之前是使用的 userspace 的模式,kubernetes 1.11 及以后默认使用的是 ipvs,如果ipvs 没有被激活,它将自动降级为 iptables 模式。
ipvs与iptables模式对比
ipvs 在大型集群规模部署时,性能更好;
ipvs 可以动态修改 ipset 集合;
ipvs 支持更为复杂的调度算法(最小负载、最少连接、加权等);
ipvs 支持服务器健康检查和连接重试等;
ipvs 是否可以满足所有场景
从上面看 ipvs 有这么多的好处?
那么是 ipvs 是否可以满足所有场景呢?答案是否定的?
因为 ipvs 无法提供包过滤、SNAT、masquared等功能,在某些场景下,还是需要与 iptables 搭配使用(如 Service 类型为 NodePort 时),ipvs 使用 ipset 来存储需要 DROP 或 masquared 的流量的源或目标地址,以确保 iptables 规则的数量是恒定不变的。
标签:iptables,service,ipvs,模式分析,proxy,kube,内核 From: https://www.cnblogs.com/muyi-yang/p/17614810.html