Kubernetes没有给本地环境(Bare-metal, On-Premise)提供负载均衡实现，LoadBalancer类型的服务主要在各大公有云厂商上能够得到原生支持。在本地环境创建LoadBalancer类型的服务后，服务的EXTERNAL-IP会一直处于<pending>状态。这是因为在本地环境没有相应的controller来处理这些LoadBalancer服务。比如:

1
2
3
4

[root@master1 vagrant]# kubectl get svc
NAME         TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP      10.32.0.1     <none>        443/TCP        31d
whoami       LoadBalancer   10.32.0.132   <pending>     80:31620/TCP   103s

之前的文章<<基于LVS DR模式的Kubernetes Service External-IP实现>>介绍了手动设置EXTERNAL-IP的方式实现外部负载均衡。本文通过在本地环境实现一个简单的controller来处理LoadBalancer类型服务自动实现负载均衡器。架构示意如图:

LoadBalancer是位于Kubernetes集群外的独立集群。可以通过ECMP将请求分散到不同的LoaderBalancer节点上，LoadBalancer再将请求分发到Kubernetes的node上。

之前的文章<<Kubernetes Service网络通信路径>>介绍了kubernetes的几种Service。如果要暴露服务给kubernetes集群外使用，可以选择NodePort和LoadBalancer。但LoadBalancer现在主要在各大公有云厂商上能够原生支持。而使用NodePort暴露服务，将使用一个非常大的端口，无法使用原始的端口号来暴露服务，比如mysql的3306端口。

Service的官方文档中介绍了一种辅助方式, 叫External-IP, 可以在worker节点上会通过该IP来暴露服务，而且可以使用在任意类型的service上。集群外的用户就可以通过该IP来访问服务。但如果这个IP只存在于一个worker节点上，那么就不具备高可用的能力了，我们需要在多个worker节点上配置这个VIP:Virtual IP。我们可以使用LVS(也叫做IPVS)的DR(Director Routing)模式作为外部负载均衡器将流量分发到多个worker节点上，同时保持数据包的目的地址为该VIP。

DR模式只会修改数据包的目的MAC地址为后端RealServer的MAC地址，因而要求负载均衡器Director和RealServer在同一个二层网络，而且响应包不会经过Director。

之前的文章<<Kubernetes网络和CNI>>和<<Kubernetes flannel网络分析>>介绍了Kubernetes集群的pod网络的通信过程。

pod本质上非固定的，经常发生变化，而pod IP在pod销毁和创建的时候会发生变更，因而不能直接对外提供服务。Kubernetes通过service资源来对外提供服务，service的IP是固定的，它自动绑定一组pod并根据不同实现将流量转发到这些pod中, 并在流量转发的过程中实现负载均衡(load balance)。

在Kubernetes的node节点上的主要组件有kube-proxy和kubelet, kubelet会调用相关的CNI实现完成POD网络的通信。而kube-proxy则负责上述的service与POD之间的流量转发。实际上，在之前文章的实验环境里，即使把node节点上的kube-proxy组件都停止，也不会影响pod网络通信。

service本质就是将一组pod通过固定IP暴露给使用者，可以由ip:port:protocol来标识。

service主要以下几种类型:

• ClusterIP: 用Kubernetes集群内部IP暴露服务，也就是说只有在Kubernetes集群内才可以访问这个service。这是默认的service类型。ClusterIP的范围是在kube-apiserver启动时通过-service-cluster-ip-range参数指定的。这些IP只能在kubernetes集群内进行访问。service的相关信息是在yaml文件中定义的，最终暴露的信息可表示为:

  1	spec.clusterIp:spec.ports[*].port:spec.ports[*].protocol

