calico IPIP跨节点通信

已于 2024-09-13 15:36:35 修改
阅读量921 收藏 14
点赞数 14
文章标签： k8s 网络
于 2024-09-13 15:30:55 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43391291/article/details/142211997
版权

一个简单的demo，模拟IPIP之间的通信
服务器1（假设IP为192.168.1.1）
服务器2（假设IP为192.168.1.2）

  1. 启用IP转发
    在两台服务器上启用IP转发：
echo 1 > /proc/sys/net/ipv4/ip_forward

永久启用IP转发，可以修改/etc/sysctl.conf：

net.ipv4.ip_forward = 1

应用更改：

sysctl -p
  1. 配置IPIP隧道
    在两台服务器上配置IPIP隧道：
    服务器1配置（192.168.1.1）
    创建IPIP隧道接口：
ip tunnel add ipip1 mode ipip remote 192.168.1.2 local 192.168.1.1 dev eth0
ip addr add 10.0.0.1/24 dev ipip1
ip link set ipip1 up

添加路由以通过IPIP隧道转发流量：

ip route add 10.0.0.0/24 dev ipip1

服务器2配置（192.168.1.2）
创建IPIP隧道接口：

ip tunnel add ipip1 mode ipip remote 192.168.1.1 local 192.168.1.2 dev eth0
ip addr add 10.0.0.2/24 dev ipip1
ip link set ipip1 up

添加路由以通过IPIP隧道转发流量：

ip route add 10.0.0.0/24 dev ipip1
  1. 验证IPIP隧道
    在两台服务器上验证IPIP隧道的连接：
    从服务器1 ping服务器2：
    ping 10.0.0.2
    从服务器2 ping服务器1：
    ping 10.0.0.1

calico ipip
IPIP模式是calico的默认网络架构，其实这也是一种overlay的网络架构，但是比overlay更常用的vxlan模式相比更加轻量化。IPinIP就是把一个IP数据包又套在一个IP包里，即把 IP 层封装到 IP 层的一个 tunnel它的作用其实基本上就相当于一个基于IP层的网桥！一般来说，普通的网桥是基于mac层的，根本不需 IP，而这个 ipip 则是通过两端的路由做一个 tunnel，把两个本来不通的网络通过点对点连接起来.

实例信息

主机容器ip
node01 7.7.250.91tcpdump1-6b94c59cb4-khtbb10.244.103.93
node02 7.7.250.207tcpdump1-6b94c59cb4-khtbb10.244.232.180

node网络结构
1.pod网络
通过kubectl exec -it tcpdump1-6b94c59cb4-khtbb – ip a进入到容器中去，查看容器内部网络

root@k8s-new-master:~/jin# kubectl exec -it tcpdump1-6b94c59cb4-khtbb -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0

4: eth0@if1694: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1480 qdisc noqueue state UP
link/ether de:9a:ba:1c:2b:60 brd ff:ff:ff:ff:ff:ff
inet 10.244.103.93/32 scope global eth0
   valid_lft forever preferred_lft forever

2.node网络
ip a 在node上查看网络可以看到
eth0网卡

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether fa:16:3e:55:db:0f brd ff:ff:ff:ff:ff:ff
inet 7.7.250.91/24 brd 7.7.250.255 scope global dynamic eth0
   valid_lft 80801sec preferred_lft 80801sec
inet6 fe80::f816:3eff:fe55:db0f/64 scope link 
   valid_lft forever preferred_lft forever

tunl0网卡

5: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
inet 10.244.103.64/32 scope global tunl0
   valid_lft forever preferred_lft forever

1694号的calif118cc83606网卡

1694: calif118cc83606@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 21
inet6 fe80::ecee:eeff:feee:eeee/64 scope link 
   valid_lft forever preferred_lft forever

node中除了eth0外，多了tunl0和calif118cc83606@if4，tunl0就是Calico在IPIP模式下的隧道名称 ，而calif118cc83606@if4，注意到，该设备的编号为1694。让我们回到pod1中，查看pod1内的ip a

