容器云负载均衡之三：使用iptables对IPVS Direct Routing模式进行端口转换

最新推荐文章于 2024-09-02 23:34:33 发布
最新推荐文章于 2024-09-02 23:34:33 发布
阅读量2.2k 收藏 2
点赞数
分类专栏： 容器云的负载均衡解决方案 文章标签： iptables IPVS port redirect direct routing
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cloudvtech/article/details/80145579
版权

一、前言

在cloud环境中，不是所有的application都有使用80端口这种特权端口的权限；但是在IPVS direct routing模式下，VIP监听的端口必须要保持和后端real server上的application监听的端口一致，见文章http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.rewrite_ports.html：


本文通过iptables来解决这个问题，最终达到IPVS DR模式监听80端口，后端HTTP服务监听8080端口，客户端访问VIP:80可以得到后端8080端口提供的服务。

转载自https://blog.csdn.net/cloudvtech

二、IPVS DR模式端口转换的实现

2.1 机器配置

IPVS director： 192.168.166.102
IPVS real server：192.168.166.103
VIP：192.168.166.111

2.2 IPVS director的设置

ipvsadm -C  
ipvsadm -A -t 192.168.166.111 -s rr  
ipvsadm -a -t  192.168.166.111:80 -r 192.168.166.103:80 -w 1 -g  
  
ifconfig  ens33:0 192.168.166.111 broadcast 192.168.166.255 netmask 255.255.255.0 up  
route add -host 192.168.166.111  dev ens33:0

/etc/sysctl.conf 

net.ipv4.ip_forward = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens33.send_redirects = 0
net.ipv4.conf.all.rp_filter = 0

2.3 IPVS real server的设置

   /etc/sysctl.conf 

net.ipv4.conf.all.arp_ignore = 1  
net.ipv4.conf.all.arp_announce = 2  
net.ipv4.conf.ens33.arp_ignore = 1  
net.ipv4.conf.ens33.arp_announce = 2  
 
ifconfig lo:0 192.168.166.111 broadcast 192.168.166.255 netmask 255.255.255.255 up  
route add -host 192.168.166.111  dev lo:0

并且启动http服务监听在80端口

2.4 在IPVS director插入如下iptables debug LOG

iptables -t mangle -A INPUT -p tcp -m tcp --dport 80 -j LOG --log-prefix "[INPUT|mangle] "
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 80 -j LOG --log-prefix "[OUTPUT|mangle] "

2.5 在IPVS read server插入如下iptables debug LOG

iptables -t mangle -A OUTPUT -p tcp -m tcp --sport 8080 -j LOG --log-prefix "[OUTPUT|mangle] port 8080 "
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j LOG --log-prefix "[INPUT|nat] before REDIRECT "
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

2.6 从其它客户端访问VIP的80端口

curl 192.168.166.111:80

可以得到返回：

curl 192.168.166.111 -vvv
* Rebuilt URL to: 192.168.166.111/
*   Trying 192.168.166.111...
* TCP_NODELAY set
* Connected to 192.168.166.111 (192.168.166.111) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.166.111
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Date: Tue, 01 May 2018 05:37:41 GMT
< Server: Apache/2.4.6 (CentOS)
< Last-Modified: Thu, 16 Oct 2014 13:20:58 GMT
< ETag: "1321-5058a1e728280"
< Accept-Ranges: bytes
< Content-Length: 4897
< Content-Type: text/html; charset=UTF-8
<

2.7 IPVS director iptables LOG输出

May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=51301 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=51301 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=12788 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4117 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=12788 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4117 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=131 TOS=0x00 PREC=0x00 TTL=64 ID=43668 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4117 RES=0x00 ACK PSH URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=131 TOS=0x00 PREC=0x00 TTL=64 ID=43668 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4117 RES=0x00 ACK PSH URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=61495 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4027 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=61495 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4027 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=11136 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=11136 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=10635 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4070 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=10635 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4070 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=46543 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4096 RES=0x00 ACK FIN URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=46543 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4096 RES=0x00 ACK FIN URGP=0 
May  1 01:38:04 k8s-node1 kernel: [INPUT|mangle] IN=ens33 OUT= MAC=00:0c:29:e7:54:7c:00:50:56:c0:00:08:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53957 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0 
May  1 01:38:04 k8s-node1 kernel: [OUTPUT|mangle] IN= OUT=ens33 SRC=192.168.166.1 DST=192.168.166.111 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53957 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=4096 RES=0x00 ACK URGP=0

