童航君：腾讯云CIS服务和clear container

演讲嘉宾：童航君 | 腾讯云CIS容器服务技术负责人

今天我讲的主要是关于腾讯云最近新上的一款产品CIS。我自加入腾讯云以来就一直在负责CIS的开发工作。不多说，我们直接进入主题。

讲述主要从五方面开始。第一为什么会有CIS这个产品，CIS是Container Instance Service 的简称，它的由来是什么？第二是CIS产品简介，它到底能为我们带来一些什么样的便利？第三，CIS的技术方案。第四，CIS如何和现有的TKE集群进行对接，让我们更方便的使用K8s。第五，讲讲Clear Container。

为什么会有CIS？

Docker很好用，编排很复杂

CIS的产生要从Docker说起。Docker非常好用，我们可以通过Dockerfile或者Docker build 命令来打包一个镜像，同时可以通过Docker pull、Docker push命令把它和容器的仓库进行对接，最终docker可以跨平台的运行。

但是大量Docker镜像管理起来非常复杂。K8s的产生可以简化Docker的编排。当然，Docker公司本来出的Swarm也是可以进行编排的，经过近几年的角逐，K8s成为了各大云厂商选择的主流编排软件。

K8s比较复杂，主要有两点。第一是安装起来比较复杂，你需要有若干台机器，并在这些机器上安装满足k8s网络需求的组件，。第二使用起来比较复杂，K8s有一些特别复杂的概念和一系列的资源。入门起来还需要一定的时间。这是CIS产生的第一个原因，Docker很好用，但是编排很复杂。

TKE简化编排，节点扩展不灵活

我们有个TKE（原来的CCS）集群，能够帮助用户一键创建K8s集群。只要在腾讯云控制台上点一下创建集群，满足网络需求的K8s集群就创建出来了，同时依托于腾讯云的TKE还可以和腾讯云的cbs，cfs，监控等对接，另外我们提供了hpa-metrics-server、cluster autoscater能够帮助用户进行pod和节点的扩缩容，也提供了log-collector组件方便用户使用日志服务。

这些确实给我们的K8s使用带来了便利，但是这些远远不够。我们设想一个场景，现在的集群节点突然不够用了，机器的cpu和内存被容器占满了，这个时候我们需要一个紧急的计算服务，怎么办？就算是现在去购买节点，等待部署完成，至少也需要几十秒才能开启我这边紧急的计算服务。

当然，我们可以使用hpa资源，对pod资源进行横向伸缩容，也可以用K8s开源的CA，我们将它和腾讯云的弹性伸缩组进行了对接，当我们觉得节点不够用的时候，可以通过CA来扩容节点。

hpa和ca伸缩容虽然可以解决一定的灵活问题，但是这还远远不够，离我们想快速通过一个简单API创建一个服务，这还是有一定距离的。

我们看一下这些简单的运算场景。例如批量运算场景、快速验证镜像场景、TKE快速对接场景。这些都是CIS产生的原因。CIS实际上就是Serverless Kubenetes服务，它也对标了很多其他公有云厂商，比如说微软的ACI，也和AWS的Fargate有点相似。它的主要功能是把K8s集群交给腾讯来管理，将集群交给云厂商管理，用户只需要关注Docker使用本身。这就是我们的CIS产品。

CIS是怎样一个产品？

CIS主要特性

CIS是一种使用用户承载工作负载，不需要用户管理、维护服务器的全托管容器服务。用户可以通过Cloud Dashboard、Cloud API、Kubernetes API创建一个容器，而这个容器实际上是落地在腾讯运维的大CIS集群中，我们选用k8s对这些容器进行管理，大家只用关注自己想用的时候调用我们的cis api就行了，而集群的管理交给腾讯来进行。

我们的CIS具有便捷、安全、便宜、灵活这四个特性。

• 便捷：主要是两个方面，第一是无须购买底层资源，直接通过简单的配置，就可以通过Docker image生成一个容器实例。第二是不需要手动删除一个容器实例，容器实例结束后，资源就会被释放。当然，您也可以配置这个容器实例长久存在。
• 安全：因为这是腾讯自己维护的CIS的K8s集群，可能大家会考虑有很多用户在使用腾讯云的产品，就有多租户安全的问题。这里请大家放心，是绝对安全的，我们基于VM级别的虚拟化隔离。而且CIS实例是具有VPC网络属性，也就是说你可以在VPC网络中配置一些安全组以及ACL策略进行访问控制。
• 便宜：从Docker来说，本来是基于namespace和cgroup进行隔离，也就是说它本来就是非常灵活的，你的CPU和内存限制可以以毫核和兆为单位。我们购买的cis实例CPU和内存量可以选择0.5核、0.5G，。第二，我们的计费是根据消耗资源进行秒级计费的。
• 灵活：它可以支持购买超强资源，一个实例里面也可以有多个容器，就是一个pod里面可以跑多个容器。

CIS产品应用场景介绍

