31 网络通信:CNI是怎么回事?又是怎么工作的?
你好,我是Chrono。
到现在,我们对Kubernetes已经非常熟悉了,它是一个集群操作系统,能够管理大量计算节点和运行在里面的应用。不过,还有一个很重要的基础知识我们还没有学习,那就是“网络通信”。
早在“入门篇”的第6讲里,我们就简单介绍过Docker的网络模式,然后在“中级篇”的第17讲,我们又为Kubernetes安装了一个网络插件Flannel。这些都与网络相关,但也只是浅尝辄止,并没有太多深究。
如果你是一个喜欢刨根问底的人,会不会很好奇:Flannel到底是如何工作的呢?它为什么能够让Kubernetes集群正常通信呢?还有没有其他网络插件呢?
今天我们就来聊一下这个话题,讲讲Kubernetes的网络接口标准CNI,以及Calico、Cilium等性能更好的网络插件。
Kubernetes的网络模型
在学习Kubernetes的网络之前,我们还是要先简单回顾一下Docker的网络知识。
你对Docker的null、host和bridge三种网络模式还有印象吗?这里我重新画了一张图,描述了Docker里最常用的bridge网络模式:
Docker会创建一个名字叫“docker0”的网桥,默认是私有网段“172.17.0.0/16”。每个容器都会创建一个虚拟网卡对(veth pair),两个虚拟网卡分别“插”在容器和网桥上,这样容器之间就可以互联互通了。
Docker的网络方案简单有效,但问题是它只局限在单机环境里工作,跨主机通信非常困难(需要做端口映射和网络地址转换)。
针对Docker的网络缺陷,Kubernetes提出了一个自己的网络模型“IP-per-pod”,能够很好地适应集群系统的网络需求,它有下面的这4点基本假设:
- 集群里的每个Pod都会有唯一的一个IP地址。
- Pod里的所有容器共享这个IP地址。
- 集群里的所有Pod都属于同一个网段。
- Pod直接可以基于IP地址直接访问另一个Pod,不需要做麻烦的网络地址转换(NAT)。
我画了一张Kubernetes网络模型的示意图,你可以看一下:
这个网络让Pod摆脱了主机的硬限制,是一个“平坦”的网络模型,很好理解,通信自然也非常简单。
因为Pod都具有独立的IP地址,相当于一台虚拟机,而且直连互通,也就可以很容易地实施域名解析、负载均衡、服务发现等工作,以前的运维经验都能够直接使用,对应用的管理和迁移都非常友好。
什么是CNI
Kubernetes定义的这个网络模型很完美,但要把这个模型落地实现就不那么容易了。所以Kubernetes就专门制定了一个标准:CNI(Container Networking Interface)。
CNI为网络插件定义了一系列通用接口,开发者只要遵循这个规范就可以接入Kubernetes,为Pod创建虚拟网卡、分配IP地址、设置路由规则,最后就能够实现“IP-per-pod”网络模型。
依据实现技术的不同,CNI插件可以大致上分成“Overlay”“Route”和“Underlay”三种。
Overlay的原意是“覆盖”,是指它构建了一个工作在真实底层网络之上的“逻辑网络”,把原始的Pod网络数据封包,再通过下层网络发送出去,到了目的地再拆包。因为这个特点,它对底层网络的要求低,适应性强,缺点就是有额外的传输成本,性能较低。
Route也是在底层网络之上工作,但它没有封包和拆包,而是使用系统内置的路由功能来实现Pod跨主机通信。它的好处是性能高,不过对底层网络的依赖性比较强,如果底层不支持就没办法工作了。
Underlay就是直接用底层网络来实现CNI,也就是说Pod和宿主机都在一个网络里,Pod和宿主机是平等的。它对底层的硬件和网络的依赖性是最强的,因而不够灵活,但性能最高。
自从2015年CNI发布以来,由于它的接口定义宽松,有很大的自由发挥空间,所以社区里就涌现出了非常多的网络插件,我们之前在第17讲里提到的Flannel就是其中之一。
Flannel(https://github.com/flannel-io/flannel/)由CoreOS公司(已被Redhat收购)开发,最早是一种Overlay模式的网络插件,使用UDP和VXLAN技术,后来又用Host-Gateway技术支持了Route模式。Flannel简单易用,是Kubernetes里最流行的CNI插件,但它在性能方面表现不是太好,所以一般不建议在生产环境里使用。
现在还有两个常用CNI插件:Calico、Cilium,我们做个简略的介绍。
Calico(https://github.com/projectcalico/calico)是一种Route模式的网络插件,使用BGP协议(Border Gateway Protocol)来维护路由信息,性能要比Flannel好,而且支持多种网络策略,具备数据加密、安全隔离、流量整形等功能。
Cilium(https://github.com/cilium/cilium)是一个比较新的网络插件,同时支持Overlay模式和Route模式,它的特点是深度使用了Linux eBPF技术,在内核层次操作网络数据,所以性能很高,可以灵活实现各种功能。在2021年它加入了CNCF,成为了孵化项目,是非常有前途的CNI插件。
CNI插件是怎么工作的
Flannel比较简单,我们先以它为例看看CNI在Kubernetes里的工作方式。
这里必须要说明一点,计算机网络很复杂,有IP地址、MAC地址、网段、网卡、网桥、路由等许许多多的概念,而且数据会流经多个设备,理清楚脉络比较麻烦,今天我们会做一个大概的描述,不会讲那些太底层的细节。
我们先来在实验环境里用Deployment创建3个Nginx Pod,作为研究对象:
使用命令 kubectl get pod
可以看到,有两个Pod运行在master节点上,IP地址分别是“10.10.0.3”“10.10.0.4”,另一个Pod运行在worker节点上,IP地址是“10.10.1.77”:
Flannel默认使用的是基于VXLAN的Overlay模式,整个集群的网络结构我画了一张示意图,你可以对比一下Docker的网络结构:
从单机的角度来看的话,Flannel的网络结构和Docker几乎是一模一样的,只不过网桥换成了“cni0”,而不是“docker0”。
接下来我们来操作一下,看看Pod里的虚拟网卡是如何接入cni0网桥的。
在Pod里执行命令 ip addr
就可以看到它里面的虚拟网卡“eth0”:
你需要注意它的形式,第一个数字“3”是序号,意思是第3号设备,“@if45”就是它另一端连接的虚拟网卡,序号是45。
因为这个Pod的宿主机是master,我们就要登录到master节点,看看这个节点上的网络情况,同样还是用命令 ip addr
:
这里就可以看到宿主机(master)节点上的第45号设备了,它的名字是 veth41586979@if3
,“veth”表示它是一个虚拟网卡,而后面的“@if3”就是Pod里对应的3号设备,也就是“eth0”网卡了。
那么“cni0”网桥的信息该怎么查看呢?这需要在宿主机(master)上使用命令 brctl show
:
从这张截图里,你可以发现“cni0”网桥上有4个虚拟网卡,第三个就是“veth41586979”,所以这个网卡就被“插”在了“cni0”网桥上,然后因为虚拟网卡的“结对”特性,Pod也就连上了“cni0”网桥。
单纯用Linux命令不太容易看清楚网卡和网桥的联系,所以我把它们整合在了下面的图里,加上了虚线标记,这样你就能更清晰地理解Pod、veth和cni0的引用关系了:
使用同样的方式,你可以知道另一个Pod “10.10.0.4”的网卡是 veth2b3ef56d@if3
,它也在“cni0”网桥上,所以借助这个网桥,本机的Pod就可以直接通信。
弄清楚了本机网络,我们再来看跨主机的网络,它的关键是节点的路由表,用命令 route
查看:
它告诉我们有这些信息:
- 10.10.0.0/24网段的数据,都要走cni0设备,也就是“cni0”网桥。
- 10.10.1.0/24网段的数据,都要走flannel.1设备,也就是Flannel。
- 192.168.10.0/24网段的数据,都要走ens160设备,也就是我们宿主机的网卡。
假设我们要从master节点的“10.10.0.3”访问worker节点的“10.10.1.77”,因为master节点的“cni0”网桥管理的只是“10.10.0.0/24”这个网段,所以按照路由表,凡是“10.10.1.0/24”都要让flannel.1来处理,这样就进入了Flannel插件的工作流程。
然后Flannel就要来决定应该如何把数据发到另一个节点,在各种表里去查询。因为这个过程比较枯燥,我就不详细说了,你可以参考下面的示意图,用到的命令有 ip neighbor
、bridge fdb
等等:
Flannel得到的结果就是要把数据发到“192.168.10.220”,也就是worker节点,所以它就会在原始网络包前面加上这些额外的信息,封装成VXLAN报文,用“ens160”网卡发出去,worker节点收到后再拆包,执行类似的反向处理,就可以把数据交给真正的目标Pod了。
使用Calico网络插件
看到这里,是不是觉得Flannel的Overlay处理流程非常复杂,绕来绕去很容易让人头晕,那下面我们就来看看另一个Route模式的插件Calico。
你可以在Calico的网站(https://www.tigera.io/project-calico/)上找到它的安装方式,我选择的是“本地自助安装(Self-managed on-premises)”,可以直接下载YAML文件:
由于Calico使用的镜像较大,为了加快安装速度,可以考虑在每个节点上预先使用 docker pull
拉取镜像:
docker pull calico/cni:v3.23.1
docker pull calico/node:v3.23.1
docker pull calico/kube-controllers:v3.23.1
Calico的安装非常简单,只需要用 kubectl apply
就可以(记得安装之前最好把Flannel删除):
安装之后我们来查看一下Calico的运行状态,注意它也是在“kube-system”名字空间:
我们仍然创建3个Nginx Pod来做实验:
我们会看到master节点上有两个Pod,worker节点上有一个Pod,但它们的IP地址与刚才Flannel的明显不一样了,分别是“10.10.219.*”和“10.10.171.*”,这说明Calico的IP地址分配策略和Flannel是不同的:
然后我们来看看Pod里的网卡情况,你会发现虽然还是有虚拟网卡,但宿主机上的网卡名字变成了 calica17a7ab6ab@if4
,而且并没有连接到“cni0”网桥上:
这是不是很奇怪?
其实这是Calico的工作模式导致的正常现象。因为Calico不是Overlay模式,而是Route模式,所以它就没有用Flannel那一套,而是在宿主机上创建路由规则,让数据包不经过网桥直接“跳”到目标网卡去。
来看一下节点上的路由表就能明白:
假设Pod A“10.10.219.67”要访问Pod B“10.10.219.68”,那么查路由表,知道要走“cali051dd144e34”这个设备,而它恰好就在Pod B里,所以数据就会直接进Pod B的网卡,省去了网桥的中间步骤。
Calico的网络架构我也画了一张示意图,你可以再对比Flannel来学习:
至于在Calico里跨主机通信是如何路由的,你完全可以对照着路由表,一步步地“跳”到目标Pod去(提示:tunl0设备)。
小结
好说了这么多,你应该看到了,Kubernetes的整个网络数据传输过程有大量的细节,非常多的环节都参与其中,想把它彻底弄明白还真不是件容易的事情。
不过好在CNI通过“依赖倒置”的原则把这些工作都交给插件去解决了,不管下层是什么样的环境,不管插件是怎么实现的,我们在Kubernetes集群里只会有一个干净、整洁的网络空间。
我来简单小结一下今天的内容:
- Kubernetes使用的是“IP-per-pod”网络模型,每个Pod都会有唯一的IP地址,所以简单易管理。
- CNI是Kubernetes定义的网络插件接口标准,按照实现方式可以分成“Overlay”“Route”和“Underlay”三种,常见的CNI插件有Flannel、Calico和Cilium。
- Flannel支持Overlay模式,它使用了cni0网桥和flannel.1设备,本机通信直接走cni0,跨主机通信会把原始数据包封装成VXLAN包再走宿主机网卡发送,有性能损失。
- Calico支持Route模式,它不使用cni0网桥,而是创建路由规则,把数据包直接发送到目标网卡,所以性能高。
课下作业
最后是课下作业时间,给你留两个思考题:
- Kubernetes没有内置网络实现,而是用CNI定义了标准接口,这么做的好处在哪里?
- 你对Flannel和Calico这两个网络插件的工作模式有什么样的看法?
欢迎在留言区发言参与讨论,这是最后一节知识点学习课,下节课我们进入回顾总结,曙光就在前方,期待你在马上到来的实操课和视频课中见证自己的成长。下节课见。
- Obscure 👍(7) 💬(3)
网络基础不行,这一节内容基本看不懂。。。咋整。。。
2022-09-07 - dao 👍(6) 💬(1)
试着思考了一下: 1,定义规范/标准,也就是接口(interface),把具体实现/扩展交给社区/第三方,然后使用插件(addon)的方式在 Kubernets 里应用,这真是个省力的方式!不需要去关注千变万化的底层运行环境。 2,Flannel 默认是 Overlay 模式基于Linux VxLan,数据包在跨节点间传输有封包和拆包的额外步骤,同节点的 Pod 间数据传输直接通过虚拟网桥,比如 cni0;不同节点的 Pod 间的数据传输需要借助 Flannel.1 (VTEP virtual tunnel endpoint) 分发。 Calico 也有多种工作模式,默认是 IPinIP,同节点的 Pod 间直接通过虚拟网卡结合路由表传输,跨节点间的 Pod 需要IP层的封装,数据包通过IP隧道传输,如 tunl0。多节点间的路由通过BGP协议共享。 在节点上抓包观察同节点 Pod 和 跨节点 Pod 数据传输: ```bash kubectl exec -it ngx-dep-bfbb5f64b-87sm4 -- curl 10.244.225.25 sudo tcpdump -n -s0 -i any host 10.244.225.25 kubectl exec -it ngx-dep-bfbb5f64b-87sm4 -- curl 10.244.185.207 sudo tcpdump -n -s0 -i any host 10.244.185.207 ```
2022-10-04 - Singin in the Rain 👍(4) 💬(1)
1、Mac VirtualBox ubuntu 22.04虚拟机环境安装Calico网络插件时,也需要指定网卡。如果enp0s3为Host-Only模式的网卡,enp0s8为NAT网络模式网卡。Flannel和Calico默认使用了enp0s8,所有虚拟机节点enp0s8网卡的IP地址是一样的,会导致冲突,Calico具体表现为calico-node只能启动一个,其他的为crashloopbackoff。因此安装的时候需要指定网卡为Host-Only模式的网卡enp0s3。详见链接:https://www.cnblogs.com/xiaohaoge/p/16953849.html 2、安装Calico或者Flannel过程中意外导致失败,需要清除一下网络插件的安装信息,重启kubelet。 rm -rf /etc/cni/net.d/* rm -rf /var/lib/cni/calico systemctl restart kubelet 详见链接:https://cloud.tencent.com/developer/article/1820462 如果还不能正常工作,需要检查一下coredns服务,然后重启dns服务: kubectl -n kube-system rollout restart deployment coredns
2023-06-20 - 美妙的代码 👍(4) 💬(1)
生产环境建议用哪个网络插件呢?
2022-09-09 - 杨丁 👍(4) 💬(1)
老师好,您画图用的啥工具啊
2022-09-06 - Lorry 👍(0) 💬(1)
老师,好像启用了calico之后,发现grafana以及Prometheus只能在pod所在的节点访问,其他节点都无法访问grafana页面以及Prometheus页面
2023-07-30 - 糊涂小孩123 👍(0) 💬(1)
/opt/cni/bin里的flannel跟以ds部署的flanneld是怎么个关系呢?这块原理是如何的
2023-06-02 - Lorry 👍(0) 💬(1)
hostNetwork是不是属于underlay?
2023-02-10 - 摊牌 👍(0) 💬(1)
引用原文 : "这里我重新画了一张图,描述了 Docker 里最常用的 bridge 网络模式:" 该图中的最下方的位置,ens160是表示啥?请老师帮忙解答下,谢谢
2023-01-29 - 明月夜 👍(0) 💬(1)
老师好,在节点上(在Pod外)好像也是能访问某个Pod的ip的,这种情况的IP寻址是不是也和在Pod里面的寻址一样?
2022-09-18 - 罗耀龙@坐忘 👍(0) 💬(1)
按照老师的教程,成功从flannel换成calico了
2022-09-03 - 罗耀龙@坐忘 👍(0) 💬(1)
老师,calico的版本是v3.24.1了
2022-09-03 - peter 👍(0) 💬(1)
请教老师一个问题: Q1:怎么修改Prometheus的镜像源格式? 第30课的问题。 我的虚拟机上:prometheus-adapter的状态是CrashLoopBackOff。 针对这个问题,老师的回答是:“exec format error”这样的感觉都是镜像的格式不对,比如amd64/arm64,换个镜像试试。 我是按照老师的如下要求修改的: image: chronolaw/kube-state-metrics:v2.5.0 image: chronolaw/prometheus-adapter:v0.9.1 我的电脑是win10, intel的CPU,应该是x86系列,请问应该怎么修改上面的image语句?
2022-09-02 - 卩杉 👍(0) 💬(0)
calico-kube-controllers-54756b744f-s94cq 1/1 Running 0 10h 10.10.219.65 master <none> <none> calico-node-6jm8l 1/1 Running 0 10h 192.168.14.142 master <none> <none> calico-node-h5fln 0/1 Error 94 10h 192.168.14.143 worker <none> <none> 我 worker 节点上有个 calico-node-h5fln 一直 Error,我用 describe 看提示重启失败,报错信息比较少: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Created 27m (x92 over 10h) kubelet Created container calico-node Warning BackOff 23m (x55 over 9h) kubelet Back-off restarting failed container Normal Pulled 55s (x97 over 10h) kubelet Container image "docker.io/calico/node:v3.23.5" already present on machine
2023-06-28