首页
常用命令
About Me
推荐
导航自定义连接:
weibo
github
Search
1
linuxea:gitlab-ci之docker镜像质量品质报告
48,943 阅读
2
linuxea:如何复现查看docker run参数命令
20,264 阅读
3
Graylog收集文件日志实例
17,970 阅读
4
git+jenkins发布和回滚示例
17,550 阅读
5
linuxea:jenkins+pipeline+gitlab+ansible快速安装配置(1)
17,515 阅读
ops
Openvpn
Sys Basics
rsync
Mail
NFS
Other
Network
HeartBeat
server 08
Code
Awk
Shell
Python
Golang
virtualization
KVM
Docker
openstack
Xen
kubernetes
kubernetes-cni
Service Mesh
Data
Mariadb
PostgreSQL
MongoDB
Redis
MQ
Ceph
TimescaleDB
kafka
surveillance system
zabbix
ELK Stack
Open-Falcon
Prometheus
Web
apache
Tomcat
Nginx
自动化
Puppet
Ansible
saltstack
Proxy
HAproxy
Lvs
varnish
更多
音乐
影视
music
Internet Consulting
最后的净土
软件交付
持续集成
gitops
devops
登录
Search
标签搜索
kubernetes
docker
zabbix
Golang
mariadb
持续集成工具
白话容器
linux基础
nginx
elk
dockerfile
Gitlab-ci/cd
最后的净土
基础命令
jenkins
docker-compose
gitops
haproxy
saltstack
Istio
marksugar
累计撰写
676
篇文章
累计收到
140
条评论
首页
栏目
ops
Openvpn
Sys Basics
rsync
Mail
NFS
Other
Network
HeartBeat
server 08
Code
Awk
Shell
Python
Golang
virtualization
KVM
Docker
openstack
Xen
kubernetes
kubernetes-cni
Service Mesh
Data
Mariadb
PostgreSQL
MongoDB
Redis
MQ
Ceph
TimescaleDB
kafka
surveillance system
zabbix
ELK Stack
Open-Falcon
Prometheus
Web
apache
Tomcat
Nginx
自动化
Puppet
Ansible
saltstack
Proxy
HAproxy
Lvs
varnish
更多
音乐
影视
music
Internet Consulting
最后的净土
软件交付
持续集成
gitops
devops
页面
常用命令
About Me
推荐
导航自定义连接:
weibo
github
搜索到
5
篇与
kubernetes-cni
的结果
2022-06-12
linuxea: flannel udp不同节点的pod通信
如下图所示我们先查看下pod的调度情况,分别是10.11.1.45和10.11.0.10在不同的两个节点,并且是不同的网段不同的网段,那么久需要查找路由表,看路由信息[root@master1 ~]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE marksugar-deployment-578cdd567b-968gg 1/1 Running 4 8d 10.11.1.45 node1 marksugar-deployment-578cdd567b-fw5rh 1/1 Running 4 8d 10.11.1.48 node1 marksugar-deployment-578cdd567b-nfhtt 1/1 Running 8 12d 10.11.0.10 master1里面分别有两个网卡,分别是eth0和lopod尾968gg开头的mac地址是9e:66:19:aa:f6:c7,ip是10.11.1.45[root@master1 ~]# kubectl exec -it marksugar-deployment-578cdd567b-968gg -- ip a 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 3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default link/ether 9e:66:19:aa:f6:c7 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.11.1.45/24 brd 10.11.1.255 scope global eth0 valid_lft forever preferred_lft foreverpod尾nfhtt开头的mac地址是ee:a2:33:a2:b6:69,ip是10.11.0.10[root@master1 ~]# kubectl exec -it marksugar-deployment-578cdd567b-nfhtt -- ip a 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 3: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default link/ether ee:a2:33:a2:b6:69 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.11.0.10/24 brd 10.11.0.255 scope global eth0 valid_lft forever preferred_lft forever路由匹配原则我们在上面知道,不同的网段通讯,需要查找路由表,看路由信息,我们就可以查询下路由信息[root@master1 ~]# kubectl exec -it marksugar-deployment-578cdd567b-968gg -- route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.11.1.1 0.0.0.0 UG 0 0 0 eth0 10.11.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.244.0.0 10.11.1.1 255.255.0.0 UG 0 0 0 eth0路由匹配是最长匹配原则,大致意思是,越精确的信息优先路由匹配是最长匹配原则,大致意思是,越精细的信息优先,什么意思呢如果是一个ip就优先匹配,而后在到0.0.0.0的默认路由,如果有就走,如过没有就丢掉当我们ping的时候,就会走默认路由,将信息发送到网关,也就是10.11.1.1要ping通,就需要源ip,目标ip,源mac,目标mac路由转发前提路由转发中ip是不变的,mac地址每经过一条都会发送变化也就是说源ip和目标ip是不发生改变的,但是源mac和目的mac是一直在变的如上,10.11.1.45的路由表的信息的下一条是10.11.1.1,他们属于同一个网段,因此只需要解析到二层即可。解析的mac地址在宿主机上是ee:e9:19:55:93:d1,如下7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default qlen 1000 link/ether ee:e9:19:55:93:d1 brd ff:ff:ff:ff:ff:ff inet 10.11.1.1/24 brd 10.11.1.255 scope global cni0 valid_lft forever preferred_lft forever inet6 fe80::ece9:19ff:fe55:93d1/64 scope link valid_lft forever preferred_lft forever开始抓包我们进行抓包来查看两个pod的mac地址是不是和我们上面说的那样。不同节点的pod网络通讯ip不变,而mac地址一直在发生变化我们在master节点抓nfhtt的包,nfhtt是10.11.0.10的ip,mac地址是ee:a2:33:a2:b6:69[root@master1 ~]# kubectl exec -it marksugar-deployment-578cdd567b-nfhtt -- tcpdump -n -e -i eth0我们并且上面开始Ping,ping的是968gg的pod,ip地址是10.11.1.45,mac地址是9e:66:19:aa:f6:c7[root@master1 ~]# kubectl exec -it marksugar-deployment-578cdd567b-nfhtt -- ping 10.11.1.45 PING 10.11.1.45 (10.11.1.45): 56 data bytes 64 bytes from 10.11.1.45: seq=0 ttl=60 time=0.613 ms 64 bytes from 10.11.1.45: seq=1 ttl=60 time=0.257 ms 64 bytes from 10.11.1.45: seq=2 ttl=60 time=0.206 ms 64 bytes from 10.11.1.45: seq=3 ttl=60 time=0.235 ms ^C --- 10.11.1.45 ping statistics --- 13 packets transmitted, 13 packets received, 0% packet loss round-trip min/avg/max = 0.191/0.254/0.613 ms查看抓包的结果[root@master1 ~]# kubectl exec -it marksugar-deployment-578cdd567b-nfhtt -- tcpdump -n -e -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 06:56:41.779184 ee:a2:33:a2:b6:69 > a2:a2:7f:a0:0d:91, ethertype IPv4 (0x0800), length 98: 10.11.0.10 > 64 06:56:41.779377 a2:a2:7f:a0:0d:91 > ee:a2:33:a2:b6:69, ethertype IPv4 (0x0800), length 98: 10.11.1.45 > 4 06:56:42.779249 ee:a2:33:a2:b6:69 > a2:a2:7f:a0:0d:91, ethertype IPv4 (0x0800), length 98: 10.11.0.10 > 64 06:56:42.779448 a2:a2:7f:a0:0d:91 > ee:a2:33:a2:b6:69, ethertype IPv4 (0x0800), length 98: 10.11.1.45 > 4 06:56:43.779308 ee:a2:33:a2:b6:69 > a2:a2:7f:a0:0d:91, ethertype IPv4 (0x0800), length 98: 10.11.0.10 > 64 06:56:43.779500 a2:a2:7f:a0:0d:91 > ee:a2:33:a2:b6:69, ethertype IPv4 (0x0800), length 98: 10.11.1.45 > 4 06:56:44.042429 ee:a2:33:a2:b6:69 > a2:a2:7f:a0:0d:91, ethertype ARP (0x0806), length 42: Request who-ha 06:56:44.042437 a2:a2:7f:a0:0d:91 > ee:a2:33:a2:b6:69, ethertype ARP (0x0806), length 42: Request who-ha 06:56:44.042440 ee:a2:33:a2:b6:69 > a2:a2:7f:a0:0d:91, ethertype ARP (0x0806), length 42: Reply 10.11.0. 06:56:44.042463 a2:a2:7f:a0:0d:91 > ee:a2:33:a2:b6:69, ethertype ARP (0x0806), length 42: Reply 10.11.0. ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel查看抓包的结果我们现在在看下cni0的网关的ip和mac地址如下cni0在这里表示的是pod网络的网关10.11.1.1网段7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default qlen 1000 link/ether ee:e9:19:55:93:d1 brd ff:ff:ff:ff:ff:ff inet 10.11.1.1/24 brd 10.11.1.255 scope global cni0 valid_lft forever preferred_lft forever inet6 fe80::ece9:19ff:fe55:93d1/64 scope link valid_lft forever preferred_lft forever和10.11.0.1网段7: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default qlen 1000 link/ether a2:a2:7f:a0:0d:91 brd ff:ff:ff:ff:ff:ff inet 10.11.0.1/24 brd 10.11.0.255 scope global cni0 valid_lft forever preferred_lft forever inet6 fe80::a0a2:7fff:fea0:d91/64 scope link valid_lft forever preferred_lft forever如上,我们看到抓包结果中两个mac地址是ee:a2:33:a2:b6:69 > a2:a2:7f:a0:0d:91pod尾968gg开头的mac地址是9e:66:19:aa:f6:c7,ip是10.11.1.45pod尾nfhtt开头的mac地址是ee:a2:33:a2:b6:69,ip是10.11.0.10我们从 10.11.0.10 ping 10.11.1.45, 10.11.0.10 的mac地址是ee:a2:33:a2:b6:69 ,10.11.1.45的pod的mac地址是9e:66:19:aa:f6:c7,而抓包走的则是10.11.0.10 的mac地址是ee:a2:33:a2:b6:69和10.11.0.1的cni0网卡的mac地址a2:a2:7f:a0:0d:91,返回的也是a2:a2:7f:a0:0d:91和ee:a2:33:a2:b6:69我们通过pod nfhtt(ee:a2:33:a2:b6:69 10.11.0.10)ping pod为9688GG的(9e:66:19:aa:f6:c7 10.11.1.45)ip而抓包显示,返回的信息的mac地址是10.11.0.1的mac地址。而10.11.0.1是cni0网关这篇延续上面几篇基础
2022年06月12日
1,240 阅读
0 评论
1 点赞
2022-04-06
linuxea:网卡与tap/tun网络接口简述(基础四)
网卡网卡分为很多类型,虚拟网卡,物理网卡等。物理网卡物理网卡需要通过网卡驱动在内核中注册后才能工作,它在内核网络协议栈和外界网络之间传递数据,用户可以为物理网卡配置网卡接口属性,比如IP地址,这些属性都配置在内核的网络协议栈中。内核也可以直接创建虚拟的网卡,只要为虚拟网卡提供网卡驱动程序,使其在内核中可以注册成为网卡设备,它就可以工作。从Linux内核3.x版本开始,物理网卡和虚拟网卡是平等的设备,它们都会在注册时创建net_device数据结构来保存(物理或虚拟)设备信息。相比于物理网卡负责内核网络协议栈和外界网络之间的数据传输,虚拟网卡的两端则是内核网络协议栈和用户空间,它负责在内核网络协议栈和用户空间的程序之间传递数据:发送到虚拟网卡的数据来自于用户空间,然后被内核读取到网络协议栈中。内核写入虚拟网卡准备通过该网卡发送的数据,目的地是用户空间。虚拟网卡物理网卡是硬件网卡,它位于硬件层,虚拟网卡则可以看作是用户空间的网卡,就像用户空间的文件系统(fuse)一样。物理网卡和虚拟网卡唯一的不同点在于物理网卡本身的硬件功能:物理网卡以比特流的方式传输数据。也就是说,内核会公平对待物理网卡和虚拟网卡,物理网卡能做的配置,虚拟网卡也能做。比如可以为虚拟网卡接口配置IP地址、设置子网掩码,可以将虚拟网卡接入网桥等等。只有在数据流经物理网卡和虚拟网卡的那一刻,才会体现出它们的不同,即传输数据的方式不同:物理网卡以比特流的方式传输数据,虚拟网卡则直接在内存中拷贝数据(即,在内核之间和读写虚拟网卡的程序之间传输)。正因为虚拟网卡不具备物理网卡以比特流方式传输数据的硬件功能,所以,绝不可能通过虚拟网卡向外界发送数据,外界数据也不可能直接发送到虚拟网卡上。能够直接收发外界数据的,只能是物理设备。虽然虚拟网卡无法将数据传输到外界网络,但却可以将数据传输到本机的另一个网卡(虚拟网卡或物理网卡)或其它虚拟设备(如虚拟交换机)上。可以在用户空间运行一个可读写虚拟网卡的程序,该程序可将流经虚拟网卡的数据包进行处理,这个用户程序就像是物理网卡的硬件功能一样,可以收发数据(可将物理网卡的硬件功能看作是嵌入在网卡上的程序),比如OpenVPN和VTun就是这样的工具。Note:很多人会误解这样的用户空间程序,认为它们可以对数据进行封装。比如认为OpenVPN可以在数据包的基础上再封装一层隧道IP首部,但这种理解是错的。用户空间的程序是无法对数据包做任何封装和解封操作的,所有的封装和解封都只能由内核的网络协议栈来完成。使用OpenVPN之所以可对数据再封装一层隧道IP层,是因为OpenVPN可以读取已经封装过一次IP首部的数据,并将包含ip首部的数据作为普通数据通过虚拟网卡再次传输给内核。因为内核接收到的是来自虚拟网卡的数据,所以内核会将其当作普通数据从头开始封装(从四层封装到二层封装)。当数据从网络协议栈流出时,就有了两层IP首部的封装。物理网卡一般来说,数据的起点和终点是用户程序,所以多数时候的数据需要在用户空间和内核空间(TCP/IP网络协议栈)再传输一次。当用户进程的数据要发送出去时,数据从用户空间写入内核的网络协议栈,再从网络协议栈传输到网卡,最后发送出去。当用户进程等待外界响应数据时,数据从网卡流入,传输至内核的网络协议栈,最后数据写入用户空间被用户进程读取。在次过程中内核和用户空间的数据传输由内核占用CPU来完成,内核和网卡之间的数据传输由网卡的DMA来完成。用户空间和内核空间与标准TCP/IP协议栈对应关系:用户空间的程序是无法对数据包做任何封装和解封操作的,所有的封装和解封都只能由内核的网络协议栈来完成。表示(7)层,应用(6)层,会话(5)层只是i编码,并没有内核参数进行封装,大致的封装如下TCP/TUNtap/tun 提供了一台主机内用户空间的数据传输机制。它虚拟了一套网络接口,这套接口和物理的接口无任何区别,可以配置 IP,可以路由流量,不同的是,它的流量只在主机内流通。作为网络设备,tap/tun 也需要配套相应的驱动程序才能工作。tap/tun 驱动程序包括两个部分,一个是字符设备驱动,一个是网卡驱动。这两部分驱动程序分工不太一样,字符驱动负责数据包在内核空间和用户空间的传送,网卡驱动负责数据包在 TCP/IP 网络协议栈上的传输和处理。tap/tun 有些许的不同,tun 只操作三层的 IP 包,而 tap 操作二层的以太网帧。在 Linux 中,用户空间和内核空间的数据传输有多种方式,字符设备就是其中的一种。tap/tun 通过驱动程序和一个与之关联的字符设备,来实现用户空间和内核空间的通信接口。在 Linux 内核 2.6.x 之后的版本中,tap/tun 对应的字符设备文件分别为:tap:/dev/tap0tun:/dev/net/tun设备文件即充当了用户空间和内核空间通信的接口。当应用程序打开设备文件时,驱动程序就会创建并注册相应的虚拟设备接口,一般以 tunX 或 tapX 命名。当应用程序关闭文件时,驱动也会自动删除 tunX 和 tapX 设备,还会删除已经建立起来的路由等信息。tap/tun 设备文件就像一个管道,一端连接着用户空间,一端连接着内核空间。当用户程序向文件 /dev/net/tun 或/dev/tap0 写数据时,内核就可以从对应的 tunX 或 tapX 接口读到数据,反之,内核可以通过相反的方式向用户程序发送数据。tap/tun 是 Linux 内核 2.4.x 版本之后实现的虚拟网络设备,不同于物理网卡靠硬件板卡实现,tap/tun 虚拟网卡完全由软件实现,功能和硬件实现完全没差别,它们都属于网络设备,都可配置 IP,都归 Linux 网络设备管理模块统一管理。tun和tap都是虚拟网卡设备:tun是三层设备,其封装的外层是IP头。tap是二层设备,其封装的外层是以太网帧(frame)头。tun是PPP点对点设备,没有MAC地址。tap是以太网设备,有MAC地址tap比tun更接近于物理网卡,可以认为,tap设备等价于去掉了硬件功能的物理网卡这意味着,如果提供了用户空间的程序去收发tun/tap虚拟网卡的数据,所收发的内容是不同的。收发tun设备的用户程序,只能间接提供封装和解封数据包的IP头的功能收发tap设备的用户程序,只能间接提供封装和解封数据包的帧头的功能注意,此处用词是【收发数据】而非【处理数据】,是【间接提供】而非【直接提供】,因为在不绕过内核网络协议栈的情况下,读写虚拟网卡的用户程序是不能封装和解封数据的,只有内核的网络协议栈才能封装和解封数据。虚拟网卡的两个主要功能是:连接其它设备(虚拟网卡或物理网卡)和虚拟交换机(bridge)。提供用户空间程序去收发虚拟网卡上的数据基于这两个功能,tap设备通常用来连接其它网络设备(它更像网卡),tun设备通常用来结合用户空间程序实现再次封装。换句话说,tap设备通常接入到虚拟交换机(bridge)上作为局域网的一个节点,tun设备通常用来实现三层的ip隧道。但tun/tap的用法是灵活的,只不过上面两种使用场景更为广泛。例如,除了可以使用tun设备来实现ip层隧道,使用tap设备实现二层隧道的场景也颇为常见。tun、tap作为虚拟网卡,除了不具备物理网卡的硬件功能外,它们和物理网卡的功能是一样的,此外tun、tap负责在内核网络协议栈和用户空间之间传输数据。tun程序 A 希望构造数据包发往 192.168.1.0/24 网段的主机 192.168.1.1。数据包要转发,是比要从用户空间转发到内核空间,到了内核空间后,如果是普通报文就直接送往网络设备上了(1,6,7)。但是有了tun设备的介入,数据在传递的时候查看了路由表,数据不应该被送往到物理网卡,而是要传送到tun进程打开的设备上。tun设备本身就可以把内核的报文送回给用户空间,用户空间收到后仍然想正常的报文一样处理,但是不同的是,会将报文做一些修改,因为用户空间本身不能做封装,这些修改的内容最终发送到内核空间,内核空间就照单全收,根据数据包信息进行发送。(1-3-4-5-6-7)应用程序 X 构造数据包,目的 IP 是 192.168.1.1,通过 socket X 将这个数据包发给协议栈。协议栈根据数据包的目的 IP 地址,匹配路由规则,发现要从 tun0 出去。tun0 发现自己的另一端被应用程序 Y 打开了,于是将数据发给程序 Y.程序 Y 收到数据后,做一些跟业务相关的操作,然后构造一个新的数据包,源 IP 是 eth0 的 IP,目的 IP 是 10.1.1.0/24 的网关 10.1.1.1,封装原来的数据的数据包,重新发给协议栈。协议栈再根据本地路由,将这个数据包从 eth0 发出。这个方式和openvpn是一样的。
2022年04月06日
1,378 阅读
0 评论
0 点赞
1
2
3