标签：iptables 模式 三种 proxy 规则 iptabels kube
kube-proxy模式详解
kubernetes里kube-proxy支持三种模式，在v1.8之前我们使用的是iptables 以及 userspace两种模式，在kubernetes 1.8之后引入了ipvs模式，并且在v1.11中正式使用，其中iptables和ipvs都是内核态也就是基于netfilter，只有userspace模式是用户态。
userspace
起初，kube-proxy进程是一个真实的TCP/UDP代理，当某个pod以clusterIP方式访问某个service的时候，这个流量会被pod所在的本机的iptables转发到本季的kube-proxy进程，然后将请求转发到后端某个pod上。具体过程为：
- kube-proxy为每个service在node上打开一个随机端口作为代理端口
- 建立iptables规则，将clusterip的请求重定向到代理端口（用户空间）
- 到达代理端口的请求再由kubeproxy转发到后端
clusterip重定向到kube-proxy服务的过程存在内核态到用户态的切换，开销很大，因此有了iptables模式，而userspace模式也被废弃了。
iptabels
kubernets从1.2版本开始将iptabels模式作为默认模式，这种模式下kube-proxy不再起到proxy的作用。其核心功能：通过API Server的Watch接口实时跟踪Service和Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量通过iptables的NAT机制“直接路由”到目标Pod。
不同于userspace，iptables由kube-proxy动态的管理，kube-proxy不再负责转发，数据包的走向完全由iptables规则决定，这样的过程不存在内核态到用户态的切换，效率明显会高很多。但是随着service的增加，iptables规则会不断增加，导致内核十分繁忙（等于在读一张很大的没建索引的表）。
2个svc，8个pod就有34条iptabels规则了，随着集群中svc和pod大量增加以后，iptables中的规则开会急速膨胀，导致性能下降，某些极端情况下甚至会出现规则丢失的情况，并且这种故障难以重现和排查。
ipvs
从kubernetes 1.8版本开始引入第三代的IPVS模式，它也是基于netfilter实现的，但定位不同：iptables是为防火墙设计的，IPVS则专门用于高性能
负载均衡，并使用高效的数据结构Hash表，允许几乎无限的规模扩张。
一句话说明：ipvs使用ipset存储iptables规则，在查找时类似hash表查找，时间复杂度为O(1)，而iptables时间复杂度则为O(n)。
可以将ipset简单理解为ip集合，这个集合的内容可以是IP地址、IP网段、端口等，iptabels可以直接添加规则对这个可变集合进行操作，这样做的好处可以大大减少iptables规则的数量，从而减少性能损耗。
假设要禁止上万个IP访问我们的服务器，如果用iptables的话，就需要一条一条的添加规则，会生成大量的iptabels规则；但是用ipset的话，只需要将相关IP地址加入ipset集合中即可，这样只需要设置少量的iptables规则即可实现目标。
由于ipvs无法提供包过滤、地址伪装、SNAT等功能，所以某些场景下（比如NodePort的实现）还要与iptables搭配使用。
标签：iptables,模式,三种,proxy,规则,iptabels,kube 来源： https://www.cnblogs.com/yrxing/p/15920398.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。