K8s网络实战分析之Calico-ipip模式

最新推荐文章于 2024-09-13 15:30:55 发布
最新推荐文章于 2024-09-13 15:30:55 发布
阅读量1.6w 收藏 45
点赞数 6
分类专栏： 云原生
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010771890/article/details/103224004
版权

Kubernetes为每个Pod都分配了唯一的IP地址，一个Pod里的多个容器共享PodIp地址。Kubernetes要求底层网络支持集群内任意两个Pod间的TCP/IP直接通信。Kubernetes的跨主机任意Pod访问方式主要是遵循CNI容器网络规范，目前已经有多个开源组件支持CNI，包括Flannel、Open VSwitch、Calico等。本文主要介绍在Calico的ipip模式下，K8s的Pod间访问原理。

Calico容器网络简介

Calico是一个基于BGP的纯三层网络方案，其会为每个容器（pod）分配一个可路由的IP，在通信时不需要解包和拆包，因此网络性能损耗小，易于排查和水平扩展。

image.png

Calico标志

标题Calico架构

image.png
Calico网络模型主要工作组件：

  1. Felix：Calico Agent，运行在每一台 Host 的 agent 进程，主要负责网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报等，保证跨主机容器的网络互通。

  2. etcd：Calico的后端存储，主要负责网络元数据一致性，确保Calico网络状态的准确性，可以与kubernetes共用；

  3. BGP Client（BIRD）：Calico 为每一台 Host 部署一个 BGP Client，使用 BIRD 实现，BIRD 是一个单独的持续发展的项目，实现了众多动态路由协议比如 BGP、OSPF、RIP 等。负责将Felix 在各Node上的设置通过BGP协议广播到Calico网络，从而实现网络互通。

  4. BGP Route Reflector：在大型网络规模中，如果仅仅使用 BGP client 形成 mesh 全网互联的方案就会导致规模限制，因为所有节点之间俩俩互联，需要 N^2 个连接，为了解决这个规模问题，可以采用 BGP 的 Router Reflector 的方法，使所有 BGP Client 仅与特定 RR 节点互联并做路由同步，从而大大减少连接数。

IPIP模式简介

Calico中的IP Pool可以使用两种模式：BGP或者IPIP。本文使用的是IPIP模式，是一种将各Node的路由之间做一个tunnel，再把网络连接起来的模式：
image.png
从字面上说，就是将一个IP数据包套在另一个IP包里，使用到了Linux提供的隧道技术。可以理解为一个基于IP层的网桥，将两个本不通的网络通过点对点连接起来。

K8s-Calico-IPIP网络实战分析

下面我们就进行基于Calico-IPIP模式下的K8s容器互联网络分析。
##实验准备
准备了1master 2slaver的K8s集群，设置为Calico-IPIP网络。每个slaver内（node1，node2）分别部署了一个Pod容器，结构示意图如下：
image.png

网络结构解析

pod网络

首先通过指令 kubectl exec -it pod1 /bin/bash</font color=grey> 进入pod1容器中，再使用指令 ip addr</font color=grey> 查看pod1内的网络设备。

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
4: eth0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default 
    link/ether ce:83:2b:89:af:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.100.15.150/32 scope global eth0
       valid_lft forever preferred_lft forever

可以看到，pod只有普通的loopback和eth0。

node网络

先查看node网络设备。

ip addr
...省略部分
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:16:3e:02:03:5c brd ff:ff:ff:ff:ff:ff
    inet 172.31.112.2/20 brd 172.31.127.255 scope global dynamic eth0
       valid_lft 311927346sec preferred_lft 311927346sec
4: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.100.15.128/32 brd 10.100.15.128 scope global tunl0
       valid_lft forever preferred_lft forever
26: cali3ef8aad4b4e@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default 
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 1

node中除了eth0外，多了tunl0和cali3ef8aad4b4e（下面简称为cali.4e），结合之前的Calico简介，大家肯定可以猜到，tunl0就是Calico在IPIP模式下的隧道名称 ，而cali.4e是啥子类，注意到，该设备的编号为26。让我们回到pod1中，查看pod1内的ip link：

$ip link show eth0
4: eth0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP mode DEFAULT group default 
    link/ether ce:83:2b:89:af:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0

eth0@if26，这里eth0连接的设备号也是26！其实这个设备就是veth pair，K8s在创建Pod的时候，会创建一个veth pair设备。设备的一端是pod2的网卡，另一端就是我们在node中看见的cali.4e了。是不是清楚了很多☺node2与之类似。
下面我们将node节点的route规则也贴上，后面会用到。