• NodePort: 在Kubernetes集群的所有node节点上使用相同的固定port来暴露服务。这种类型会自动创建ClusterIP类型的服务，NodePort的service会将流量转发到ClusterIP类型的服务。服务的使用者可以使用NodeIP:NodePort来访问该服务。这种类型服务暴露的信息可以表示为:

  1 2	<NodeIP>:spec.ports[*].nodePort:spec.ports[*].protocol spec.clusterIp:spec.ports[*].port:spec.ports[*].protocol

• LoadBalancer: 是通过kubernetes集群外部设施所提供的IP来暴露服务。NodePort和ClusterIP类型的服务会被自动创建。不同的LoadBalancer负责实现外部IP:port与NodePort服务的映射。这种类型暴露的信息可以表示为:

  1 2 3

  spec.loadBalancerIp:spec.ports[*].port:spec.ports[*].protocol <NodeIP>:spec.ports[*].nodePort:spec.ports[*].protocol spec.clusterIp:spec.ports[*].port:spec.ports[*].protocol

flannel是coreos开源的Kubernetes CNI实现。它使用etcd或者Kubernetes API存储整个集群的网络配置。每个kubernetes节点上运行flanneld组件，它从etcd或者Kubernetes API获取集群的网络地址空间，并在空间内获取一个subnet,该节点上的容器IP都从这个subnet中分配，从而保证不同节点上的IP不会冲突。flannel通过不同的backend来实现跨主机的容器网络通信，目前支持udp,vxlan,host-gw等一系列backend实现。本文介绍vxlan backend下的容器通信过程。

flannel在v0.9.0版本上对vxlan的实现作了改动。源码中有一段非常详细的注释介绍了不同版本的设计与实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// Some design notes and history:
// VXLAN encapsulates L2 packets (though flannel is L3 only so don't expect to be able to send L2 packets across hosts)
// The first versions of vxlan for flannel registered the flannel daemon as a handler for both "L2" and "L3" misses
// - When a container sends a packet to a new IP address on the flannel network (but on a different host) this generates
//   an L2 miss (i.e. an ARP lookup)
// - The flannel daemon knows which flannel host the packet is destined for so it can supply the VTEP MAC to use.
//   This is stored in the ARP table (with a timeout) to avoid constantly looking it up.
// - The packet can then be encapsulated but the host needs to know where to send it. This creates another callout from
//   the kernal vxlan code to the flannel daemon to get the public IP that should be used for that VTEP (this gets called
//   an L3 miss). The L2/L3 miss hooks are registered when the vxlan device is created. At the same time a device route
//   is created to the whole flannel network so that non-local traffic is sent over the vxlan device.
//
// In this scheme the scaling of table entries (per host) is:
//  - 1 route (for the configured network out the vxlan device)
//  - One arp entry for each remote container that this host has recently contacted
//  - One FDB entry for each remote host
//
// The second version of flannel vxlan removed the need for the L3MISS callout. When a new remote host is found (either
// during startup or when it's created), flannel simply adds the required entries so that no further lookup/callout is required.
//
//
// The latest version of the vxlan backend  removes the need for the L2MISS too, which means that the flannel deamon is not
// listening for any netlink messages anymore. This improves reliability (no problems with timeouts if
// flannel crashes or restarts) and simplifies upgrades.
//
// How it works:
// Create the vxlan device but don't register for any L2MISS or L3MISS messages
// Then, as each remote host is discovered (either on startup or when they are added), do the following
// 1) create routing table entry for the remote subnet. It goes via the vxlan device but also specifies a next hop (of the remote flannel host).
// 2) Create a static ARP entry for the remote flannel host IP address (and the VTEP MAC)
// 3) Create an FDB entry with the VTEP MAC and the public IP of the remote flannel daemon.
//
// In this scheme the scaling of table entries is linear to the number of remote hosts - 1 route, 1 arp entry and 1 FDB entry per host
//
// In this newest scheme, there is also the option of skipping the use of vxlan for hosts that are on the same subnet,
// this is called "directRouting"