CIS的主要应用场景有两个，一可以用于批量计算的场景，因为它支持秒级的批量解冻，同时逻辑结束就会自动释放，如果你有一些突然来的大批量计算业务，可以使用CIS，能够方便大家的计算作业。

二是可以有一些镜像的快速验证产品。比如说现在有一个镜像，想快速验证这个镜像是否OK，你就直接起一个CIS运行，然后进行快速的验证。

CIS技术方案

CIS产品技术架构

使用CIS，用户只需要关注容器实例本身，而腾讯工程师是运维CIS所属的落地K8s集群。也就是说，用户要启动一个CIS的时候，cis后台会对应在K8s集群中创建一个cvm，再在这个cvm上创建一区一的pod，这个pod里面会有对应的容器，最终用户就可以访问这个容器了。虽然说CIS资源是在腾讯的K8s集群里面管理，但实际上它有用户的VPC属性，用户可以直接通过网络访问他所购买的CIS实例。当然，它还会和我们的TencentHub和ccr去进行对接。这是整体的技术架构。

CIS网络方案

cis的网络用到了VPC的弹性网卡的功能。弹性网卡是腾讯云vpc的一款产品，借助于vpc的路由能力，腾讯云cvm上的一张网卡可以属于另外一个vpc网络，我们将这张网卡塞到cis容器所属的网络namespace，就能实现cis具有vpc属性。

CIS日志收集

我们通常都是通过日志来判断实例的运行情况，但是K8s pod中的容器如果销毁，容器中的日志真实文件肯定也会消失，pod所属的CVM可能会被其他人复用，因此我们需要把日志保存下来。我们这里采用的是时序型数据库储存cis日志。在cis集群中启动一个filebeat的daemonset，通过Filebeat来收集到CIS日志，再吐到es集群中。用户查询日志的时候，就直接通过ES集群中的相关API进行查询。这是CIS日志收集过程中的技术实现。

CIS与Serverless Kubernetes集群

Virtual Kubelet

讲到CIS技术实现的时候，大家可能也会好奇，好象没什么用吧，和我们本地搭个Docker没什么区别？实际上开源有一个特别好的东西叫Virtual Kubelet ，通过Virtual Kubelet 可以和现有的K8s集群进行对接。例如我们可以和原来的CCS，现在的TKE搭配使用，让CIS能够扩展运行在一个假设有无限资源的Virtual Kubelet 节点上。

这是怎么实现的呢？首先简介一下Virtual Kubelet。Virtual Kubelet是一个可以通过和现有Kubernetes集群节点对接，并把该集群的pod调度到“无限资源”的虚拟virtual-kubelet节点的开源项目。现在是微软ACI和亚马逊的fargate已经支持了该项目，我们将这个项目和cis的api进行对接，大家可以直接体验我们现在放在TencentHub上的virtual-kubelet镜像。

K8s现有一些node节点。现在部署一个Virtual Kubelet节点，我们也可以部署一些pod或者deployment，让它运行在Virtual Kubelet节点上。Virtual Kubelet节点上pod的落地是通过CIS集群，也就是说它会有一个CIS的API过来，最终创建的一个pod是运行在CIS集群上，同时因为这个pod上有一个属于用户k8s集群的弹性网卡，用户所拥有的k8s集群得到了扩展。

具体是怎么做的呢？我们可以看一下步骤。首先，我们可以在CCS节点上部署一个Virtual Kubelet pod，它会注册一个叫virtual-kubelet的node，virtual-kubelet和Kubelet的功能类似，Kubelet最终的落地创建pod，是通过DockerD把pod的容器创建出来，virtual-kubelet是通过CIS的云API把CIS的实例创建起来。第二步和第三步，是我们新建一个Deployment\Job之类的东西，yaml文件定义它管理的pod要运行在 virtual-kubelet节点，资源创建后，K8s的Master调度器开始工作，将pod调度到virtual-kubelet节点上。

当然，我们最终可以看到是这样的图， virtual-kubelet可以无限放大，实际上运行个很多CIS资源，因为它实际上不在用CPU内存，真正的CPU在用的是CIS集群本身。如果Deployment删掉，对应的这些实例也会被删掉。也就是说，通过virtual-kubelet这个中间件，你就可以实现CIS和TKE的对接，这对很多用户来说还是很方便的。

这是现在CIS的一些基本功能。总结一下，CIS是用户只用关注Docker本身的一种容器服务，它所落地的K8s是我们腾讯自己在维护的，这样做的好处是，用户可以不关注K8s的运维，同时也可以通过这些API，能够快速的对接现有的K8s集群，实现快速对接的功能。

Clear Container

什么是Docker？什么是K8s？

我们先回顾一下什么是Docker，什么是K8s。K8s是业界主流的paas平台，用户可以通过kubectl创建一些资源，这些资源的最主流落地是通过DockerD把pod的runtime（容器）创建出来。Docker是一个轻量级的虚拟化项目，同时Docker是K8s的pod的runtime。当然，K8s还支持例如gvisor等其他runtime。

CIS的整体架构