node1
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.127.253  0.0.0.0         UG    0      0        0 eth0
10.100.6.128    172.31.112.1    255.255.255.192 UG    0      0        0 tunl0
10.100.9.192    172.31.127.252  255.255.255.192 UG    0      0        0 tunl0
10.100.15.128   0.0.0.0         255.255.255.192 U     0      0        0 *
10.100.15.129   0.0.0.0         255.255.255.255 UH    0      0        0 cali386c6dca3ac
10.100.15.150   0.0.0.0         255.255.255.255 UH    0      0        0 cali3ef8aad4b4e
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.31.112.0    0.0.0.0         255.255.240.0   U     0      0        0 eth0

node2
route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.127.253  0.0.0.0         UG    0      0        0 eth0
10.100.6.128    172.31.112.1    255.255.255.192 UG    0      0        0 tunl0
10.100.9.192    0.0.0.0         255.255.255.192 U     0      0        0 *
10.100.9.193    0.0.0.0         255.255.255.255 UH    0      0        0 cali4360a48538f
10.100.9.206    0.0.0.0         255.255.255.255 UH    0      0        0 cali2d771657bc2
10.100.9.207    0.0.0.0         255.255.255.255 UH    0      0        0 cali7116f2b12fa
10.100.15.128   172.31.112.2    255.255.255.192 UG    0      0        0 tunl0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.31.112.0    0.0.0.0         255.255.240.0   U     0      0        0 eth0

网络结构小结

根据上节的信息，绘出当前实验网络的主要设备图。后面将进行网络连接实战。
image.png

网络连接实战

node间连接

很容易的，我们先猜测一个从pod2发往pod1的ip数据流向。
image.png
下面让我们一起来验证我们的猜测吧！使用的工具就是tcpdump啦~
分别在两个node的Cali.c2、tunl0、eth0出进行抓包分析，结果如下图所示，其中Cali.c2与tunl0的ip完全一致，因此合并输出。
image.png
按照标志的①、②、③、④来依次分析：
①：上节已经说了，pod2中的eth0(即图中的vthe0)与Cali.c2是一对veth pair，因此，Cali.c2接收到的ip流向一定与vthe0相同，为 10.100.9.206->10.100.15.150</font color=grey>。查看之前的node2 route表，发现有一条 ：

 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.15.128   172.31.112.2    255.255.255.192 UG    0      0        0 tunl0

所有发往10.100.15.128/255.255.255.192的ip报都需要通过tunl0，经过172.31.112.2作为gateway发送。因此，cali.c2的ip报会发往tunl0。
②：经过tunl0的ip报会被再封上一层ip。通过node2 的route规则，会发往eth0，因此我们在eth0处的抓包结果为 172.31.127.252 > 172.31.112.2: IP 10.100.9.206 > 10.100.15.150</font color=grey>

 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.31.112.0    0.0.0.0         255.255.240.0   U     0      0        0 eth0

③、④：三和四其实就是①、②的逆过程，检查node1的route表即可知道流向。etho0将ipip拆封后，将流量发给tunl0，tunl0再转发给cali.4e。

 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.15.150   0.0.0.0         255.255.255.255 UH    0      0        0 cali3ef8aad4b4e

node内连接

如果是同一个node内的两个pod进行访问，那么还会走tunl0进行ipip封装吗？
其实很容易回答这个问题，通过上节的route规则就可以知道，Calico会为每一个node分配一小段网络，同时会Wie每个pod创建一个“入”的ip route规则。如下图所示，当从pod2访问pod3时，Cali.c2是直接发出10.100.9.206-> 10.100.9.207</font color=grey>流量的，在node2的ip route中，发往10.100.9.207的ip报直接会被转发到cali.fa，不会用到tunl0，只有在node间访问的时候才会使用tunl0进行ipip封装！

 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.9.207    0.0.0.0         255.255.255.255 UH    0      0        0 cali7116f2b12fa

image.png

总结

通过上节的实战与分析，相信大家一定对Calico-ipip网络有了比较清晰的印象，文章最后做个小结：

  1. IPIP模式下，node间的Pod访问会使用IPIP技术对出node的ip报进行隧道封装
  2. node内的Pod访问不会用到ipip隧道封装。
  3. Pod的ip都是由calico-node设置的IP地址池进行分配的，docker0对kubernetes设置的Pod的IP地址将不再起作用。
    下一篇我会基于本文的实战基础，对kubernetes service的网络调用进行实战分析。