v0.9.0之前版本的实现主要依赖vxlan内核模块的L2MISS和L3MISS消息机制。L2MISS是指vxlan设备在ARP表中找不到内层IP对应的MAC地址时会给用户态程序发送netlink消息。L3MISS是指vxlan设备在FDB表中找不到VXLAN协议内层MAC地址所属的VTEP的IP地址时会给用户态程序发送netlink消息。之前的文章<<动态维护FDB表项实现VXLAN通信>>介绍过相关概念和操作。本文主要分析v0.9.0版本上的实现方式。

Linux进程在运行中异常中止或者崩溃，Linux会将进程当时的内存信息、寄存器信息、函数调用堆栈等信息存储到文件系统的一个文件中，这个过程叫做core dump, 生成的core文件可以使用gdb来分析诊断程序存在的问题。最近对core dump的生成过程及相应进程退出的过程有些疑惑。究竟是崩溃进程的内核task退出前生成core文件还是崩溃的task先退出之后kernel检测到进程崩溃后额外来生成的呢？带着这个疑问去做些了实验和代码分析。

默认情况下，core dump文件被命名为core.pid, 如core.12345。内核参数/proc/sys/kernel/core_pattern可以定义core dump文件名模板。具体模板参数可以参考文档。但内核有个小巧特性，如果core_pattern的第一个字符为管道符:|, 内核会执行|之后的配置的可执行程序，并通过pipe将core dump内容传给这个用户态程序。

ABRT:Automated Bug Reporting Tool服务收集应用崩溃的core文件就是使用这个机制，abrt-ccpp服务会将core_pattern设置为:

1

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h

Security Boot机制是UEFI的一个特性，用于确保固件所加载的代码是可信的。它通过将可信根存放在固件中，在加载阶段校验所加载的二进制可信。当前实现主要是基于X.509证书的公私钥体系。固件使用可信的公钥来校验所加载的bootloader, bootloader再来校验内核或者第二阶段的bootloader, 内核校验所加载的内核模块，这样一级级完成校验。

在开启了Security Boot机制的CentOS8上，加载我们未签名的内核模块会失败:

1
2

[root@localhost virtualdev]# insmod ./virtualdev.ko
insmod: ERROR: could not insert module ./virtualdev.ko: Required key not available

接下来我们来通过签名我们的内核模块完成加载。要签名和校验我们的内核模块，我们需要一对公钥私钥。私钥用于签名，公钥需要加载到系统固件的MOK: Machine Owner Key列表中用于校验被签名的模块。

之前的文章<<Kubernetes环境中NFQUEUE与MARK机制冲突>>介绍了我们使用NFQUEUE机制将数据包送往用户态进行安全检测。之前程序逻辑是将来自虚拟网络设备的数据包直接放行。而当把逻辑修改为对POD虚拟网卡的流量也进行检测时，POD网络就无法连通了。排查发现数据包送上用户态之后，并没有收到用户态程序的裁决信息。

在对NFQUEUE的源码实现了进行草略分析后,发现NFQUEUE机制是支持network namespace的。POD虚拟网络设备的数据包送往用户态的队列是在POD独有的network namespace中创建的，和默认的network namespace:init_net中的队列是完全独立的。我们的用户态程序运行是在init_net中运行，而POD的network namespace中并没有用户态程序在读取队列获取数据包，因而数据包会被丢弃。

和之前文章同样，通过简化程序来进行实验。实验的Kubernetes环境有3个node, 容器组网使用flannel。

我们创建了两个busybox的pod：

1
2

kubectl run busybox1 --image=busybox --command -- sleep 3600
kubectl run busybox2 --image=busybox --command -- sleep 3600

他们分别位于node1和node2上:

1
2
3
4

[root@master1 scripts]# kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
busybox1-77bb94599d-x89z4   1/1     Running   12         22h   10.230.96.4    node1   <none>           <none>
busybox2-7d76b658b6-h5r2k   1/1     Running   10         22h   10.230.12.2    node2   <none>           <none>