2.8 IPVS real server iptables LOG输出

May  1 01:37:41 k8s-node2 kernel: [INPUT|nat] before REDIRECT IN=ens33 OUT= MAC=00:0c:29:75:24:37:00:0c:29:e7:54:7c:08:00 SRC=192.168.166.1 DST=192.168.166.111 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=51301 DF PROTO=TCP SPT=56047 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
May  1 01:37:41 k8s-node2 kernel: [OUTPUT|mangle] port 8080 IN= OUT=ens33 SRC=192.168.166.103 DST=192.168.166.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8080 DPT=56047 WINDOW=28960 RES=0x00 ACK SYN URGP=0 
May  1 01:37:41 k8s-node2 kernel: [OUTPUT|mangle] port 8080 IN= OUT=ens33 SRC=192.168.166.103 DST=192.168.166.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=32293 DF PROTO=TCP SPT=8080 DPT=56047 WINDOW=227 RES=0x00 ACK URGP=0 
May  1 01:37:41 k8s-node2 kernel: [OUTPUT|mangle] port 8080 IN= OUT=ens33 SRC=192.168.166.103 DST=192.168.166.1 LEN=4396 TOS=0x00 PREC=0x00 TTL=64 ID=32294 DF PROTO=TCP SPT=8080 DPT=56047 WINDOW=227 RES=0x00 ACK URGP=0 
May  1 01:37:41 k8s-node2 kernel: [OUTPUT|mangle] port 8080 IN= OUT=ens33 SRC=192.168.166.103 DST=192.168.166.1 LEN=857 TOS=0x00 PREC=0x00 TTL=64 ID=32297 DF PROTO=TCP SPT=8080 DPT=56047 WINDOW=227 RES=0x00 ACK PSH URGP=0 
May  1 01:37:41 k8s-node2 kernel: [OUTPUT|mangle] port 8080 IN= OUT=ens33 SRC=192.168.166.103 DST=192.168.166.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=32298 DF PROTO=TCP SPT=8080 DPT=56047 WINDOW=227 RES=0x00 ACK FIN URGP=0

转载自https://blog.csdn.net/cloudvtech

三、与从IPVS director访问VIP相结合

可以将本方案和根据文章《从IPVS DR模式下director不能访问VIP问题的探究》提供的解决方案绑定在一起，就可以为kubernetes容器云环境下的IPVS service找到无缝的解决方案：

  • IPVS director可以和后端application混合部署
  • IPVS director可以监听80特权端口
  • application只需监听任意无特权端口
  • 客户端可以在包括IPVS director所在的worker node之内的任何位置访问VIP:80服务

转载自https://blog.csdn.net/cloudvtech

















