小白也能玩转 Kubernetes 你与大神只差这几步（二）

因文章略长，故分为三篇展开呈现，本篇为第二篇。

容器实例服务

容器实例服务（Container Instance Service，CIS）是一种使用容器为用户承载工作负载，不需要用户管理、维护服务器的全托管容器服务。它具有便捷、安全、便宜、灵活等四个特性。

便捷意味着用户无须购买底层资源，通过简单的配置，就可以用 docker image 生成容器实例，而容器结束实例即会结束，无须手工释放，也可以配置重启策略使实例长久存在。

安全是因为 CIS 由腾讯云自己进行集群维护，Kata containers 提供了 docker 级别的生产速度和 vm 级别的资源隔离，在实例运行在用户的 vpc 网络中，支持配置安全组和 ACL 策略进行访问控制。

在成本方面，CIS 根据购买的 cpu、内存量，按实例实际运行的时间按秒计费；需要多少用多少，从启动开始，实例无论出于什么原因一旦结束即停止计费，价格合适。

而灵活性方面，容器实例支持购买超小资源，在一个 pod 里可以跑多个容器；一个实例可以是一个容器，亦可以包含多个相关容器；

在应用场景方面，容器实例支持秒级批量启动、逻辑结束自动释放、便宜的价格、支持通过内外网和其他资源互通等特性使其很适合进行计算作业。

其次也可以有有镜像的快速验证产品，用户只要拥有程序的容器的镜像，就可以通过一些简单的配置，以极低的成本把程序运行起来。例如进行一次程序验证、爬取一个网站、部署一个 Web 服务等等，任何支持容器的简单应用都可以使用容器实例来部署。

CIS 技术方案

CIS 可以让用户只需要关注容器实例本身，将运维 CIS 所属的落地 K8s 集群的工作交给腾讯云。用户在启动一个 CIS 时，腾讯云会对应在 K8s 集群中提供 CVM 资源，在这个资源给出 pod 和对应的容器，用户就可访问该容器。CIS 资源有 VPC 属性，用户可以直接通过网络访问所购买的 CIS 实例。当然，它还会和我们的 Tencent Hub 和 image registry 去进行对接。

CIS 底层由多地域多套 Kubernetes 集群组成，而每个 CIS 实例生成时会配置用户 VPC 的弹性网卡的功能。VPC 弹性网卡本质上是，弹性网卡可以达到 VPC 网络的相连，弹性网卡是挂在容器里面。当有了 VPC 属性之后，它就可以访问 VPC 内的其他 CIS、CVM、CDB 和 COS 等网上的其他资源打通。

一般来讲，容器中的日志真实文件会随着 k8s pod 的消失而消失。但要支持秒级计费能力，就需要通过日志判断实例，因此日志是不允许消失。所以腾讯云采用的是时序型数据库，通过开源软件 Filebeat 来收集 CIS 日志，转到 ES 数据库中。在每个实例节点上部署 DaemonSet 后，日志转到 CIS 集群中，用户查询日志时，就会通过 ES 集群中的相关 API 进行查询。

CIS 与 Serverless Kubernetes 集群

开源项目 Virtual Kubelet 是一个可以部署在已有 Kubernetes 集群节点上，并把该集群的 pod 调度到“无限资源”的虚拟节点 CIS 集群上。pod 节点可以部署在 virtual Kubelet 上，其可以通过 CIS 集群落地，pod 上的弹性网卡属于 Kubernetes 的 VPC 网络，这样做就可以直接在 CIS 上运行大批量、周期性的、突发的任务，作为已有 kubernetes 集群的资源补充。

Virtual Kubelet 可以与腾讯云容器服务（ Cloud Container Service，CCS）共同构建 Severless 服务。CCS 支持用户使用 CVM、VPC、LB、CBS 等基础产品搭建具备完全操作权限的 Kubernetes 集群，通过在 CCS 集群 node 上部署 virtual kubelet 可以把 CIS 实例作为集群 pod 调度。

具体操作时，需要在 CCS 上任一节点上部署 virtual-kubelet pod，该操作会为该 CCS 集群添加一个虚拟节点“virtual-kubelet node”；然后新建 Deployment\Job\CronJob 时通过将目标节点指向 virtual-kubelet node，则这些服务的 pod 不会占用 CCS 集群的 CVM 资源；

CCS 服务的 pod 被调度到了 CIS 服务上，意味着用户可以不考虑 CCS 集群的底层资源，当然也不需要做 CVM 扩缩容，就可以创建“无限”的服务；通过 virtual kubelet 调度创建出的 CIS 实例依然会被上层的 CCS 服务控制，例如 Deployment 会把下层的 CIS 实例总保持在期望的数量和状态；这些 CCS 服务一旦被删掉，跟其相关的 CIS 实例也会被自动删除；

容器实例与 Clear Containers

总结来看，Docker 是一个轻量级的虚拟化项目，同时 Docker 是 K8s pod 的 runtime；目前用户面临的问题是。将用户容器运行在单独的虚拟机上可以保障租户间的隔离安全，但是用户只需要一个容器，虚拟机的其他是多余的；而 Clear Containers 和 Docker 的区别在于，前者不共用内核，基于 KVM 隔离更安全；

Clear Container 与原来的物理机启动厚重的虚拟机相比，虚拟机上再启动 docker 提供服务，现在直接在物理机上启动轻量的 clear container，直接给用户提供服务，虚拟化层级变小，更节约资源，也更提高性能。

