虚拟网络之Kubernetes Cilium CNI 网络通信调测

虚拟网络之Kubernetes Cilium CNI 网络通信调测

前言

Cilium CNI 是基于Linux 新版本内核中的eBPF实现的，对应数据面转发逻辑和Flannel CNI 比较有了不小的变化，从实现机制上来说，性能上是有很大的提升的；本篇就是将我在环境上实操验证进行一个简单的记录；关于Cilium CNI 安装，可以参考官网，也可以查看我之前的博客；
https://docs.cilium.io/en/v1.9/gettingstarted/k8s-install-default/
https://blog.csdn.net/LL845876425/article/details/110410377

Cilium CNI 配置查看

查看Cilium CNI 相关网络配置；

cat /etc/cni/net.d/05-cilium.conf
kubectl get pods -n kube-system -o wide
kubectl get cm -n kube-system -o wide
kubectl get cm cilium-config -n kube-system -o yaml

[root@master ~]# cat /etc/cni/net.d/05-cilium.conf
{
  "cniVersion": "0.3.1",
  "name": "cilium",
  "type": "cilium-cni",
  "enable-debug": false
}
[root@master ~]#

同Node pod 通信：

同节点内部的容器之间的连通性依赖内核协议栈二层转发和BPF程序，不会经过像OVS或Linux bridge这样的二层设备。这部分功能由Cilium Agent负责，使用BPF规则进行流量的管控。简单示意图如下：

官方示意图如下：
可以看到，同节点的容器之间通信直接走BPF规则即可；不同节点的容器的通信需要通过各个节点上的cilium_host接口进行转发；

容器和所在节点的通信走节点内部的三层路由和BPF转发，BPF程序连接容器的veth pair和它的网关设备。

如下路由中，将cilium_host作为容器的默认网关。容器和容器所在的节点的通信需要经过cilium_host接口

client pod centos-test-764675d946-c2scc 10.0.1.174 master
server pod nginx-nets-c6744f88d-p8kr4 10.0.1.179 master

可以看到没有对应的2层bridge：

client pod 看到 if12，对应node 节点上序号12 的设备，查看node节点网卡配置，即是：

# 
12: lxc175346e62e21@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2a:b8:ff:5a:83:b5 brd ff:ff:ff:ff:ff:ff link-netnsid 2

指定该设备口抓包，即可抓到从 pod 出的包；

该设备对应设备类型为 veth

[root@centos-test-764675d946-c2scc /]# curl -I 10.0.1.179
HTTP/1.1 200 OK
Server: nginx/1.19.3
Date: Mon, 30 Nov 2020 08:30:11 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 29 Sep 2020 14:12:31 GMT
Connection: keep-alive
ETag: "5f7340cf-264"
Accept-Ranges: bytes

[root@centos-test-764675d946-c2scc /]# ip a s
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
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 4a:a1:12:a5:22:51 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.1.174/32 scope global eth0
       valid_lft forever preferred_lft forever
[root@centos-test-764675d946-c2scc /]# ip route show
default via 10.0.1.205 dev eth0 mtu 1450
10.0.1.205 dev eth0 scope link
[root@centos-test-764675d946-c2scc /]#

节点和pod上 ip route 记录：

# pod 
[root@centos-test-764675d946-c2scc /]# ip route show
default via 10.0.1.205 dev eth0 mtu 1450
10.0.1.205 dev eth0 scope link
[root@centos-test-764675d946-c2scc /]#

# node节点：
[root@master ~]# ip route show
default via 172.16.0.1 dev eth0
10.0.0.0/24 via 10.0.1.205 dev cilium_host src 10.0.1.205 mtu 1450
10.0.1.0/24 via 10.0.1.205 dev cilium_host src 10.0.1.205 mtu 1450
10.0.1.205 dev cilium_host scope link
169.254.0.0/16 dev eth0 scope link metric 1002
172.16.0.0/20 dev eth0 proto kernel scope link src 172.16.0.5
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
[root@master ~]#

另外还可以看到 Cilium 还是会有一些iptables 规则下发

跨node pod 访问：

下面是使用Host L3进行跨节点通信的流程图

下面是使用vxlan进行跨节点通信的流程图

Cilium cli

使用Cilium后，不会再使用kube-proxy，它会从Kubernetes API服务器获得Service信息，并存入BPF。可以使用cilium命令行查看相关的信息。
如使用# cilium node list查看当前的node节点信息，使用# cilium service list查看service信息等。对于策略的获取，可以通过命令行# cilium policy get，也可以通过Hubble UI查看，如下：

参考：

• Kubernetes Multi-Cluster Networking -Cilium Cluster Mesh
• Kubernetes_Cilium_Plugin
• https://www.cnblogs.com/charlieroro/p/12728984.html