追踪 Kubernetes 中的数据包
网络和操作系统内核,对我来说是既陌生又满是吸引,希望能够拨开层层迷雾找到背后的真相。
在 上一篇文章 中我深入探讨了 Kubernetes 网络模型,这次我想更深入一点:了解数据包在 Kubernetes 中的传输,为学习 Kubernetes 的 eBPF 网络加速做准备,加深对网络和操作系统内核的理解。 文中可能有疏漏之处,还望大家赐教。
在开始之前,我可以用一句话来总结我的学习成果:数据包的流转其实就是一个网络套接字描述符(Socket File Descriptor,中文有点冗长,以下简称 socket fd)的寻址过程。 它不是简单的指 socket fd 的内存地址,还包括它的网络地址。
在 Unix 和类 Unix 系统中,一切皆文件,也可以通过文件描述符来操作 socket。
基础知识
数据包
既然要讨论数据包的流转,先看看什么是数据包。
网络数据包(network packet),也称为网络数据报(network datagram)或网络帧(Network frame),是通过计算机网络传输的数据单位。拿最常见的 TCP 数据包来看包含如下几个部分:
Ethernet header:链路层信息,主要包括目的 MAC 地址和源 MAC 地址,以及报文的格式,这里是 IP 包。
IP header:网络层信息,主要包括长度、源 IP 地址和目的 IP 地址以及报文的格式,当然这里必须是 TCP 包。
TCP header:传输层信息,包括源端口和目的端口。
数据:一般是第 7 层的数据,比如 HTTP 等。
这里没有介绍的 checksum 和 FCS 通常是用来检查数据包在传输过程中是否被篡改或者发生了错误。
应用程序使用 socket 向网络发送数据的过程可以简单理解为使用头信息封装数据的过程:TCP 数据包、IP 数据包、Ethernet 数据包;反过来,从网络接收以太网数据包到应用程序可以处理的数据,就是解包的过程。封包和解包的过程是由内核网络协议栈来完成的。
下面分别说一下 socket 和内核网络协议栈的处理。
socket 套接字
Socket 是一种在计算机网络中使用的编程接口,位于用户空间(用户应用程序运行的空间)和内核网络协议栈(内核中对数据进行封包和解包的组件)之间。
作为编程接口,socket 提供了如下操作(只列出部分):
socket
connect
bind
listen
accept
数据传输
send
sendto
sendmsg
recv
recvfrom
recvmsg
getsockname
getpeername
getsockopt
、setsockopt
获取或设置 socket 层或协议层选项close
通过下面的图,可以直观感受各个操作的作用:
开始讲解内核网络协议栈之前,先说下数据包在内存中的数据结构:sk_buff。
sk_buff
sk_buff 是 Linux 内核中用于管理网络数据包的数据结构,它包含了接收和发送的网络数据包的各种信息和属性,如数据包的协议、数据长度、源和目标地址等。sk_buff 是一种可以在网络层和数据链路层之间传递的数据结构,可以被用于所有类型的网络协议栈,例如 TCP/IP、UDP、ICMP 等。
sk_buff 在 Linux 内核中广泛应用于网络协议栈的各个层级,如数据链路层、网络层、传输层等。sk_buff 数据结构的字段很多,有 4 个重要的字段且都是指针类型。sk_buff 在不同层的使用,就是通过修改这些指针来完成的:加 header (封包)和移除 header(解包)。
这个过程操作做的是指针,数据是零拷贝的,可以极大地提升效率。
内核网络协议栈
封包
应用程序使用 socket 的 sendmsg 操作发送数据(这里不深入讲解 netfilter、traffic control、queue discipline):
先分配 sk_buff
接下来开始网络协议栈的处理
设置传输层信息(这里是 TCP 头中的源和目的端口)
根据目标 IP 查找路由
设置网络层信息(源和目的 IP 地址等)
调用 netfilter(
LOCAL_OUT
)设置接口(interface)和协议(protocol)
调用 netfilter(
POST_ROUTING
)如果包过长,分段传输
L2 寻址,即查找可以拥有目标 IP 地址的设备的 MAC 地址
设置链路层信息,
至此内核网络协议栈的操作完成
调用 tc(traffic control)egress(可以对包进行重定向)
进入队列 queue discipline(qdisc)
写入 NIC(network interface controler)
发送到网络
解包
NIC 收到网络发来的数据包(这里不深入讲解 direct memory access、netfilter、traffic control):
将数据包写如 DMA 中(Direct Memory Access 直接内存访问,不需要依赖 CPU,由 NIC 直接写入到内存中)
分配 sk_buff,并填充元数据,比如 protocol 为 Ethernet 类型,接收数据包的网络接口等
将链路层信息保存在 sk_buff 的
mac_header
字段中,并“移除”数据包中的链路层信息(移动指针)接下来开始网络协议栈的处理
将网络层信息保存在
network_header
字段中调用 tc ingress
“移除”网络层信息
将传输层信息保存在
transport_header
字段中调用 netfilter(
PRE_ROUTING
)查找路由
合并多个分包
调用 netfilter(
LOCAL_IN
)“移除”传输层信息
查找监听目标端口的 socket,或者发送 reset
将数据写入 socket 的接收队列中
发信号通知有数据写入队列
至此内核网络协议栈的操作完成
sk_buff 从 socket 接收队列中出队
将数据写入应用程序的缓冲区
释放 sk_buff
Kubernetes 的网络模型
另一部分的基础知识就是 Kubernetes 的网络模型了,可以参考之前的那篇 深入探索 Kubernetes 网络模型和网络通信。
Kubernetes 中的数据包流转
这里继续讨论之前文章中的三种通信场景,pod 间的通信使用 pod IP 地址。如果要讨论通过 Service 来访问,则要加入 netfilter 的讨论篇幅会增加不少。
同 pod 内的容器间通信
pod 内两个容器间的方式通常使用回环地址 127.0.0.1
,在封包的 #4 路由过程中确定了使用回环网卡 lo
进行传输。
同节点上的 pod 间通信
curl
发出的请求在封包 #4 过程中确定使用 eth0
接口。然后通过与 eth0
相连的隧道 veth1
到达节点的根网络空间。
veth1
通过网桥 cni0
与其他 pod 相连虚拟以太接口 vethX
相连。在封包 #10 L2 寻址中,ARP 请求通过网桥发送给所有相连的接口是否拥有原始请求中的目的 IP 地址(这里是 10.42.1.9
)
拿到了 veth0
的 MAC 地址后,在封包 #11 中设置数据包的链路层信息。数据包发出后,经过 veth0
隧道进入 pod httpbin
的 eth0
接口中,然后开始解包的过程。
解包的过程没啥特别,确定了 httpbin 使用的 socket。
不同节点的 pod 间通信
这里稍微不同,就是在通过 cni0
发送 ARP 请求没有收到应答,使用根命名空间也就是主机的路由表,确定了目标主机 IP 地址后,然后通过主机的 eth0
放 ARP 请求并收到目标主机的响应。将其 MAC 地址在封包 #11 中写入。
数据包发送到目标主机后,开始解包的过程,最终进入目标 pod。
在集群层面有一张路由表,里面存储着每个节点的 Pod IP 网段(节点加入到集群时会分配一个 Pod 网段(Pod CIDR),比如在 k3s 中默认的 Pod CIDR 是
10.42.0.0/16
,节点获取到的网段是10.42.0.0/24
、10.42.1.0/24
、10.42.2.0/24
,依次类推)。通过节点的 Pod IP 网段可以判断出请求 IP 的节点,然后请求被发送到该节点。
总结
统计一下在三个场景中,经过内核网络协议栈的处理次数都是两次(包括 netfilter 的处理。),即使是同 pod 或者同节点内。而这两种情况实际都发生在同一个内核空间中。
假如同一个内核空间中的两个 socket 可以直接传输数据,是不是就可以省掉内核网络协议栈处理带来的延迟?
下篇继续。
版权声明: 本文为 InfoQ 作者【张晓辉】的原创文章。
原文链接:【http://xie.infoq.cn/article/5aaeea2f543d6ccd11b3f8c69】。文章转载请联系作者。
评论