京东数科 | Kubernetes实践之contiv支持非docker容器运行时

在我们京东数科的kubernetes容器集群中，网络插件使用的是contiv，容器运行时使用的是默认的docker，一直以来它们配合的非常好。但是当我们把容器运行时更换为containerd或者cri-o时，pod却一直无法创建成功。查看日志发现，一直打印类似这样的错误： Err: invalid nw name space: /var/run/netns/cni-4128c748-11b7-58bf-9a98-6e740c4e7f13 ，于是定位到导致该错误的源码位于nsToPID函数中，如下：

 // mgmtfn/k8splugin/driver.go
 // nsToPID is a utility that extracts the PID from the netns
 func nsToPID(ns string) (int, error) {
     ok := strings.HasPrefix(ns, "/proc/")
     if !ok {
         return -1, fmt.Errorf("invalid nw name space: %v", ns)
     }
     elements := strings.Split(ns, "/")
     return strconv.Atoi(elements[2])
 }

该函数的实现比较简单，首先检查传入的ns字符串是否以/proc/开头，如果不是则直接返回错误。而出错的时候，ns的值类似/var/run/netns/cni-4128c748-11b7-58bf-9a98-6e740c4e7f13这种格式，显然不符合条件。我们也通过日志发现，当容器运行时是默认的docker时，ns的值是类似proc/12345/ns/net这种格式的，它可以通过格式检查，并返回正确的pid。那现在问题基本明确了，当容器运行时是docker时，ns的值是 proc/[pid]/ns/net 这种格式的；当容器运行时是containerd或者cri-o时，ns的值是 /var/run/netns/[xxx] 这种格式的，导致解析失败。所以我们就从最初的源头分析，到底是什么原因导致了两种格式的ns的存在，以及如何解决这个问题。

1. contiv的整体架构

contiv是kubernetes集群中提供容器跨主机通讯的开源网络插件，能够支持二层、三层、overlay、aci等多种模式。它的整体架构如下图：

其中，netctl是一个命令行管理工具。netmaster是整个contiv集群的管理控制结点。netplugin需要部署在集群的每个结点上，负责创建ovs流表、通告BGP路由等实际工作。contivk8s也需要部署在集群的每个结点上，它是kubelet与netplugin之间的适配器，负责将kubelet发送过来的cni（container network interface）请求转换为netplugin可以接受的数据格式。

2. kubernetes集群中使用非docker容器运行时

在kubernetes集群中，kubelet里面默认配置的容器运行时是docker，但是可以通过kubelet的参数container-runtime和container-runtime-endpoint来使用其他的容器运行时，例如containerd和cri-o。此时，container-runtime需要设置为remote，同时container-runtime-endpoint需要设置为具体的容器运行时监听的套接字地址，例如 unix:///run/containerd/containerd.sock 。在kubernetes集群中，之所以能够使用各种不同的容器运行时，是因为kubernetes中规定了容器运行时（container runtime interface）的标准，只要按照cri标准开发的容器运行时，都可以集成到kubernete集群中。

我们知道，kubelet在创建pod时，首先创建一个sandbox容器，然后才会创建用户定义的容器。sandbox容器的一个作用是初始化网络资源，例如设置IP地址、路由信息等，也就是说cni网络插件是在此步骤中参与进来的。前面说到，kubernetes中规定了容器运行时cri的标准，其中与sandbox容器相关的api有RunPodSandbox，StopPodSandbox等等，各个具体的容器运行时也都实现了这些api。当kubelet想要创建一个sandbox容器时，它会调用容器运行时提供的RunPodSandbox这个api。所以，去看看各个容器运行时的 RunPodSandbox 这个api是如何实现的，就能知道为什么会出现两种格式的ns。

3. 容器运行时docker