在网络方面，Docker 的网络有一个 VETH 设备，如果你访问外面，会有一个 Docker0 网桥，如果你访问外网，会有 Snat。但是是基于 KVM 的虚拟机，很多厂家都是用 QEMU 把虚拟机启动，虚拟机里面有一个虚拟网络设备，host 上更多是一个 tap 设备，也就是说虚拟机不支持 VETH 设备。如果要复用 Docker 生态，所以又有一个 VETH 设备，这里就有一个 cc-bridge 网桥，网络就通过到 host 的 tap0—cc-bridge—eth0—veth0—Docker0，再进协议栈，这样出去。

Clear container 比 Kubernetes 更注重技术细节，其技术实现包含 cc-runtime、cc-shim、cc-proxy、cc-agent、miniOS（kernel 和 rootfs）；并且只实现 runtime，把原来 runc 拆分成 cc-runtime 和 cc-agent，再加上 VM 带来的额外通信机制。

Clear Containers 原来是每个容器都会起一个虚拟机， pod 有多个容器的概念，难道每个 pod 里面每个容器都要起一个虚拟机，一个 pod 有若干个虚拟机吗？

事实上并不需要如此。Clear Containers 可以借助 CRI-O 和 K8s 进行对接。在过去，如果要创建 pod，直接是 Kubelet 和 Docker 进行访问，然后把这个容器创出来。加了 CRI-O 这个组件之后，Kubelet 作为 cri-o client，对 cri-o server 控制一个 run client，基于 Docker 的 pod 就起来了。当然，如果是 Clound Containers 或者 Clear Containers，就要调用 cc-runtime，需要根据应用编排安全的需要选择

Tencent Hub 技术架构与 DevOps 实践

DevOps 的概念从 2009 年至今已经过去了近十年的时间。DevOps 应当以业务敏捷为中心，构造适应快速发布软件的工具和文化。那么 Tencent Hub 是什么？Tencent Hub 核心是两部分，第一部分，是一个多功能的存储仓库，包含了 Docker 镜像存储功能以及 helmcharts 等存储；第二部分，Tencent Hub 是一个 DevOps 引擎，通过 workflow 工作流的编排，去帮助大家建立自己的 DevOps 流程。

Tencent Hub 技术架构

Tencent Hub 的总体架构， Tencent Hub 在镜像仓库的存储是基于 COS 存储，因为 COS 可靠性非常高，能达到 11 个 9 的可靠性；Tencent Hub 有一个自研 workflow 引擎，使用 YAML 定义 DevOps 流程，让 DevOps 本身达到 Program 的方式；基于容器的插件机制（Component），最大限度复用已有 DevOps 任务；Tencent Hub 使用容器去实现插件机制，来封装用户自定义的 DevOps 任务。使用 Kubernetes 作为 job 执行引擎，具有良好的可扩展性；在 Docker 存储方面，加入了 Docker 镜像漏洞扫描等。

在 Tencent Hub，最核心的存储还是 Docker 镜像。Tencent Hub 除了公共的镜像存储之外，还支持私有的镜像存储。在私有镜像存储里面，需要通过登录才能获取或者上传自己的 Docker 镜像。

首先，客户端发起 push/pull 操作，client 连接 Registry 检查权限；Registry 返回 401，并且返回了获取 Token 的服务地址；client 请求授权服务获取 Token(OAuth2 或 Basic Authentication)；client 返回一个 Token 表示客户端的访问授权列表；client 携带 Token 重新请求 Registry 获取资源；Registry 校验 Token 以及其中的权限列表通过后， 与 client 建立 pull/push 会话，开始上传/下载数据。

Tencent Hub pull 的授权流程大体如下， Docker 服务端首先会去访问 webhook，客户端会根据当前是否有 Token 来返回一个授权的地址，即hub.tencentyun.com/token这个地址。然后客户端就会自动访问/Token的URL，带上当前的状况以及申请的权限范围，最后生成阶段再返回。最后，当前面都申请完成之后，就会进入Docker镜像拉取流程。

Docker 镜像是分层组织形式，每个 Docker 镜像包含多个 Layer 和一个 Config 文件，每个 Layer 构建一个 Docker 镜像文件系统里面出现的差异，Config 文件包含当前 Docker 镜像能运行的一些环境要求。这些文件被一个 Manifest 文件引用起来，形成可以一直拉取 Manifest，通过它可以找到所有的 Docker 镜像内容。

设计好处主要有三点。首先，由于所有数据可以被校验，安全性高；第二，相同内容的 layer 只需存储一份，所以冗余少；第三，整个 Docker 镜像里无论哪个 Layer 有改变，都会最终影响到 Manifest 的改变，所以 Docker 镜像并不是重新修改一个 Layer，而是重新生成，因此做缓存的时候就可以在不同环境下部署缓存。

Tencent Hub 镜像的存储核心是利用了 Docker 官方实现的 distribution。distribution 的实现在这个图里面描述得比较清楚，代码层次结构也几乎相同。最上面有 API root 层分发，第二层会有一个权限控制的一层。在权限控制下面有实现 API 协议的函数处理，提供主要的业务逻辑实现。最终是 distribution 的实现，提供了一套存储的插件机制，有一个标准的存储接口，规定了文件上传、文件移动。

目前腾讯云容器服务的仓库是 CCR，而并不是 Tencent Hub。CCR 有两个问题，第一是不同地域的镜像是不通的，直接依赖了 COS 提供的分发能力，COS 是无法跨区域的，所以会存在问题。第二是拉取多个镜像时，对延时不敏感，但是对吞吐量很敏感。

在 Docker 镜像的存储完成之后，还是提供了一个 Docker 镜像的静态扫描。通过对比包管理(apt, yum)记录的软件版本与本地漏洞数据库中的软件版本得出漏洞列表。Scanner 周期性地与漏洞数据库进行同步获取最新的漏洞信息；镜像上传完成后发送到扫描中心进行异步漏洞扫描；而当新漏洞被发现时，Registry 也会受到通知，同时可以通过 webhook 将信息投递给开发者。