【云原生】Kubernetes之Kube-proxy的iptables与ipvs实现方式

Goland猫
695 阅读6分钟

先从Cluster IP开始

Kubernetes以Pod作为应用部署的最小单位。kubernetes会根据Pod的声明对其进行调度，包括创建、销毁、迁移、水平伸缩等，因此Pod 的IP地址不是固定的，不方便直接采用Pod IP对服务进行访问。

为解决该问题，Kubernetes提供了Service资源，Service对提供同一个服务的多个Pod进行聚合。一个Service提供一个虚拟的Cluster IP，后端对应一个或者多个提供服务的Pod。在集群中访问该Service时，采用Cluster IP即可，Kube-proxy负责将发送到Cluster IP的请求转发到后端的Pod上。

Kube-proxy是一个运行在每个节点上的go应用程序，支持三种工作模式：

userspace 模式

该模式下kube-proxy会为每一个Service创建一个监听端口。发向Cluster IP的请求被Iptables规则重定向到Kube-proxy监听的端口上，Kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。

该模式下，Kube-proxy充当了一个四层Load balancer的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加两次内核和用户空间之间的数据拷贝，效率较另外两种模式低一些；好处是当后端的Pod不可用时，kube-proxy可以重试其他Pod。

iptables 模式

为了避免增加内核和用户空间的数据拷贝操作，提高转发效率，Kube-proxy提供了iptables模式。在该模式下，Kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。

该模式下Kube-proxy不承担四层代理的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。

image.png

ipvs 模式

该模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs rules。ipvs也是在kernel模式下通过netfilter实现的，但采用了hash table来存储规则，因此在规则较多的情况下，Ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。如果要设置kube-proxy为ipvs模式，必须在操作系统中安装IPVS内核模块。

什么是IPVS？

IPVS (IP Virtual Server，IP虚拟服务器)是基于Netfilter的、作为linux内核的一部分实现传输层负载均衡的技术，通常称为第4层LAN交换。

IPVS集成在LVS(Linux Virtual Server)中，它在主机中运行，并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。因此IPVS天然支持Kubernetes Service。

image.png

为什么选择IPVS？

  • 随着kubernetes使用量的增长，其资源的可扩展性变得越来越重要。特别是对于使用kubernetes运行大型工作负载的开发人员或者公司来说，service的可扩展性至关重要。

  • kube-proxy是为service构建路由规则的模块，之前依赖iptables来实现主要service类型的支持，比如(ClusterIP和NodePort)。但是iptables很难支持上万级的service，因为iptables纯粹是为防火墙而设计的，并且底层数据结构是内核规则的列表。

  • kubernetes早在1.6版本就已经有能力支持5000多节点，这样基于iptables的kube-proxy就成为集群扩容到5000节点的瓶颈。举例来说，如果在一个5000节点的集群，我们创建2000个service，并且每个service有10个pod，那么我们就会在每个节点上有至少20000条iptables规则，这会导致内核非常繁忙。

  • ipvs (IP Virtual Server) 实现了传输层负载均衡，也就是我们常说的4层LAN交换，作为Linux 内核的一部分。ipvs运行在主机上，在真实服务器集群前充当负载均衡器。ipvs可以将基于TCP和UDP的服务请求转发到真实服务器上，并使真实服务器的服务在单个IP 地址上显示为虚拟服务。

基于IPVS的集群内负载均衡就可以完美的解决这个问题。IPVS是专门为负载均衡设计的，并且底层使用哈希表这种非常高效的数据结构，几乎可以允许无限扩容。

IPVS与IPTABLES的区别

IPVS模式在Kubernetes v1.8中引入，并在v1.9中进入了beta。 1.11中实现了GA(General Availability)。IPTABLES模式在v1.1中添加，并成为自v1.2以来的默认操作模式。 IPVS和IPTABLES都基于netfilter。 IPVS模式和IPTABLES模式之间的差异如下：

  • IPVS为大型集群提供了更好的可扩展性和性能。
  • IPVS支持比iptables更复杂的负载平衡算法（最小负载，最少连接，位置，加权等）。
  • IPVS支持服务器健康检查和连接重试等。

IPVS要求

  1. k8s版本 >= v1.11
  2. 使用ipvs需要安装相应的工具来处理”yum install ipset ipvsadm -y“
  3. 确保 ipvs已经加载内核模块， ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh、nf_conntrack_ipv4(如果这些内核模块不加载，当kube-proxy启动后，会退回到iptables模式)

kube-proxy 工作原理

kube-proxy 监听 API server 中 service 和 endpoint 的变化情况，并通过 userspace、iptables、ipvs 或 winuserspace 等 proxier 来为服务配置负载均衡（仅支持 TCP 和 UDP）。

服务外访问

 

  • 南北向的流量，即外部请求访问 Kubernetes 集群，主要包括三种方式：nodePort、loadbalancer、Ingress。

  • nodePort 同样是 Service 的一种类型，通过 iptables 赋予了调用宿主机上的特定 port 就能访问到背后Service 的能力。

  • loadbalancer 则是另一种 Service 类型，通过公有云提供的负载均衡器实现。

  • 我们访问 100 个服务可能需要创建 100 个 nodePort/loadbalancer。我们希望通过一个统一的外部接入层访问内部 Kubernetes 集群，这就是 Ingress 的功能。Ingress 提供了统一接入层，通过路由规则的不同匹配到后端不同的 Service 上。

  • Ingress 可以看做是“Service 的 Service”。Ingress 在实现上往往结合 nodePort 以及 loadbalancer 完成功能。

到现在为止，我们简单了解了 Kubernetes 的相关概念，它大致是怎么运作的，以及微服务是怎么运行在 Kubernetes 中的。于是当我们听到别人讨论 Kubernetes 时，我们可以知道他们在讨论什么。

avatar
文章
阅读
粉丝