kube-proxy模式之iptables

最新推荐文章于 2024-07-28 11:15:00 发布
最新推荐文章于 2024-07-28 11:15:00 发布
阅读量2.1k 收藏 7
点赞数
分类专栏： Kubernetes 文章标签： kube-proxy模式 iptables模式 k8s
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010039418/article/details/119867394
版权

注：本文基于K8S v1.21.2版本编写

1 默认模式

当我们以默认配置部署kube-proxy时，将使用iptables作为proxier，我们可以从日志中查看相关信息。

I0814 13:42:49.260381       1 node.go:172] Successfully retrieved node IP: 192.168.0.111
I0814 13:42:49.260462       1 server_others.go:140] Detected node IP 192.168.0.111
W0814 13:42:49.260622       1 server_others.go:598] Unknown proxy mode "", assuming iptables proxy
I0814 13:42:49.478905       1 server_others.go:206] kube-proxy running in dual-stack mode, IPv4-primary
I0814 13:42:49.479023       1 server_others.go:212] Using iptables Proxier.
I0814 13:42:49.479032       1 server_others.go:219] creating dualStackProxier for iptables.
W0814 13:42:49.479258       1 server_others.go:512] detect-local-mode set to ClusterCIDR, but no IPv6 cluster CIDR defined, , defaulting to no-op detect-local for IPv6
I0814 13:42:49.480464       1 server.go:643] Version: v1.21.2

2 关于iptables

Iptabels是与Linux内核集成的包过滤防火墙系统，包含五表五链，其中，对于表，按先后顺序分别为，raw->mangle->nat->filter->security,

  • raw表——两个链：PREROUTING、OUTPUT
    作用：决定数据包是否被状态跟踪机制处理，和conntrack相关
  • mangle表——五个链：PREROUTING、INPUT、OUTPUT、POSTROUTING、FORWARD
    作用：修改数据包的服务类型、TTL以及QOS相关
  • nat表——三个链：PREROUTING、OUTPUT、POSTROUTING
    作用：用于网络地址转换
  • filter表——三个链：INPUT、FORWARD、OUTPUT
    作用：过滤数据包
  • security表——三个链：INPUT、FORWARD、OUTPUT
    作用：对连接进行安全标记，比如SECMARK，CONNSECMARK

其中，mangle和security用的比较少，raw主要用于iptables规则调试，因此在kube-proxy主要起作用的就是nat和filter表，这点我们可以通过查看iptables规则可知，其他三个表并没有规则。

而对于链，按先后顺序为，

  • 本机数据包：PREROUTING -> INPUT -> OUTPUT -> POSTROUTING
  • 转发数据包：PREROUTING -> FORWARD -> POSTROUTING

我们可以通过下面两张图来更直观的了解这五表五链，
在这里插入图片描述而对于数据包的流动而言，下面这张图更能清楚地描述这个过程，
在这里插入图片描述

3 CoreDNS数据流

我们以coredns服务为例，看下dns请求是如何通过iptables规则从其他pod到达coredns pod。

考虑到集群中的iptables规则繁多，我们可以通过raw表来实现规则的trace，方便跟踪数据包的流动，具体可以参考——CentOS通过raw表实现iptables日志输出和调试

因此我们在测试容器所在的node上创建以下两条规则，