root@k8s-new-master:~/jin# kubectl exec -it tcpdump1-6b94c59cb4-khtbb -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0

4: eth0@if1694: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1480 qdisc noqueue state UP
link/ether de:9a:ba:1c:2b:60 brd ff:ff:ff:ff:ff:ff
inet 10.244.103.93/32 scope global eth0
   valid_lft forever preferred_lft forever

eth0@if1694:这里eth0连接的设备号也是1694,其实这个设备就是veth pair，K8s在创建Pod的时候，会创建一个veth pair设备。设备的一端是pod的网卡，另一端就是我们在node中看见的calif118cc83606@if4
node2的网络与node1的结构一样，这里就不在赘述，接着，我们在看看node的route
node1

root@k8s-node-cpu-1:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         7.7.250.1       0.0.0.0         UG    100    0        0 eth0
7.7.250.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.244.54.64    7.7.250.112     255.255.255.192 UG    0      0        0 tunl0
10.244.103.64   0.0.0.0         255.255.255.192 U     0      0        0 *
10.244.103.76   0.0.0.0         255.255.255.255 UH    0      0        0 cali28b497ab82c
10.244.103.87   0.0.0.0         255.255.255.255 UH    0      0        0 cali98ef874e28b
10.244.103.91   0.0.0.0         255.255.255.255 UH    0      0        0 cali63d9a5db526
10.244.103.93   0.0.0.0         255.255.255.255 UH    0      0        0 calif118cc83606
10.244.103.108  0.0.0.0         255.255.255.255 UH    0      0        0 cali727b4dbb755
10.244.103.111  0.0.0.0         255.255.255.255 UH    0      0        0 calib9e39c47403
10.244.103.112  0.0.0.0         255.255.255.255 UH    0      0        0 calib41209c5fbf
10.244.103.113  0.0.0.0         255.255.255.255 UH    0      0        0 cali56756115774
10.244.103.115  0.0.0.0         255.255.255.255 UH    0      0        0 cali686493f32f5
10.244.103.116  0.0.0.0         255.255.255.255 UH    0      0        0 calib887b40925e
10.244.103.118  0.0.0.0         255.255.255.255 UH    0      0        0 cali2800bb83c8d
10.244.103.119  0.0.0.0         255.255.255.255 UH    0      0        0 cali3d3cdd474b2
10.244.103.120  0.0.0.0         255.255.255.255 UH    0      0        0 cali9db0936d821
10.244.103.121  0.0.0.0         255.255.255.255 UH    0      0        0 cali7276057dd49
10.244.103.122  0.0.0.0         255.255.255.255 UH    0      0        0 cali29f515035f9
10.244.103.123  0.0.0.0         255.255.255.255 UH    0      0        0 cali0b51b9ea0fe
10.244.119.0    7.7.250.56      255.255.255.192 UG    0      0        0 tunl0
10.244.132.128  7.7.250.99      255.255.255.192 UG    0      0        0 tunl0
10.244.154.192  7.7.250.140     255.255.255.192 UG    0      0        0 tunl0
10.244.162.0    7.7.250.154     255.255.255.192 UG    0      0        0 tunl0
10.244.206.128  7.7.250.216     255.255.255.192 UG    0      0        0 tunl0
10.244.232.128  7.7.250.207     255.255.255.192 UG    0      0        0 tunl0
10.244.248.128  7.7.250.133     255.255.255.192 UG    0      0        0 tunl0
10.244.252.64   7.7.250.173     255.255.255.192 UG    0      0        0 tunl0
169.254.169.254 7.7.250.10      255.255.255.255 UGH   100    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

node2

