本站将逐步迁移至新站点,点击访问

kube-proxy代理模式对比

258次阅读
没有评论

前言

kubectl–> API server –> etcd,每个节点的kube-proxy负责监听API server中service和endpoint的变化情况。将变化信息写入本地userspace、iptables、ipvs来实现service负载均衡,使用NAT将vip流量转至endpoint中。 这里仅对iptables和ipvs说明,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。

拓补图

kube-proxy代理模式对比

缺陷

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使用更低的重定向流量。其同步规则的效率和网络吞吐量也更高。

拓补图

kube-proxy代理模式对比

说明

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

Honest1y
版权声明:本站原创文章,由Honest1y于2021年02月05日发表,共计3114字。
转载提示:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)