碰碰猪
关注
专栏目录
k8s cluster ip VS node port 网络原理
博然的宝藏库
10-23 420
nat后： srt: 2.2.2.30 (node ip ) dest: 1.1.1.1:443 (真实的pod ip + 端口)nat前： srt: 1.1.1.30 （client ip ） dest: 2.2.2.30:38888 (node ip + 端口)nat前： srt: 1.1.1.1:443 (真实的pod ip ) dest: 2.2.2.30 (node ip )
【实战加详解】二进制部署k8s高可用集群教程系列十三 - 部署calico
JohnYang's CSDN Home
10-13 602
实战加详解 - 完美解决二进制部署k8s高可用集群中ssl证书以及TLS Bootstrap机制的问题
k8s calico ipip模式详解
魏志标的博客
06-28 2677
Calico 是一种容器之间互通的网络方案。在虚拟化平台中，比如 OpenStack、Docker 等都需要实现 workloads 之间互连，但同时也需要对容器做隔离控制。而在多数的虚拟化平台实现中，通常都使用二层隔离技术来实现容器的网络，这些二层的技术有一些弊端，比如需要依赖 VLAN、bridge 和隧道等技术，其中 bridge 带来了复杂性，vlan 隔离和 tunnel 隧道则消耗更多的资源并对物理环境有要求，随着网络规模的增大，整体会变得越加复杂。
k8s网络原理之Calico
weixin_36841480的博客
09-12 201
之前整理总结过有关flannel的相关原理以及详细的传输过程，一直都想总结一篇通俗易懂的有关calico的相关原理和传输过程的，因为平常事情较多，没想到一拖就是这么久，这回借着复习的机会，将calico的原理，传输过程，以及各组件的作用还有两种模式进行了细致的讲解和分析对比，也是对自己之前学习的一个总结，希望对大家有帮助。 什么是Calico: Calico是一个基于BGP的纯三层网络方案，其会...
K8S Calico网络插件之IPIP模式
Blue summer的博客
10-10 4420
注：本文基于K8S v1.21.2版本编写 1 关于Calico flannel是overlay网络, 主要工作在L2(VXLAN)，calico主要是L3，通过BGP路由协议在机器之间传送报文。 2 安装Calico(IPIP模式） 因为之前有安装flannel，因此需要先删除， kubectl delete -f kube-flannel.yml 同时需要删除flannel.1和cni0这两个网络设备， ip link delete cni0 ip link delete flannel.1 之后就
Kubernetes CNI组件Calico：IPIP工作模式
小楼一夜听春雨，深巷明朝卖杏花
03-16 4737
CNI存在的意义 为了对接第三方的网络组件，提供一种接口，实现接口逻辑的松耦合 K8s网络组件之Calico Calico是一个纯三层（基于路由的）的数据中心网络方案，Calico支持广泛的平台，包括Kubernetes、OpenStack等。 Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器（ vRouter） 来负责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播..
kubeadm安装k8s 1.25高可用集群
青梅煮酒
02-05 2618
calico BGP通信是基于TCP协议的，所以只要节点间三层互通即可完成，即三层互通的环境bird就能生成与邻居有关的路由。但是这些路由和flannel host-gateway模式一样，需要二层互通才能访问的通，因此如果在实际环境中配置了BGP模式生成了路由但是不同节点间pod访问不通，可能需要再确认下节点间是否二层互通。为了解决节点间二层不通场景下的跨节点通信问题，calico也有自己的解决方案——IPIP模式。
企业入门实战--k8s之vxlan 、calico、 ingress实现七层负载均衡
鱼子酱
07-29 963
企业入门实战--k8s之vxlan 、calico、 ingress实现七层负载均衡Flannel vxlanDR模式实现calico网络插件替换flannelcalico支持的网络策略-访问控制Ingress-nginx七层负载均衡实现安装Ingress Flannel vxlan DR模式实现 flannel支持多种后端，包括 vxlan默认报文封装模式，适用于跨网段通信 Directrouting直连路由模式，适用于同网段通信。表现为host-gw，主机网关，性能好，但只能在二层网络中，不支持跨网。
K8S Calico网络插件
「 虚幻私塾」
05-24 2032
🚀 优质资源分享 🚀 学习路线指引（点击解锁） 知识定位 人群定位 🧡 Python实战微信订餐小程序 🧡 进阶级 本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。 💛Python量化交易实战💛 入门级 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 目录 0.前言 1.Calico概述 1.1.Calico组件 1.2.Calico网络实现 1.3.了解Calico对CIDR子网的划分（blockSiz
Kubernetes网络插件详解 - Calico篇 - 概述
m0_72650596的博客
08-05 906
Kubernetes容器网络比较复杂，需要与底层基础设施及上层业务来确定容器网络方案，同时很多网络插件又支持多种模式，需要大量的网络的基础知识支撑才能了解清楚。选择合适的CNI插件，需要综合考虑底层网络网络拓扑，结合应用需要的网络功能，以及网络路由协议的需求。Calico是比较成熟的容器网络插件，功能上比较丰富，性能上也在不断优化。...
企业运维实战--k8s学习笔记4.k8s网络通信、Flannel vxlan模式简介、calico网络插件替换、网络策略范例总结
Rabbit_hyl的博客
07-28 611
企业运维实战--k8s学习笔记4.k8s网络通信、Flannel vxlan模式简介、calico网络插件替换、网络策略范例编写一、k8s网络通信简介（重点）二、Flannel vxlan模式简介Flannel vxlan模式跨主机通信原理简介DR模式实现三、calico网络插件替换flannel四、calico支持的网络策略-类似访问控制 一、k8s网络通信简介（重点） k8s是通过CNI接口接入插件来实现网络通讯的。目前较为流行的插件有flannel、calico等。 插件存放位置在/etc/cni/
一文明白calico的IPIP网络模式
wanger5354的博客
01-14 1171
前言本文主要分析k8s中网络组件calico的 IPIP网络模式。旨在理解IPIP网络模式下产生的calixxxx，tunl0等设备以及跨节点网络通信方式。可能看着有点枯燥，但是请花几分钟时间坚持看完，如果看到后面忘了前面，请反复看两遍，这几分钟时间一定你会花的很值。一、calico介绍Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择，但Calico以其性能、灵活性而闻名。Calico的功能更为全面，不仅提供主机和pod之间的网络连接，还涉及网络安全
10 张图解 K8S CNI Calico 网络模型原理与功能实战
2201_75362610的博客
08-15 2155
Calico` 是一个联网和网络策略供应商。Calico 支持一套灵活的网络选项，因此你可以[根据自己的情况选择最有效的选项，包括非覆盖和覆盖网络，带或不带 BGP。
calico IPIP跨节点通信
最新发布
weixin_43391291的博客
09-13 973
一般来说，普通的网桥是基于mac层的，根本不需 IP，而这个 ipip 则是通过两端的路由做一个 tunnel，把两个本来不通的网络通过点对点连接起来.node中除了eth0外，多了tunl0和calif118cc83606@if4，tunl0就是Calico在IPIP模式下的隧道名称 ，而calif118cc83606@if4，注意到，该设备的编号为1694。node2的网络与node1的结构一样，这里就不在赘述，接着，我们在看看node的route。一个简单的demo，模拟IPIP之间的通信。
calico设置IPIP模式
ccy19910925的博客
12-20 5655
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 ...
k8s CNI Calico 网络模式总结【建议收藏】
不忘初心，方得始终
04-02 1572
IP in IP 使用 20 字节标头，IPv4 VXLAN 使用 50 字节标头，IPv6 VXLAN 使用 70 字节标头，IPv4 WireGuard 使用60 字节标头，IPv6 WireGuard 使用 80 字节标头。全网格非常适合 100 个或更少节点的中小型部署，但在规模明显更大时，全网格的效率会降低，我们建议使用路由反射器。备注： IBGP & EBGP 结合使用，集群大于100个节点以后使用TOR模式可以带来很好的性能。
calico的ipip与bgp的模式分析
那达慕的博客
09-27 4517
1、前言 BGP工作模式： bgp工作模式和flannel的host-gw模式几乎一样； bird是bgd的客户端，与集群中其它节点的bird进行通信，以便于交换各自的路由信息； 随着节点数量N的增加，这些路由规则将会以指数级的规模快速增长，给集群本身网络带来巨大压力，官方建议小于100个节点； 限制：和flannel的host-gw限制一样，要求物理机在二层是连能的，不能跨网段； Route ...
k8s calico网络原理以及多租户实现设计
虾米的博客
04-07 1万+
软件定义网络SDN 基础概念介绍 租户（Tenant）：在网络资源上完全隔离的一个用户，在业务上可以代表一个对于网络有隔离和管理需求的部门。一个租户可以对应多个网络。 网络（Network）：在业务上可以代表一个部门下的一个项目组。一个网络只能挂在一个租户下面，同时可以有多个子网。 子网（Subnet）：在业务上可以代表一个部门下项目组的一个开发或测试环境。同一个net
【k8s】K8S中的IP地址(Node IP、Pod IP、Cluster IP、External IP、Internal-IP)
热门推荐
m0_45406092的博客
07-21 2万+
文章目录参考 kubernetes里有三张不同的网络，每种IP地址，就代表一个不同的寻址空间： Node IP：Node节点的IP地址 Pod IP：Pod的IP地址 Cluster IP：Service的IP地址 首先，Node IP是kubernetes集群中每个节点的物理网卡的IP地址（包括虚拟机的网卡），这是一个真实存在的物理网络，所有属于这个网络的服务器之间都能通过这个网络进行通信，不管他们中是否有部分节点不属于这个kebernetes集群。这也表明了Kubenetes集群之外的节点访问Kub
手动安装k8s集群的网络插件flanneld-v0.12.0
资源摘要信息:"flanneld-v0.12.0-amd64.zip是一个专为Kubernetes（k8s）集群设计的网络插件的压缩包文件，版本为v0.12.0。这个压缩包被设计用于在k8s集群安装过程中，特别是当网络插件flannel无法通过常规的在线下载...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值