[root@node1 ~]# iptables -t raw -A PREROUTING -p udp -s 10.244.1.62 --dport 53 -j TRACE
[root@node1 ~]# iptables -t raw -A OUTPUT -p udp -s 10.244.1.62 --dport 53 -j TRACE
[root@node1 ~]# iptables -t raw -vnL
Chain PREROUTING (policy ACCEPT 174 packets, 18916 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 TRACE      udp  --  *      *       10.244.1.62          0.0.0.0/0            udp dpt:53

Chain OUTPUT (policy ACCEPT 78 packets, 7085 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 TRACE      udp  --  *      *       10.244.1.62          0.0.0.0/0            udp dpt:53

其中10.244.1.62是测试容器的ip，规则越细，我们越容易筛选出我们的数据报文，不然一大堆日志。

然后通过kubectl exec进入到测试容器，执行ping操作，

[root@master ~]# kubectl exec -it centos-79456f6db-9wzc5 -n kubernetes-dashboard -- /bin/bash
[root@centos-79456f6db-9wzc5 /]# ping -c 1 www.baidu.com.
PING www.a.shifen.com (14.215.177.39) 56(84) bytes of data.
64 bytes from 14.215.177.39 (14.215.177.39): icmp_seq=1 ttl=53 time=19.2 ms

--- www.a.shifen.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.240/19.240/19.240/0.000 ms

有两点需要注意，

  • 只ping一个报文，不然日志太多
  • 域名最后要加一个点，不然会先在集群中查询这个域名

然后在系统日志/var/log/messages中查看数据流动情况，以下日志有精简，因为我们只关注数据流向，

node1 kernel: TRACE: raw:PREROUTING:policy:2 
node1 kernel: TRACE: mangle:PREROUTING:policy:1 
node1 kernel: TRACE: nat:PREROUTING:rule:1 
node1 kernel: TRACE: nat:KUBE-SERVICES:rule:10 
node1 kernel: TRACE: nat:KUBE-SVC-TCOU7JCQXEZGVUNU:rule:1 
node1 kernel: TRACE: nat:KUBE-SEP-MK55K7XS7VKFSUGB:rule:2 
node1 kernel: TRACE: mangle:FORWARD:policy:1 
node1 kernel: TRACE: filter:FORWARD:rule:1 
node1 kernel: TRACE: filter:KUBE-FORWARD:return:5 
node1 kernel: TRACE: filter:FORWARD:rule:2 
node1 kernel: TRACE: filter:KUBE-SERVICES:return:1 
node1 kernel: TRACE: filter:FORWARD:rule:3 
node1 kernel: TRACE: filter:KUBE-EXTERNAL-SERVICES:return:1 
node1 kernel: TRACE: filter:FORWARD:rule:4 
node1 kernel: TRACE: filter:DOCKER-USER:return:1 
node1 kernel: TRACE: filter:FORWARD:rule:5 
node1 kernel: TRACE: filter:DOCKER-ISOLATION-STAGE-1:return:2 
node1 kernel: TRACE: filter:FORWARD:rule:15 
node1 kernel: TRACE: mangle:POSTROUTING:policy:2 
node1 kernel: TRACE: nat:POSTROUTING:rule:1 
node1 kernel: TRACE: nat:KUBE-POSTROUTING:rule:1 
node1 kernel: TRACE: nat:POSTROUTING:rule:8 
node1 kernel: TRACE: nat:POSTROUTING:policy:12

而其中，最需要注意的是nat表的prerouting链，这里我把对应的iptables规则择出来，

Chain PREROUTING (policy ACCEPT 347 packets, 75317 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  969  136K KUBE-SERVICES  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kubernetes service portals */

Chain KUBE-SERVICES (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    ...
  280 22956 KUBE-SVC-TCOU7JCQXEZGVUNU  udp  --  *      *       0.0.0.0/0            10.96.0.10           /* kube-system/kube-dns:dns cluster IP */ udp dpt:53

Chain KUBE-SVC-TCOU7JCQXEZGVUNU (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  280 22956 KUBE-SEP-MK55K7XS7VKFSUGB  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-system/kube-dns:dns */

Chain KUBE-SEP-MK55K7XS7VKFSUGB (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    ...
  280 22956 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-system/kube-dns:dns */ udp to:10.244.0.48:53

由此可见，

  • 我们发往coredns的DNS请求开始时使用的clusterip，最后会被DNAT到对应的coredns的ip
  • k8s集群中每个服务都会有对应的iptables来路由请求

那对于多个服务的情况，负载是如何进行的呢，为此，我们在dashboard中，将coredns的副本数量调整为3个，再查看下对应的iptables规则，这里我们只看变化的部分，也就是服务部分，

Chain KUBE-SVC-TCOU7JCQXEZGVUNU (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 KUBE-SEP-MK55K7XS7VKFSUGB  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-system/kube-dns:dns */ statistic mode random probability 0.33333333349
    0     0 KUBE-SEP-YEXLSZTEUWXX6KZK  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-system/kube-dns:dns */ statistic mode random probability 0.50000000000
    0     0 KUBE-SEP-6XVRDQFXUVS4IFFJ  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* kube-system/kube-dns:dns */

可见，这时候规则里多了probability，这就是iptables的负载均衡。不过有意思的是，这个规则的概率和我们平常的有点不一样，按理三个服务，那每个都是1/3的概率，这里却出现了0.5。这是因为iptables的规则计算不一样，它是从前往后匹配，所以第一条规则的命中是1/3，但是到了第二条，那就是后面两条二选一，因此是1/2，到了最后一条，就是100%了。

Blue summer
关注
专栏目录
kube-proxy中使用ipvs与iptables的比较
linus.lin的博客
10-24 7027
Iptables模式 kube-proxy 就可以通过 Service 的 Informer 感知到API Server中service和endpoint的变化情况。而作为对这个事件的响应，它就会在宿主机上创建这样一条 iptables 规则（你可以通过 iptables-save 看到它）。这些规则捕获到service的clusterIP和port的流量，并将这些流量随机重定向到service后端Pod。对于每个endpoint对象，它生成选择后端Pod的iptables规则。 如果选择的第一个Pod没有
比较kube-proxy模式：iptables还是IPVS？
didiplus
05-23 1401
kube-proxy是任何Kubernetes部署中的关键组件。它的作用是将流向服务（通过集群 IP 和节点端口）的流量负载均衡到正确的后端pod。kube-proxyuserspaceiptables或IPVS。userspace模式非常旧且慢，绝对不推荐！但是，应该如何权衡选择iptables还是IPVS模式呢？在本文中，我们将比较这两种模式，在实际的微服务环境中衡量它们的性能，并解释在何种情况下你可能会选择其中一种。首先，我们将简要介绍这两种模式的背景，然后深入测试和结果……
iptable模拟丢包和阻断特定网络包的命令
wjh_84的专栏
07-24 299
可以通过指定udp 源ip和端口号过滤并停止特定的网络数据：iptables -A INPUT -p udp -s 172.16.186.155 --sport 56586 -j DROP。也可以通过指定udp目的ip和端口号过滤并停止特定的网络数据：iptables -A INPUT -p udp -d 172.18.78.19 --dport 8352 -j DROP。UDP表示网络包是属于UDP的传输协议，表示tcp，对应iptables参数-p udp。
kube-proxy源码阅读(iptables实现)
八月对半
03-03 1668
Reference 文章目录1 入口2 ProxyServer创建及调用3 ProxyServer 核心调用流程3.1 func (o *Options) Run() err3.2 func (o *Options) runLoop() error3.3 func (s *ProxyServer) Run() error3.4 func (proxier *Proxier) SyncLoop()4 资源事件处理流程4.1 Service事件4.2 Endpoints事件4.3 Nodes事件4.4 func
12、Kubernetes中KubeProxy实现之iptables和ipvs
weixiaohuai的博客
09-30 1421
iptables和ipvs其实都是依赖的一个共同的Linux内核模块：Netfilter。Netfilter是Linux 2.4.x引入的一个子系统，它作为一个通用的、抽象的框架，提供一整套的hook函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。Netfilter的架构就是在整个网络流程的若干位置放置了一些检测点（HOOK），而在每个检测点上登记了一些处理函数进行处理。
kube_proxy iptables
qq_36980207的博客
09-06 156
//将table中所有来自srcChain链中的数据包跳转到dstChain链中 type iptablesJumpChain struct { table utiliptables.Table //iptables的表 dstChain utiliptables.Chain //需要创建的chain的名字 srcChain utiliptables.Chain //需要进行判定的chain的名字 comment string //添加的注释 extraArgs []strin.
kube & iptables
01-05 1028
虽然paas层用的openshift，实际上是封装kubernetes. For some parts of your applications you may wantto expose a Service onto an external IP address. Kubernetes supports two waysof doing this: NodePorts and LoadBala
12、Kubernetes中KubeProxy实现之iptables和ipvs_ipvs和iptables
2401_83973943的博客
04-11 874
A OUTPUT!COMMIT。
kubernetes的Kube-proxy的iptables转发规则
田园园野的博客
06-01 1万+
概念 kube-proxy 实际上并不起一个 proxy 的作用，而是 watch 变更并更新 iptables，也就是说，client 的请求直接通过 iptables 路由。 如果kube-proxy通过iptables 转发。会修改filter和nat表 filter表 filter表通过OUTPUT链规定所有的出报文都要经过KUBE-SERVICES，如果一个Service没有对应的end...
kubernetes 使用cilium 网络插件 替换kube-proxy
02-10
在Kubernetes环境中，传统的服务发现和网络代理方案是通过kube-proxy来实现的，它提供了iptables、ipvs等不同的工作模式。然而，随着云原生应用的发展，对网络性能、安全性和可观测性的需求日益增强，这催生了Cilium...
Kubernetes kube-proxy的iptables与ipvs模式
最新发布
✨ 欢迎来到【Seal ^_^ 的CSDN博客】！这里是我记录技术心得、分享经验的地方。✨
07-28 5918
kube-proxy支持多种不同的代理模式，其中iptables和ipvs是最常用的两种。
Kube-proxy 使用 iptables 模式时,通过 Service 服务发布入口如何到达 Pod ？
山河已无恙
04-09 613
被问到这个问题，整理相关的笔记当 kube-proxy 模式设置为 iptables 的时候，通过 SVC 服务发布入口如何到达 Pod？博文内容涉及：问题简单介绍三种常用的服务发布方式到Pod报文路径解析当前集群为版本为v1.25.1Demo 演示使用了ansible理解不足小伙伴帮忙指正食用需要了解iptables生命的火花不是目标，而是对生活的热情。——《心灵奇旅》
Kubernetes--kube-proxy模式
GaoChuang_的博客
11-14 1463
一、kube-proxy三种工作模式 在kubernetes集群的每个节点上都运行着kube-proxy进程负责实现Kubernetes中Service组件的虚拟IP服务。目前kube-proxy有三种工作模式： User space模式 iptables模式 IPVS模式 Userspace模式 Userspace模式作用是在proxy的用户空间监听一个端口，所有的Service都转到这个端口，然后proxy的内部应用层对其转发。proxy会为每个Service随机监听一个...
Kubernetes kube-proxy 如何与 iptables 完美配合使用
运维那些事儿
08-06 1573
我们知道 kube-proxy 是 Kubernetes 中一个运行在每个节点上的守护进程，它基本上反映了集群中定义的服务已经对后端 Pod 负载均衡的规则管理。 假设我们有几个 API 微服务的 Pods 运行在我们的集群中，这些 Pods 的副本通过一个 Service 服务暴露，当一个请求到达 Service 的虚拟 IP 时，如何将请求转发到其中一个底层 Pod？其实就是通过 kube-proxy 创建的规则，虽然表面上并没有那么简单，但是我们还是可以进行大致的了解。 kube-proxy 可以在
kube-proxy —— iptable模式实现原理实例分析
aaqq123456654321的博客
04-04 134
k8s proxy
12、Kubernetes中KubeProxy实现之iptables和ipvs_ipvs和iptables(1)
m0_60452293的博客
04-05 342
app: nginxtemplate:metadata:labels:app: nginxspec:metadata:spec:我们这里创建一个副本数量为3的nginx pod，并创建一个对应的service对外暴露服务，service类型为ClusterIP。创建完成后，资源如下：可以看到，三个pod的IP分别为192.168.1.3、192.168.0.7、192.168.1.4。
kube-proxy iptables模式原理分析
summer_fish的专栏
04-19 914
在kubernetes集群内，访问一个pod应用可以通过pod IP，但是pod删除重建后IP会发生变化，而且在高可用多副本场景下直接通过IP访问，则会有客户端需要实现负载均衡等问题。为了解决上述问题，kubernetes在客户端和pod间引入了一个抽象层：service。 service通过labelSelector与pod关联，客户端通过service访问pod。访问类型可以分为两类： 通过service VIP访问：通过访问service clusterIP代理到后端pod。 通过servi
看过最详细的Kube-proxy的iptables模式原理详解
热门推荐
zhangxiangui40542的专栏
03-08 2万+
Kubernetes如何利用iptables 原文地址 Linux内置的防火墙可以对IP数据包做一系列如过滤、更改、转发这样的操作，防火墙在对数据包做过滤决定时，有一套遵循的规则，这些规则存储在专用的数据包过滤表（table）中，而这些表集成在Linux 内核中。在数据包过滤表中，规则被分组放在我们所谓的链（chain）中。 我们通常说的iptables就是指Linux内置的防火墙，它实际上...
kube-proxy iptables
07-27
在Kubernetes中，kube-proxy使用iptables来实现服务的负载均衡和网络转发。它会监听Kubernetes API中的Service和Endpoint对象的变化，并根据这些信息更新iptables规则，实现服务的访问和转发。 具体来说，kube-...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值