root@k8s-node-cpu-2:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         7.7.250.1       0.0.0.0         UG    100    0        0 eth0
7.7.250.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.244.54.64    7.7.250.112     255.255.255.192 UG    0      0        0 tunl0
10.244.103.64   7.7.250.91      255.255.255.192 UG    0      0        0 tunl0
10.244.119.0    7.7.250.56      255.255.255.192 UG    0      0        0 tunl0
10.244.132.128  7.7.250.99      255.255.255.192 UG    0      0        0 tunl0
10.244.154.192  7.7.250.140     255.255.255.192 UG    0      0        0 tunl0
10.244.162.0    7.7.250.154     255.255.255.192 UG    0      0        0 tunl0
10.244.206.128  7.7.250.216     255.255.255.192 UG    0      0        0 tunl0
10.244.232.128  0.0.0.0         255.255.255.192 U     0      0        0 *
10.244.232.129  0.0.0.0         255.255.255.255 UH    0      0        0 cali791ba3ae326
10.244.232.131  0.0.0.0         255.255.255.255 UH    0      0        0 caliabd8e32ae9b
10.244.232.134  0.0.0.0         255.255.255.255 UH    0      0        0 cali1a871390354
10.244.232.136  0.0.0.0         255.255.255.255 UH    0      0        0 cali2902dace78d
10.244.232.137  0.0.0.0         255.255.255.255 UH    0      0        0 calid3549ba9763
10.244.232.140  0.0.0.0         255.255.255.255 UH    0      0        0 calid75abf4f5e0
10.244.232.145  0.0.0.0         255.255.255.255 UH    0      0        0 cali2448ba71d7b
10.244.232.159  0.0.0.0         255.255.255.255 UH    0      0        0 cali00c062a9b0f
10.244.232.161  0.0.0.0         255.255.255.255 UH    0      0        0 cali8ee22f188ce
10.244.232.162  0.0.0.0         255.255.255.255 UH    0      0        0 cali6bc7c9b388a
10.244.232.163  0.0.0.0         255.255.255.255 UH    0      0        0 cali767b53297be
10.244.232.167  0.0.0.0         255.255.255.255 UH    0      0        0 calid244a185e38
10.244.232.173  0.0.0.0         255.255.255.255 UH    0      0        0 cali2904ebea0d8
10.244.232.177  0.0.0.0         255.255.255.255 UH    0      0        0 cali113cc1d4e7a
10.244.232.179  0.0.0.0         255.255.255.255 UH    0      0        0 cali10092744c78
10.244.232.180  0.0.0.0         255.255.255.255 UH    0      0        0 cali761e373fe81
10.244.248.128  7.7.250.133     255.255.255.192 UG    0      0        0 tunl0
10.244.252.64   7.7.250.173     255.255.255.192 UG    0      0        0 tunl0
169.254.169.254 7.7.250.10      255.255.255.255 UGH   100    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

结合上面的信息，我们可以得到如下的拓扑

梳理路由规则
如上图显示，
1.pod1中的eth0(即图中的vthe0)与calif118cc83606是一对veth pair，因此，calif118cc83606接收到的ip流向与vthe0相同，
2.查看node1 路由表，发现有一条 去往10.244.232.128/255.255.255.192的ip经过tunl0，以7.7.250.207作为网关发送到node2，node2 eth0的地址正是7.7.250.207。
3.经过tunl0的ip报会被再封上一层ip。通过node1 的路由规则，会发往eth0，因此我们在eth0处的抓包结果为

7.7.250.91> 7.7.250.207: IP 10.244.103.93> 10.244.232.180

node1
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.244.232.128  7.7.250.207     255.255.255.192 UG    0      0        0 tunl0
0.0.0.0         7.7.250.1       0.0.0.0         UG    100    0        0 eth0
10.244.103.93   0.0.0.0         255.255.255.255 UH    0      0        0 calif118cc83606

同样，node2的路由大致结构与node1类似，这里贴出路由表，不在赘述

node2
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.244.103.64   7.7.250.91      255.255.255.192 UG    0      0        0 tunl0
0.0.0.0         7.7.250.1       0.0.0.0         UG    100    0        0 eth0
10.244.232.180  0.0.0.0         255.255.255.255 UH    0      0        0 cali761e373fe81

总结

1.IPIP模式下，node间的Pod访问会使用IPIP技术对出node的ip报进行隧道封装
2.Pod的ip都是由calico-node设置的IP地址池进行分配的，docker0对kubernetes设置的Pod的IP地址将不再起作用。
、