我们从busybox2中访问busybox1，网络连通正常:

1
2
3
4
5
6
7
8

[root@master1 scripts]# kubectl exec -ti busybox2-7d76b658b6-h5r2k -- ping -c2 10.230.96.4
PING 10.230.96.4 (10.230.96.4): 56 data bytes
64 bytes from 10.230.96.4: seq=0 ttl=62 time=1.076 ms
64 bytes from 10.230.96.4: seq=1 ttl=62 time=0.770 ms

--- 10.230.96.4 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.770/0.923/1.076 ms

之前的文章<<QEMU虚拟机内识别ivshmem设备>>介绍了在虚拟机内通过用户态程序访问ivshmem设备的共享内存。在虚拟机之间或者宿主机与虚拟机之间通过共享内存进行通信的情形下，共享内存的两端必须依赖轮询方式来实现通知机制。这种方式是ivshmem提供的ivshmem-plain的使用方式。除此之外，ivshmem还提供了ivshmem-doorbell的使用方式，它提供了基于中断的通知机制。

ivshmem-doorbell提供了两种中断方式，一种是传统的基于INTx的中断, 它主要使用BAR0的Interrupt Mask和Interrupt Status两个寄存器；另一种是基于MSI-X的中断，它主要使用BAR0的IVPosition和Doorbell两个寄存器。参考共享的设备端叫做peer。IVPosition寄存器存储该peer的数字标识符(0-65535), 称做peer_id。该寄存器为只读寄存器。而Doorbell寄存器为只写寄存器。ivshmem-doorbell支持多个中断向量，写入Doorbell寄存器则触发共享该内存的某个peer的某个中断。Doorbell为32位，低16位为peer_id，而高16位为中断向量号(这里是从0开始的顺序号，而非PCI驱动在Guest虚拟机内部所申请的向量号)。

使用ivshmem-doorbell机制需要运行ivshmem-server。ivshmem-server根据参数创建共享内存，并通过监听本地UNIX DOMAIN SOCKET等待共享内存的peer来连接。添加了ivshmem-doorbell设备的QEMU进程会连接该socket, 从而获取ivshmem-server所分配的一个peer_id。ivshmem-doorbell支持多个中断向量，ivshmem-server会为ivshmem虚拟PCI设备支持的每个中断向量创建一个eventfd，并将共享内存以及为所有客户端中断向量所创建的eventfd都通过SCM_RIGHTS机制传递给所有客户端进程。这样所有的peer便都具备了独立的两两之间的通知通道。之后在虚拟机内通过触发ivshmem虚拟PCI设备的DOORBELL寄存器的写入，虚拟机的QEMU进程便会通过DOORBELL寄存器中的peer_id和中断向量号来找到相应的eventfd，从而通知到对端的QEMU进程来产生相应的PCI中断。

要使用中断机制，用户态程序是无能为力的，需要编写相应的PCI驱动来实现。本文通过一个简单的PCI驱动示例来说明ivshmem-doorbell的MSI-X中断机制的使用。

ivshmem:(Inter-VM shared memory device)是QEMU提供的一种宿主机与虚拟机之间或多个虚拟机之间共享内存的特殊设备。它有两种形式:

• ivshmem-plain: 简单的共享内存区域
• ivshmem-doorbell: 除了共享内存，还能提供基于中断的通信机制

这种设备在虚拟机内部表现为PCI设备，共享的内存区域则以PCI BAR的形式存在。ivshmemPCI设备提供3个BAR:

• BAR0: 设备寄存器
• BAR1: MSI-X表
• BAR2: 共享内存区域

简单共享内存的场景只使用BAR2就足够了。如果需要基于中断实现额外通信，需要用到BAR0和BAR1。这可能需要编写内核驱动在虚拟机内处理中断，宿主机上QEMU进程在启动前需要先启动ivshmem server, 然后让QEMU进程连接到server的unix socket。

