032.核心组件-kube-proxy
作者:互联网
一 kube-proxy原理
1.1 kube-proxy概述
Kubernetes为了支持集群的水平扩展、高可用性,抽象出了Service的概念。Service是对一组Pod的抽象,它会根据访问策略(如负载均衡策略)来访问这组Pod。Kubernetes在创建Service时会为Service分配一个虚拟的IP地址,客户端通过访问这个虚拟的IP地址来访问服务,Service则负责将请求转发到后端的Pod上。 Service作用类似反向代理,但与普通的反向代理有一些不同:首先,它的IP地址是虚拟的,默认情况无法从外面访问;其次,它的部署和启停是由Kubernetes统一自动管理的。 然而,Service是一个抽象概念,而真正提供Service功能的是kube-proxy服务进程。在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程,可以简单理解此进程是Service的透明代理兼负载均衡器,其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。 此外,Service的ClusterIP与NodePort等概念是kube-proxy服务通过iptables的NAT转换实现的,kube-proxy在运行过程中动态创建与Service相关的iptables规则,这些规则实现了将访问服务(ClusterIP或NodePort)的请求负载分发到后端Pod的功能。 由于iptables机制针对的是本地的kube-proxy端口,所以在每个Node上都要运行kube-proxy组件。这样一来,在Kubernetes集群内部,才可以在任意Node上发起对Service的访问请求。 综上所述,由于kube-proxy的作用,在Service的调用过程中客户端无须关心后端有几个Pod,中间过程的通信、负载均衡及故障恢复都是透明的。二 kube-proxy模式
2.1 userspace模式
起初,kube-proxy进程是一个真实的TCP/UDP代理,类似HAProxy,负责从Service到Pod的访问流量的转发,这种模式被称为userspace(用户空间代理)模式。 如图所示,当某个Pod以ClusterIP方式访问某个Service的时候,这个流量会被Pod所在本机的iptables转发到本机的kube-proxy进程,然后由kube-proxy建立起到后端Pod的TCP/UDP连接,随后将请求转发到某个后端Pod上,并在这个过程中实现负载均衡功能。 ClusterIP与NodePort的实现原理,以及kube-proxy与APIServer的交互过程,如下图所示: 提示:如上为旧版kube-proxy与APIServer的交互过程。2.2 iptables模式
如图所示,Kubernetes从1.2版本开始,将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用,其核心功能:通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息,并更新对应的iptables规则,Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。 根据Kubernetes的网络模型,一个Node上的Pod与其他Node上的Pod应该能够直接建立双向的TCP/IP通信通道,所以如果直接修改iptables规则,则也可以实现kube-proxy的功能,只不过后者更加高端,因为是全自动模式的。 与第1代的userspace模式相比,iptables模式完全工作在内核态,不用再经过用户态的kube-proxy中转,因而性能更强。 iptables模式虽然实现起来简单,但存在无法避免的缺陷:在集群中的Service和Pod大量增加以后,iptables中的规则会急速膨胀,导致性能显著下降,在某些极端情况下甚至会出现规则丢失的情况,并且这种故障难以重现与排查,于是Kubernetes从1.8版本开始引入第3代的IPVS(IPVirtualServer)模式。 kube-proxy针对Service和Pod创建的一些主要的iptables规则如下。- KUBE-CLUSTER-IP:在masquerade-all=true或clusterCIDR指定的情况下对ServiceClusterIP地址进行伪装,以解决数据包欺骗问题。
- KUBE-EXTERNAL-IP:将数据包伪装成Service的外部IP地址。
- KUBE-LOAD-BALANCER、KUBE-LOAD-BALANCERLOCAL:伪装LoadBalancer类型的Service流量。
- KUBE-NODE-PORT-TCP、KUBE-NODE-PORT-LOCALTCP、KUBE-NODE-PORTUDP、KUBE-NODE-PORT-LOCAL-UDP:伪装NodePort类型的Service流量。
2.3 IPVS模式
如图所示。IPVS在Kubernetes1.11中升级为GA稳定版。iptables与IPVS虽然都是基于Netfilter实现的,但因为定位不同,二者有着本质的差别:iptables是为防火墙而设计的;IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张,因此被kube-proxy采纳为第三代模式。 与iptables相比,IPVS拥有以下明显优势:- 为大型集群提供了更好的可扩展性和性能;
- 支持比iptables更复杂的复制均衡算法(最小负载、最少连接、加权等);
- 支持服务器健康检查和连接重试等功能;
- 可以动态修改ipset的集合,即使iptables的规则正在使用这个集合。
标签:iptables,Service,proxy,规则,032,Pod,kube 来源: https://www.cnblogs.com/itzgr/p/12516505.html