cis的架构是每个容器实例是运行在一个cvm节点上面的。这样做带来一个问题，实际上用户只需要它的容器，但是我们为了能保证多租户之间的隔离，为了保证安全，我们实际上起了一个厚重的虚拟机。尽管我们有一个强大的buffer池在这里，创建的请求热启动也是在30秒之内，性能能够保证，但是对于腾讯自己来说，这个运维成本确实是挺多的，用户只需要容器，我们却提供了一个虚拟机。

有了这个问题，我们应该该怎么改进呢？如果把Docker替换成Clear Containers会怎样？先介绍一下Clear Containers，或者说现在的kata Containers。左边图是Docker架构，Docker是基于linux namespace和cgroup技术的runtime，namespace保障隔离，cgroup控制CPU和内存资源。docker在业界最大的安全诟病是共内核。相反，虚拟机的主流技术，KVM结合硬件辅助虚拟化技术，将x86虚拟机kernel运行于non-root ring 0态，和host有一个很好的隔离。实际上这里的虚拟机，我们可以直接把它当作kata或者clear Containers。不同的是clear container有一个很小的内核，基于中间件，再构造虚拟化后的APP。

总结一下Clear Containers和Docker的区别，Clear Containers不共内核，更安全。

用Clear Containers替换Docker？

如果我们用Clear Containers替换Docker，这时候会怎样呢？这时还是有一个K8s的集群，但是现在不是虚拟机，而是真实的物理机，实际上我们也有这一款黑石产品，真正的Node节点落地是在物理机上面。这是一个物理机的Node节点，Clear Containers作为Kubelet runtime，也就是说，这个Clear Containers代替了原来的Docker在给用户提供服务。这样做的好处有两点。

第一，相比于原来的虚拟机起动厚重的虚拟机，虚拟机上再起动Docker提供服务，现在直接在物理机上起动轻量的Clear Containers直接给用户提供服务，虚拟机层级变小，这样就比较节约资源。第二，因为层级变小，也会提高性能。这么做当然是有很大好处的。但是有一个问题，Clear Containers或者kata Container能够和现在原生的Docker进行对接的吗？答案是可以的。也就是说，你可以使用Clear Container这个底层基于KVM的虚拟化技术，也可以复用原来的docker image。具体是怎么实现的，这是Clear Containers的细节。左边是原来的Docker细节，Docker的分层有一个Containerd，接下来是各个shim，最后的实际落地是runshim，它结合namespace隔离调用了linux的clone系统调用。现在相当于runshim变成了cc-runtime，前面部分的Docker镜像都是相同的，但是最终的落地，cc-runtime原来是基于clone系统调用去创一个Docker容器，现在我们用cc-runtime结合qemu去创一个虚拟机。这样做到底有什么好处呢？就是虚拟化更安全了。它为什么可以复用Docker的生态，这一部分都不变呢？这就是得益于Clear Containers或者kata Containers组件的拆解。原来Clear Containers包含cc-runtime、cc-shim、cc-proxy、cc-agent、miniOS。所谓miniOS，虚拟机起来的时候需要一个最小内核和rootfs。相比hyper.sh，它是runV，但是它不能够兼容Docker生态，Clear Container只实现runtime，把原来的runshim分成cc-runtime和cc-agent，这样还会有vm带来的额外通信机制。原来Docker文件系统是通过virtio-blk/9pfs机制挂在虚拟机里面，这样就可以实现复用Docker生态，同时也能带来基于KVM隔离虚拟化的安全。

第二个问题，大家比较关心的是kata Containers或者Clear Container的网络到底是怎么进行的。我们知道，Docker的网络有一个VETH设备，通过veth设备联通docker0网桥进入host协议栈。但是虚拟机就不一样了，基于KVM的虚拟机不支持veth设备，往往是虚拟机里面有一个虚拟网络设备，host上更多是一个tap设备。如果我们要复用Docker的网络生态，需要创建一个VETH设备链接cc-bridge网桥，再和host上的tap设备，网络流量就通过到host的tap0—cc-bridge—eth0—veth0—Docker0，再进host协议栈出去。

还有一个问题，Clear Containers原来是每个容器都会起一个虚拟机，这样就会带来一个问题，pod有多个容器的概念，也就是说一个pod里面会有多个中期，如果每个pod都要起一个虚拟机，一个pod多容器，就有若干个虚拟机吗？答案是不一定的，因为Clear Containers可以借助CRI-O和K8s进行对接。原来Kubelet是这样的，如果我们要创建pod，直接是Kubelet和Docker进行访问，然后把这个容器创出来。加了CRI-O这个组件之后，Kubelet作为client，有个CRI-O Server在这里，CRI-O会控制起一个runc，基于Docker的pod就起来了。当然，如果是Clound Containers或者kata Containers，就要调用cc-runtime创建clear container。同时你也可以根据自己的应用编排安全需要，控制pod的容器是共虚拟机还是多个虚拟机。

Clear Containers下一步的技术规划就大概讲到这里。今天我的演讲部分也就结束了。我们的CIS已经上线，如果大家想体验，可以找我们开白名单。