其实，docker的后台服务进程dockerd并没有直接实现cri标准中规定的那些api。因为docker出现的时间比较早，它自己本身就有一套完整的创建、启动、停止、删除容器的api。而cri标准是后来才出现的，并且这两套接口无法实现无缝结合，所以必须有一个中间的适配器adapter存在，这个适配器就是 dockershim ，它的作用就是将cri标准的接口转换为dockerd中可以识别的接口。最后值得注意的是dockershim是集成在kubelet里面的。

 // pkg/kubelet/dockershim/docker_service.go
 func (ds *dockerService) GetNetNS(podSandboxID string) (string, error) {
     r, err := ds.client.InspectContainer(podSandboxID)
     if err != nil {
         return "", err
     }
     return fmt.Sprintf("/proc/%v/ns/net", r.State.Pid), nil
 }

在dockershim中调用GetNetNS函数时，需要传入第2步中返回的sandbox容器的容器ID。GetNetNS的实现也比较简单，就是给dockerd发送inspect请求，获得sandbox容器的详细信息，然后从详细信息中取出sandbox容器的pid，最终返回/proc/[pid]/ns/net。至此，dockershim的逻辑已经分析完了，也已经知道了/proc/[pid]/ns/net格式的ns是如何得来的。下面在分析容器运行时containerd之前，需要先了解下两个事情，一是创建sandbox容器时contiv做了些什么事情，二是 linux 内核中namespace的基础知识。

4. 创建sandbox容器时contiv做的具体工作

5. linux内核中namespace的基础知识

namespace是linux内核提供的一种资源隔离方案，包括network、mount、user、pid、ipc、uts等多种资源类型的隔离。对于系统中的每个进程，都有/proc/[pid]/ns/这样的一个目录存在，里面包含了这个进程所属的各个namespace的信息，例如：

 ls -l /proc/12345/ns/

 lrwxrwxrwx 1 root root 0 Mar 12 16:53 ipc -> ipc:[4026533048]
 lrwxrwxrwx 1 root root 0 Mar 12 16:53 mnt -> mnt:[4026533279]
 lrwxrwxrwx 1 root root 0 Mar 12 16:53 net -> net:[4026533051]
 lrwxrwxrwx 1 root root 0 Mar 12 16:53 pid -> pid:[4026533283]
 lrwxrwxrwx 1 root root 0 Mar 12 16:53 user -> user:[4026531837]
 lrwxrwxrwx 1 root root 0 Mar 12 16:53 uts -> uts:[4026533282]

与namespace相关的api有三个，它们分别是clone、setns、unshare。在linux系统中，我们可以通过fork或者clone来创建新的进程，以fork方式创建出来的新的进程与其父进程在相同的命名空间内，而以clone方式创建新的进程时，可以通过flags参数来指定创建新的命名空间。例如，当flags中包含CLONE_NEWNET时，新的进程则会位于一个新的网络命名空间内，与父进程的网络命名空间是不同的。setns则可以将当前进程加入到一个已经存在的命名空间，它的函数原型是 int setns(int fd, int nstype) 。假设已经存在一个pid为12345的进程，我们想要把当前进程加入到pid为12345的进程所在的网络命名空间，则可以在当前进程中打开/proc/12345/ns/net这个文件，获得它的文件描述符fd，然后调用 setns(fd, CLONE_NEWNET) 来实现。unshare则会使当前进程退出当前的命名空间，然后加入到新创建的命名空间内，它的函数原型是 int unshare(int flags)。 例如我们想要把当前进程加入到一个新的网络命名空间内，则可以在当前进程内调用 unshare(CLONE_NEWNET) 来实现。最后命名空间还有一个特性，就是当一个命名空间中的所有进程都退出时，该命名空间将会被销毁。那么，当所有进程都退出某个命名空间时，我们依然想保留它怎么办？可以通过bind mount的方式。例如 mount --bind /proc/12345/ns/net /file/tmp ，这样就算属于这个网络命名空间的所有进程都退出了，只要/file/tmp这个文件还在，那么/proc/12345/ns/net这个网络命名空间就会一直存在。在其他的进程中，可以打开文件/file/tmp，获得文件描述符fd，最后调用 setns(fd, CLONE_NEWNET) 加入到这个网络命名空间。