具体可以参考官方文档。

本文只讨论ivshmem-plain模式。宿主机上添加ivshmem设备后，虚拟机应用如何找到相应的ivshmem设备呢？

Linux的/sys/bus/pci/devices/目录会列出所有的PCI设备，ivshmem设备也会包含在其中。PCI设备都存在vendor号和device两个标识，vendor表示厂商，device表示厂商内的设备类型。ivshmem设备的vendor号为0x1af4, device号为0x1110，PCI设备的vendor和device号可在这里进行查询。

虚拟机中应用可通过遍历该目录下的具体设备，通过读取vendor和device文件来识别ivshmem设备。

但如果有两种应用都需要使用一个独立的ivshmem设备，虚拟机应用如何识别出应该使用哪个ivshmem设备呢?

因为每个PCI设备都可以由BDF:(Bus, Device, Function)来唯一标识，简单做法可以为每个应用预留好固定BDF地址。BDF地址中，BUS占用8位，Device占用5位,Function占用3位。比如，预留总线pci0的最后两个设备地址0000:00:1e.0和0000:00:1f.0。

有时候无法预留，不同虚拟机上的ivshmem地址可能不同。这种情况可以通过与宿主机上的应用约定好相应的固定内容做为signature写入共享内存头部，虚拟机应用读取共享内存头部的signature信息来识别相应设备。

在Kubernetes节点上安装我们的流量检测模块之后所有的Pod会断网。经分析是由于流量检测模块的NFQUEUE机制与kube-proxy使用的iptables的mark机制冲突的原因。

在Linux内核中，网络数据包是由sk_buff结构来表示的，一般数据包简写作SKB。mark是sk_buff结构的一个字段, 如(include/linux/skbuff.h):

1
2
3
4
5
6
7
8

struct sk_buff {
    ...
	union {
		__u32		mark;
		__u32		reserved_tailroom;
	};
    ...
}

mark并不是网络协议结构的部分，不会存在于任一层协议头中，而是Linux网络子系统用于在主机内部传递状态信息的标记机制。各种网络应用可以根据自身需要使用该字段来实现自身的状态传递。

这个mark机制主要用在netfilter框架中，所以也叫nfmark。除了它之外，内核中还有conntrack模块也有自己的mark机制，一般叫做ctmark。

之前的文章<<基于IPTABLES MARK机制实现策略路由>>也介绍过iptables的MARK模块，可以用于修改和匹配数据包的mark值。

NFQUEUE机制可以在内核中将数据通过NFQUEUE通道将数据包送往用户态，在用户态进行安全检测，再将裁决(verdict)结果送回内核。之前的文章<<NFQUEUE和libnetfilter_queue实例分析>>介绍了libnetfilter_queue库的简单用法。我们的流量检测程序会使用libnetfilter_queue库中的nfq_set_verdict2在返回verdict的同时，设置数据包的mark值,以传递更多的信息给内核模块，函数原型如下:

1
2
3
4
5
6
7

int nfq_set_verdict2(struct nfq_q_handle *  qh,
                     uint32_t               id,
                     uint32_t               verdict,
                     uint32_t               mark,
                     uint32_t               data_len,
                     const unsigned char*   buf
)

这就会导致数据包sk_buff结构的mark值被设置。而kube-proxy实现也依赖iptables的mark机制, 会在主机上添加如下iptables规则:

1
2
3

-A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000
...
-A KUBE-FIREWALL -m comment --comment "kubernetes firewall for dropping marked packets" -m mark --mark 0x8000/0x8000 -j DROP

对于不合法的报文，kube-proxy会给相应报文标记0x8000/0x8000, 之后通过KUBE-FIREWALL规则链将数据包丢弃。

如果我们的流量检测程序所设置的mark值设置为kube-proxy所依赖的0x8000位，就会导致数据包被丢弃。