cloudvtech
关注
专栏目录
kubernetes / IPVS 和 IPTABLES
Yosigo_的博客
09-06 862
IPVS（IP 虚拟服务器）实现传输层负载平衡，通常称为第 4 层 LAN 交换，作为 Linux 内核的一部分。IPVS 在主机上运行并充当真实服务器集群前面的负载平衡器。IPVS 可以将基于 TCP 和 UDP 的服务的请求定向到真实服务器，并使真实服务器的服务在单个 IP 地址上表现为虚拟服务。
LVS模式一：DR（Direct Routing）直接路由模式
qq_42711214的博客
09-26 1286
一般来说，LVS集群采用三层结构，其主要组成部分为： A、负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。 B、服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。 C、共享存储（shared stor...
iptables和ipvs
jingzhiz 专属移动笔记
10-14 3675
一、service和iptables的关系 service 的代理是 kube-proxy kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上，而kube...
12、Kubernetes中KubeProxy实现之iptables和ipvs_ipvs和iptables
最新发布
2401_86444443的博客
09-02 1038
iptables和ipvs其实都是依赖的一个共同的Linux内核模块：Netfilter。Netfilter是Linux 2.4.x引入的一个子系统，它作为一个通用的、抽象的框架，提供一整套的hook函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。Netfilter的架构就是在整个网络流程的若干位置放置了一些检测点（HOOK），而在每个检测点上登记了一些处理函数进行处理。
12、Kubernetes中KubeProxy实现之iptables和ipvs
weixiaohuai的博客
09-30 1460
iptables和ipvs其实都是依赖的一个共同的Linux内核模块：Netfilter。Netfilter是Linux 2.4.x引入的一个子系统，它作为一个通用的、抽象的框架，提供一整套的hook函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。Netfilter的架构就是在整个网络流程的若干位置放置了一些检测点（HOOK），而在每个检测点上登记了一些处理函数进行处理。
kube-proxy中使用ipvs与iptables的比较
linus.lin的博客
10-24 7069
Iptables模式 kube-proxy 就可以通过 Service 的 Informer 感知到API Server中service和endpoint的变化情况。而作为对这个事件的响应，它就会在宿主机上创建这样一条 iptables 规则（你可以通过 iptables-save 看到它）。这些规则捕获到service的clusterIP和port的流量，并将这些流量随机重定向到service后端Pod。对于每个endpoint对象，它生成选择后端Pod的iptables规则。 如果选择的第一个Pod没有
ipvs和iptables的区别？
lbzrl的博客
04-13 801
1）实现方式：iptables是基于Netfilter框架的网络过滤工具，它使用链表（chain）和规则（rule）来处理网络数据包。2）功能：iptables主要用于实现网络地址转换（NAT）、端口转发（forwarding）、流量过滤等功能，而ipvs主要用于实现负载均衡（load balancing）和服务器健康检查（health check）。4）使用场景：iptables更适合用于防火墙、NAT和端口转发等场景，而ipvs更适合用于负载均衡和服务器集群管理。
如何部署LVS负载均衡集群（NAT模式）
Liu_Fang_Hong的博客
07-05 3730
集群是由多台主机沟工程，但是对外只表现为一个整体，只提供一个访问入口（域名或者IP地址）普通的服务器构建服务器集群通过整合多台服务器，使用LVS来达到服务器的高可用和负载均衡，并以同一个IP地址对外提供相同的服务，常用的一种群集技术LVS（Linux虚拟服务器，Linux Virtual Server）
LVS 负载均衡器总结
01-26
4. **Virtual server via IP Address Mapping (VS-IPTABLES)**：这种模式较少使用，通过iptables规则实现负载均衡，但不如其他模式高效。 高可用性（HA）集群是确保服务连续性的关键，通过监控主服务器状态，实现...
Linux学习：四层负载均衡2
weixin_63123212的博客
07-30 1108
用地址转换实现虚拟服务器。分发器有能被外部访问到的合法IP地址，他修改来自专有网络的流出包的地址。外界看起来包是来自分发器本身，当外界包送到转换器时，他能判断出应该将包送到内部网的哪个节点。优点节省IP地址，能对内部进行伪装；缺点效率低用直接路由技术实现虚拟服务器。当参与集群的计算机和作为控制管理的计算机在同一网段时，可以用此方法，控制管理的计算机收到请求包时直接送到参与集群的节点。用IP隧道技术实现虚拟服务器。在集群的节点不在同一网段时可用的转发机制，是将IP包封装在其他网络流量中的方法。......
Lvs-负载均衡配置 NAT模式
huasan994520的博客
06-13 742
群集的含义 Cluster，集群、群集 由多台主机构成，但对外只表现为一个整体负载均衡群集、高可用群集和高性能运算群集。提高应用系统的响应能力、尽可能处理更多的访问请求、减少延迟为目标，获得高并发、高负载（LB）的整体性能 LB的负载分配依赖于主节点的分流算法提高应用系统的可靠性、尽可能地减少中断时间为目标，确保服务的连续性，达到高可用（HA）的容错效果 HA的工作方式包括双工和主从两种模式提高应用系统的CPU运算速度、扩展硬件资源和分析能力为目标，获得相当于大型、超级计算机的高性能运算（HPC）能力 高性
k8s-service底层之 Iptables与 IPVS
huahua1999的博客
04-17 7865
service底层之 Iptables与 IPVS service底层实现主要由两个网络模式组成：iptables与IPVS。他们都是有kube-proxy维护 service工作流程图 Iptables 以k8s中的nginx这个service举例，这是一个nodePort类型的service 用命令 iptables-save |grep nginx 可以看到这个service中的iptables规则 找到他对外暴露的端口30601 ...
Kubernetes IPVS和IPTABLES
sinat_40572875的博客
11-19 1150
IPVS（IP Virtual Server，IP虚拟服务器）实现了传输层的负载平衡，通常称为4 LAN（四层局域网）交换，是Linux内核的一部分。IPVS在主机上运行，在真实服务器集群前面充当负载平衡器。IPVS可以将基于 TCP 和 UDP 的服务请求定向到真实服务器上。
k8s中iptables与ipvs详解——2023.05
我是小bā吖的博客
05-30 4399
从k8s的1.8版本开始，kube-proxy引入了IPVS模式，IPVS模式与iptables同样基于Netfilter，但是ipvs采用的hash表，iptables采用一条条的规则列表。iptables又是为了防火墙设计的，集群数量越多iptables规则就越多，而iptables规则是从上到下匹配，所以效率就越是低下。因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。
iptables与ipvs的异同
Q先生
12-14 1181
Kubernetes 1.29 新版将抛弃 iptables那么我们就来聊一下iptables与ipvs的异同iptables和ipvs都是Linux系统中用于网络流量控制和管理的工具，但它们在实现方式、功能和性能上有所不同。本文将对iptables和ipvs进行比较，以帮助读者更好地了解它们之间的区别。
kube-proxy中使用IPVS与iptables的比较
xiangfeideyuwei的博客
08-08 1104
iptables是Linux内核中的一个用户空间实用程序，允许系统管理员和/或用户配置IPv4/IPv6包过滤规则。kube-proxy使用iptables来处理Kubernetes服务的流量。IPVS（IP Virtual Server）是Linux内核中的一个负载均衡技术。与iptables不同，IPVS 提供了更高效、更灵活的负载均衡机制。iptables 模式适用于小规模集群，配置简单，易于管理。在大规模集群中，性能可能成为瓶颈，规则更新较慢。IPVS 模式。
比较kube-proxy模式：iptables还是IPVS？
didiplus
05-23 1454
kube-proxy是任何Kubernetes部署中的关键组件。它的作用是将流向服务（通过集群 IP 和节点端口）的流量负载均衡到正确的后端pod。kube-proxyuserspaceiptables或IPVS。userspace模式非常旧且慢，绝对不推荐！但是，应该如何权衡选择iptables还是IPVS模式呢？在本文中，我们将比较这两种模式，在实际的微服务环境中衡量它们的性能，并解释在何种情况下你可能会选择其中一种。首先，我们将简要介绍这两种模式的背景，然后深入测试和结果……
k8s里面的iptables和ipvs有什么区别?怎么选？为什么选择ipvs
weixin_44227567的博客
02-23 1055
在 Kubernetes 中，IPVS 可以用于实现 Service 的负载均衡，相比于 Iptables，IPVS 具有更高的性能和更多的负载均衡算法选择，可以更好地应对高流量和高并发的场景。如果流量比较小，可以使用 Iptables 实现 Service，如果需要更高的性能和更多的负载均衡算法，可以考虑使用 IPVS。在 Kubernetes 中，Iptables 和 IPVS 都是负责流量转发的工具，但是在实现上有一些区别，可以根据不同的场景来选择使用。
K8S中iptables和ipvs区别
神棍之路
08-24 1792
从k8s的1.8版本开始，kube-proxy引入了IPVS模式，IPVS模式与iptables同样基于Netfilter，但是ipvs采用的hash表，iptables采用一条条的规则列表。iptables又是为了防火墙设计的，集群数量越多iptables规则就越多，而iptables规则是从上到下匹配，所以效率就越是低下。对于每个service，它都生成相应的iptables规则，这些规则捕获到service的clusterIP和port的流量，并将这些流量随机重定向到service后端Pod。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值