6. 容器运行时containerd

 // vendor/github.com/containernetworking/plugins/pkg/ns/ns_linux.go
 func NewNS() string {
     // b是长度为16的随机字节数组
     nsName := fmt.Sprintf("cni-%x-%x-%x-%x-%x", b[0:4], b[4:6], b[6:8], b[8:10], b[10:])
     nsPath := path.Join("/var/run/netns", nsName)
     // 此时，nsPath类似这样/var/run/netns/cni-4128c748-11b7-58bf-9a98-6e740c4e7f13

     // 保留当前的网络命名空间
     origNS, _ = GetNS(getCurrentThreadNetNSPath())

     // 创建一个新的网络命名空间，并把当前进程加入进去
     unix.Unshare(unix.CLONE_NEWNET)

     // 将新的网络命名空间挂载到/var/run/netns/目录下的某个文件
     unix.Mount(getCurrentThreadNetNSPath(), nsPath, "none", unix.MS_BIND, "")

     // 将当前进程恢复到之前保留的网络命名空间
     origNS.Set()
     
     return nsPath
 }

7. 问题修复

原因已经找到了，netplugin期望从传入的ns参数中获得代表新的网络命名空间的pid，但是在容器运行时containerd中构造出的ns是/var/run/netns/[xxx]这样的格式，无法获得pid。那我们的解决方式就是在这两种格式的ns之间做一个转换，将格式为 /var/run/netns/[xxx] 的ns转换为 /proc/[pid]/ns/net 这样的格式。要想转换，就需要一个pid的存在，那这个pid是哪个进程的pid呢？而且还要确保这个pid指向那个刚刚创建的网络命名空间。我们先把创建sandbox容器时涉及到的组件整理一下，如下图：

（1）kubelet调用cri标准的RunPodSandbox接口

（2）容器运行时containerd创建新的网络命名空间，将环境变量CNI_NETNS设置为这样的格式/var/run/netns/[xxx]，然后调用cni网络插件接口创建新的进程并执行contivk8s

（3）contivk8s将cni请求转换为netplugin可以接受的api，其中一步是读取这样格式/var/run/netns/[xxx]的环境变量CNI_NETNS，然后将其赋值给ns参数

（4）netplugin设置ip地址、ovs流表等等

经过这些分析之后，我们可以在contivk8s这里搞点小事情。contivk8s进程启动后，读取环境变量CNI_NETNS的值，如果是类似/var/run/netns/[xxx]这种格式的，则打开该文件并获得文件描述符fd，然后调用 setns(fd, CLONE_NEWNET) 将自己加入到/var/run/netns/[xxx]指定的网络命名空间。接着获得自己进程的进程号pid，并格式化为/proc/[pid]/ns/net这样的格式，最后将其发送到netplugin。具体的代码片段如下：

 if !strings.HasPrefix(ppInfo.NwNameSpace, "/proc/") {
     nsHandle, err := netns.GetFromPath(ppInfo.NwNameSpace)
     if err != nil {
         return fmt.Errorf("error getting ns %s: %s", ppInfo.NwNameSpace, err)
     }
     err = netns.Set(nsHandle)
     if err != nil {
         return fmt.Errorf("error switching to ns %s: %s", ppInfo.NwNameSpace, err)
     }
     ppInfo.NwNameSpace = fmt.Sprintf("/proc/%d/ns/net", os.Getpid())
 }

8. 总结

contivk8s经过修改之后，不管容器运行时是dockerd还是containerd，最终netplugin里面接收到的ns参数始终是/proc/[pid]/ns/net这样的格式，从而可以进行正确的处理。我们已经将该功能合并到github的contiv项目中了，欢迎大家使用，如果有任何问题，可以通过邮件zhouzijiang@jd.com进行交流。

最后，我们京东数科一直致力于构建基于kubernetes的大规模容器集群，经受618和双11的流量考验，欢迎有意向的同学加入我们一起努力，可以发送简历到邮箱hejun3@jd.com，谢谢！