K8S中iptables和ipvs区别

原文

从k8s的1.8版本开始;kube-proxy引入了IPVS模式;IPVS模式与iptables同样基于Netfilter;但是ipvs采用的hash表;iptables采用一条条的规则列表。iptables又是为了防火墙设计的;集群数量越多iptables规则就越多;而iptables规则是从上到下匹配;所以效率就越是低下。因此当service数量达到一定规模时;hash查表的速度优势就会显现出来;从而提高service的服务性能

每个节点的kube-proxy负责监听API server中service和endpoint的变化情况。将变化信息写入本地userspace、iptables、ipvs来实现service负载均衡;使用NAT将vip流量转至endpoint中。由于userspace模式因为可靠性和性能;频繁切换内核/用户空间;早已经淘汰;所有的客户端请求svc;先经过iptables;然后再经过kube-proxy到pod;所以性能很差。

ipvs和iptables都是基于netfilter的;两者差别如下;

• ipvs 为大型集群提供了更好的可扩展性和性能
• ipvs 支持比 iptables 更复杂的负载均衡算法;最小负载、最少连接、加权等等;
• ipvs 支持服务器健康检查和连接重试等功能

一、Iptables模式

在这种模式下;kube-proxy监视API Server中service和endpoint的变化情况。对于每个service;它都生成相应的iptables规则;这些规则捕获到service的clusterIP和port的流量;并将这些流量随机重定向到service后端Pod。对于每个endpoint对象;它生成选择后端Pod的iptables规则。

如果选择的第一个Pod没有响应;kube-proxy将检测到到第一个Pod的连接失败;并将自动重试另一个后端Pod。

拓扑图;

缺点;

iptables 因为它纯粹是为防火墙而设计的;并且基于内核规则列表;集群数量越多性能越差。

一个例子是;在5000节点集群中使用 nodePort 服务;如果我们有2000个服务并且每个服务有10个 pod;这将在每个工作节点上至少产生20000个 iptable 记录;这可能使内核非常繁忙。

二、IPVS模式;NAT模式;

在这种模式下;kube-proxy监听API Server中service和endpoint的变化情况;调用netlink接口创建相应的ipvs规则;并定期将ipvs规则与Kubernetes服 Services和Endpoints同步。保证IPVS状态。当访问Services时;IPVS将流量定向到后端pod之一。

IPVS代理模式基于netfilter hook函数;该函数类似于iptables模式;但使用hash表作为底层数据结构;在内核空间中工作。这意味着IPVS模式下的kube-proxy使用更低的重定向流量。其同步规则的效率和网络吞吐量也更高。

拓扑图;

说明;

ipvs依赖iptables进行包过滤、SNAT、masquared(伪装)。 使用 ipset 来存储需要 DROP 或 masquared 的流量的源或目标地址;以确保 iptables 规则的数量是恒定的;这样我们就不需要关心我们有多少服务了

如果没有加载并启用ipvs模块;或者没有配置ipvs相关配置;则会被降级成iptables模式。