weixin_43391291
关注
calico ipip 跨节点pod通信详解
weixin_49497353的博客
07-22 357
为了更好地了解calico ipip协议中跨节点之间pod通信
calico 架构及跨节点通信原理介绍
败八
11-03 7083
背景及calico简介 为了搞定 AI on k8s的网络环境，即夸节点容器通信的问题，在k8s多个网路解决方案中选择了延迟表现最好的-calico方案，本文主要介绍calico 架构、组件及网络通信原理，更多的细节在之后的文章中分享。 Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。 Calico的原理...
Calico IP_AUTODETECTION_METHOD
summer_fish的专栏
12-22 1376
模式时，确保 Kubernetes 集群正常运行，Calico 与 Kubernetes API 服务器正常通信，并且 Pod 的 IP 地址能够被正确分配和获取。这样，Calico 将能够有效地管理和路由容器的流量。是一种特殊的模式，用于在 Kubernetes 环境中检测容器的 IP 地址。的配置项用于指定 Calico 如何检测容器的 IP 地址。在 Calico 中，
kubernetes flannel 切换 calico 后节点 pod 无法通信
ygqygq2的IT博客
03-11 2249
文章目录1. 问题2. 问题排查3. 小结 1. 问题 版本： kubernetes version: NAME STATUS ROLES AGE VERSION master1 Ready control-plane,master 56d v1.23.4 master2 Ready control-plane,master 56d v1.23.4 master3 Ready control-plane,mas
K8S Calico IP In IP网络模式通信分析
jiayu的博客
09-04 468
代理 ARP 是 ARP 协议的一个变种，当 ARP 请求目标跨网段时，网关设备收到此 ARP 请求，会用自己的 MAC 地址返回给请求者，这便是代理 ARP（Proxy ARP）。下面这张图中，电脑发送 ARP 请求服务器8.8.8.8 的 MAC 地址，路由器（网关）收到这个请求时会进行判断，由于目标 8.8.8.8 不属于本网段（即跨网段），此时便返回自己的接口 MAC 地址给 PC，后续电脑访问服务器时，目标 MAC 直接封装为 MAC25。当一个数据包的目的地址不是本机时，就会查询路由表
Kubernetes_容器网络_Calico_04_Calico不同节点间Pod通信tunl0手动选择网卡
weixin_42468240的博客
07-14 118
文章目录系列文章目录前言Calico通过calixxx和tunl0网卡完成节点间Pod通信准备两台机器第一种情况 指定网卡1(白名单配置法)第二种情况 指定网卡2(白名单配置法)第三种情况 跳过指定网卡(黑名单配置法)第四种情况 通过网络连通性判断(指定IP)第五种情况 通过cidr判断总结 前言前面两篇学会了Calic...
Kubernetes内外网通信｜集群外节点访问 pod ip
weixin_48711696的博客
02-01 889
使常规虚拟机可以访问 pod ip
calico设置IPIP模式
ccy19910925的博客
12-20 5623
Configuring IP-in-IP If your network fabric performs source/destination address checks and drops traffic when those addresses are not recognized, it may be necessary to enable IP-in-IP encapsulation ...
如何使用Calico实现跨主机Docker网络通信
山河已无恙
01-03 1569
户外依然大雨滂沱，只是这回彷彿不仅命运一人独自哭泣，不晓得由来，窗外的雨水似乎渗上我心头，有些寒冻，有些缩麻，还有些苦涩。城市万家灯火，橘黄街灯与家户里的温暖流洩，我总觉得这时候的我，最脆弱。 -----《Unser Leben Unser Traum》
K8s 中跨主机 Pod 之间是如何通信的(CNI 使用 Calico)？
山河已无恙
04-08 788
被问到这个问题，整理相关笔记博文内容涉及：K8s 中 Pod 之间是如何通信的简单介绍，报文路径解析&&veth pair简单介绍理解 跨节点 Pod 通信，需要理解和veth pair没接触的小伙伴可以先看这两部分。理解不足小伙伴帮忙指正中国式催婚：爱不爱不重要，重要的是把婚结了。过的幸不幸福不重要，重要的是把婚结了。有钱没钱不重要，重要的是把婚结了。父母催你结婚的意义在于，你只要成家了，他们作父母的责任就尽完了。(余华)
记一次k8s的calico跨节点网络不通的问题及排错过程和解决方法
热门推荐
Explore
11-06 1万+
集群内布有四个节点： 节点名称 主机IP km1 192.168.1.1 kn1 192.168.1.2 kn2 192.168.1.3 kn3 192.168.1.4 网络不通的表征：进入节点km1的pod，ping kn1-3节点上的pod的ip都不通，kn1-3节点ping km1也不通，但是kn1 kn2 kn3之间他们各自节点上的pod的ip之间是可以相互ping通。 这种情况让我们想起了当时设置路由转发时候的配置，因为我们的四台服务器，只有一个公网IP，我们把19
一次calico跨节点POD网络不通的解决方法
weixin_34107955的博客
04-15 8801
2019独角兽企业重金招聘Python工程师标准>>> ...
k8s----网络通信机制（calico-IPIP，fiannel-VXLAN）caclicoctl命令
weixin_45697293的博客
08-20 1872
calico 默认部署为 CrossSubnet，此种模式在部署完成后，有可能造成节点之间无法正常通行，如果已经确定部署模式为 IPIP 模式，可以在部署前将 CALICO_IPV4POOL_IPIP=“CrossSubnet”，修改为。，Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口（网卡）上，Cni0 设备获得的ip地 址是该节点分配到的网段的第一个地址。，但是会存在安全性问题，其在内核内置，可以通过Calico的配置文件设置是否启用IPIP，在公司内部如果k8s的node节点。
flannel使用的vxlan和calico使用的IPIP对比
lingshengxiyou的博客
03-21 923
从上面的报文可以看出vxlan报文比原始报文多出了50个字节，包括8个字节的vxlan协议相关部分，8个字节的UDP头部，20个字节的IP头部和14个字节的MAC头部。
计算机网络笔记001
最新发布
cocofu的博客
09-22 721
通信网络研究的是通信终端（如电话）和内部通信问题，而计算机网络则更关注计算机之间的联网和通信，比如我们的Wi-Fi网络。分布式系统是一种建立在计算机网络之上的、 具有高度内聚性 ( Cohesiveness ) 和透明性 ( Transparency ) 的系统， 呈现给用户的是一 个统一的系统， 好像是一台计算机 。#### 学生D：云计算平台也是，像AWS，不同的服务如存储、计算和数据库虽然独立，但通过一个统一的管理界面和API协作，用户感觉是一个整体。#### 老师：没错，这是一部分。
kubernetes网络(一)之calico详解
鲜少伟的博客
09-22 1148
本文介绍Kubernetes最流行的网络解决方案calico。
网络高级day03（Http）
dghbs的博客
09-21 1140
HTTP
linux网络编程5
qq_65818377的博客
09-21 849
将套接字修改为被动，让操作系统给该套接字设置一个连接队伍，用来记录所有连接到该套接字的连接。关闭使用socket函数创建的套接字，会导致服务器无法接收新的连接，但不会影响已经连接的；其是关闭一个代表已经连接套接字，则会出现向另外一端接收到一个长度为0的数据包；关闭accept返回的套接字，则会导致其连接关闭，但不会影响服务器的；backlog：连接队列的长度，即设置服务器最大的连接客服的数量。其返回的是一个已连接的套接字，这个套接字代表当前这个连接。connect建立连接后不会产生新的套接字；
calico 跨节点 pod网络不通处理
05-25
如果 Calico 跨节点的 Pod 网络不通，可以尝试以下步骤进行排查和处理： 1. 检查网络策略是否正确配置。网络策略可以限制 Pod 之间的通信，如果策略有误，可能会导致 Pod 之间无法通信。 2. 检查网络插件是否正常...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值