重磅 | Docker捐出containerd，CoreOS捐出rkt

K8S技术社区正式上线啦！快快关注找到志同道合的小伙伴！

CloudNativeCon + KubeCon Europe 2017峰会第一天，近2千位容器爱好者齐聚柏林BCC 会议中心，一起感受Cloud Natvie云原生计算和 Kubernetes 的魅力，以及容器生态圈前沿技术。以下是K8S技术社区特约记者船长的现场报道：

CloudNativeCon+KubeCon现场

容器生态圈的历史性事件

随着Docker容器运行时containerd、CoreOS容器引擎rkt双双进入CNCF，容器生态即将进入一个崭新的发展阶段：OCI 容器运行时标准runc+CNCF容器运行时实现将成各大厂商统一标准，Kubernetes将确立为容器编排的事实标准。

至此，CNCF 基金会已管理了 Kubernetes、Prometheus、OpenTracingFluentd、Linkerd、gRPC、CoreDNS、containerd、rkt 等9个云原生项目，CNCF 基金会也持续关注目前正在快速演进和发展的潜在项目，吸引更多优秀项目加入。

来自 Google 的Kubernetes 项目管理负责人Aparna Sinha详细介绍了 Kubernetes 1.6新版本的特性，值得一提的是，得益于 CoreOS etcd v3版本的可扩展性，以及Kubernetes采用 gRPC 取代旧版本中 json 字符串作为组件间消息传递机制， 使得Kubernetes 支持单集群5千节点（15万 pod），大规模可扩展性和稳定性是企业生产级容器平台必不可少的特性，大规模环境的稳定性以及新特性的不断加入，使Kubernetes 成为企业容器编排首选平台。

关于 Kubernetes 1.6新版本的详细特性请参照3月29日社区文章 【图文直播】德国KubeCon大会详解K8S 1.6最新特性

KubeCon Day1重要话题总结和点评

01

为什么 Docker 选择把 containerd 捐赠给 CNCF 基金会？ 【 Patrick Chanezon, Docker】

从2016年4月份 Docker 发布1.11版本开始，containerd 已经从 Docker Engine 中拆分出来成为独立的容器运行时组件，作为Linux 和 Windows 系统下的守护进程，containerd 为宿主机管理整个容器的生命周期，包括容器镜像转换和存储、容器执行和监控管理、容器网络和存储资源挂载等等。

选择把containerd捐赠给 CNCF 基金会，主要原因在于两者的目标一致，并且 containerd 的技术实现也跟 CNCF 其它项目保持一致，能很快融入当前生态。Kubernetes 从1.5版本对Docker版本的支持由1.10.3升级到了1.12.3，这意味着containerd 已经成为 Kubernetes 的关键部分。技术实现方面，containerd通过本地 UNIX Socket 暴露 gRPC API给上层系统调用，并且以 Prometheus 的数据格式对外提供监控数据。同时，containerd 也完全兼容 OCI 标准以及 runC实现并将通过 OCI 认证。

从1.6版本开始，Kubernetes 已经默认启用了 CRI 机制，并且默认使用 Docker-CRI 实现避免了 kubelet 直接调用 Docker API ，减轻了 Kubernetes 对 Docker 的直接依赖，Kubernetes CRI 对 containerd 的支持也已经有 POC 代码

（https://github.com/kubernetes/kubernetes/pull/43655），可以看出，Docker 引擎将会逐渐淡出 Kubernetes 的视野，containerd 将会通过 CRI 接口成为 Kubernetes的默认容器引擎和生命周期管理工具。

02

KubeVirt - 用 Kubernetes 作为基础架构控制平面，统一管理容器和虚拟机，构建未来融合式数据中心 【 Itamar Heim & Fabian Deutsch, Red Hat】

Kubernetes 是非常好的容器管理平台并且已被很多企业采用，同时企业数据中心的现状是虚拟机和容器将会在很长一段时间内共存，就底层技术来说两者的差异没那么大，虚拟机也是用户进程，容器和虚拟机使用了同样的隔离技术如 selinux, cgroups 等，如果企业想把 Kubernetes 作为数据中心基础架构的单一控制平面，该怎么做呢？Red Hat 的工程师给出了他们的答案：KubeVirt。

通过 Kubernetes Third Party Resource（TPR） 机制，KubeVirt 扩展了 Kubernetes API 并且加入了 ‘VM’ 的资源类型。KubeVirt由如下图所示的几大组件组成：

1. virt-api-server

KubeVirt 进行虚拟机管理的入口，响应 VM TPR 的请求并且进行验证。virt-api-server不对 kube-apiserver进行修改而选择扩展出新 API Server， 有利于架构解耦以及不破坏当前 Kubernetes 对容器的管理流程。

2. VM TPR

以 Kubernetes TPR 方式定义 VM 参数，如CPU 类型、CPU 内存大小，网卡信息、磁盘信息等等。

3. virt-controller

响应virt-api-server的请求，监控 VM TPR 的变化，因为每一个 VM 对象需要由 pod 来初始化，并且 VM 迁移时对应 pod 也需要同步迁移，这样要求 virt-controller 同时需要管理跟 VM 对象关联的 pod生命周期。virt-controller 会把VM 相关操作路由到 virt-handler。

4. vm-launcher

每个 VM 对象都会创建1个 pod，这个 pod 会运行 vm-launcher。其作用是提供 cgroups 和 namespaces，用来启动虚拟机进程，一旦虚拟机进程在容器内出现，virt-handler 将把自身绑定到这个进程，这样，虚拟机就通过 pod 创建出来。

5. virt-handler

以 DaemonSet 的方式在每个节点上运行一个实例，相应virt-controller的请求，监听VM 对象的变化并根据相应描述调用 libvirtd更新虚拟机状态。

6. libvirtd

在每个主机上运行，负责真正的虚拟机创建删除等管理工作。

KubeVirt有它的优势也有值得改进的地方：优势是当前的工作流程和机制很好地封装了虚拟机逻辑，使用pod 作为虚拟机的启动器，容易加入对虚拟机迁移等高级特性的支持。缺点是当前实现方式没有采用 Kubernetes 当前使用的 CRI 接口机制，跟 Kubernetes 整体架构不太一致。

除了 KubeVirt 之外，当前也有另外几种虚拟机和容器统一调度的实现方案：

1. virtlet

同样是为了让 Kubernetes 能创建和管理虚拟机资源，virtlet 与 KubeVirt 的目标一致，但实现方式上采用了 Kubernetes CRI 的标准实现，目前处于 pre-alpha 阶段。

2. Frakti

Frakti 是 HyperContainer 的 Kubernetes CRI 实现，当前已经是 Kubernetes repo 下的正式项目，思路是基于 Hypervisor 的容器化，让 Kubernetes把 pod 和容器直接运行于宿主机的 hypervisor 之上。这是另一种跟 KubeVirt 和 virtlet 不同的容器和虚拟机深度融合的思路。

03

Open Service Broker API 以及 Kubernetes Service Catalog【Paul Morie, Red Hat & Chip Childers, Cloud Foundry Foundation】

Service Broker 可以理解成可管理一系列外部服务的服务端程序，作为云原生平台如 Kubernetes，OpenShift，CloudFoundry中，应用程序跟外部服务之间的桥接，让云平台用户和应用程序能简单地消费服务而不用关注服务创建销毁同步等细节。连接开发者和众多服务生态，让应用程序能简单方便地使用外部服务。

Service Broker API 的简要历史回顾：

1. v1版本由 VMware 在2011年开源出来，支持5种服务：MySQL、PostgreSQL、RabbitMQ、MongoDB 和 Redis。关键的设计思想参照了12factor的第4条，让无状态应用能把以挂载的方式简单地把数据存储在服务后端。

        

2. v2版本在2013年发布，代码重构，重新抽象和解耦了平台和服务实现。

        

3. 在2015年增加了异步管理功能。

        

4. 在2015年底2016年初，开始支持 Google Cloud 和 Deis的云平台。

        

5. CloudFoundry 用户提议支持多平台直接的交互，如 Mesos资源管理加Kubernetes容器调度的混合使用场景。

       

6. 当前由Fujitsu, Google, IBM, Pivotal, Red Hat and SAP等6家公司共同管理 Open Service Broker API 项目。

        

Open Service Broker API 的概念非常简单，主要包括以下几种资源和操作：

        

1. Catalog：由某一特定 Broker 提供的服务列表。一个 catalog 可包括来自于一个或多个  broker 的服务。

        

2. Service：由服务 broker 提供的一种能力，如 Database as a Service。

        

3. Service Instance：service 的实例，如某一个具体的 MySQL 数据库实例My DB。

        

4. Binding：应用程序和 service 实例直接的映射关系，如为我的应用程序’guestbook’使用 My DB 里的认证信息。

        

示例操作流程见下面：

Kubernetes Service-Catalog  当前为 Kubernetes 孵化项目，正是基于这个思想，在 Kubernetes 环境中实现 Open Service Broker API让应用更好共享和消费服务。

04

Audit in Kubernetes Now, and in the Future 【Maciej Szulik, Red Hat】

审计是按时间顺序记录用户、管理员或其它系统组件的跟安全相关的操作行为，给系统管理员提供对以下几个问题的回答：1.发生了什么？2.什么时候发生的？3.谁发起的？4.对谁发起的？5.在哪里被观察到的？6.在哪里被发起的？7.会影响那些地方？用来发现系统安全违规行为、性能分析以及软件 bug 等。

提醒大家注意的一点是，审计系统并不会给系统带来额外的安全特性。以 Kubernetes Audit 为例子，Audit 是 kube-apiserver 接收到的请求流程中的验证插件之一，工作在 Authentication 认证之后，也就是说，审计只会针对已认证用户的操作行为进行记录。

Kubernetes Audit 审计作为kube-apiserver 的一部分，配置非常简单，在启动 kube-apiserver 时添加如下选项可以打开审计功能：

kube-apiserver

…

        - -audit-log-path                 //把审计日志追加到指定文件或新创建出审计文件

        - -audit-log-maxage           //审计日志文件最长保留天数，过期后 Kubernetes 自动删除老文件

        - -audit-log-maxbackup     //审计日志文件最多保留数量，超过数量后 Kubernetes 自动删除

        - -audit-log-maxsize          //单个日志文件的大小，MB 为单位

当前 Kubernetes 审计的好处是轻量级实现、日志格式简单；但同时，它目前只对HTTP 请求做了审计、噪音数据多、基于日志文件。将来进一步的改进方式，可参考社区讨论：

https://github.com/kubernetes/features/issues/22

https://github.com/kubernetes/community/pull/145

在审计标准化方面，CADF（Cloud Auditing Data Federation，云审计数据互联规范）定义了云环境中审计数据的标准格式，供各个云平台提供商使用。pyCADF 是 CADF 规范的 Python 实现，当前 OpenStack Keystone中使用其作为审计中间件。

此外，CNCF 基金会执行董事Dan Kohn在开场演讲时，介绍了基金会最新的进展， 继DELL EMC 成为新的白金会员，SUSE成为新黄金会员后， CNCF当前一共有81个会员并在持续增长中。

第一天的重要讲座先分享到这，欢迎大家持续关注 K8S 技术社区给大家带来的后续现场报道以及 Kubernetes 技术深度解析。

 March 29-30，2017    Berlin，Germany 

2017年3月29日至30日，K8S领域盛会KubeCon在德国柏林举办，K8S技术社区记者将在柏林持续为大家带来现场报道！敬请关注！

K8S技术社区当前有两大技术推广平台，K8S技术社区官方网站（www.k8s.cn）和K8S技术社区微信公众平台（kubernetescn），我们欢迎广大K8S技术同好们关注支持，也希望集合K8S技术极客进群交流（筒子们后台留言微信号！），有任何建议或问题都可以随时与我们取得沟通（[e-mail]），感谢支持！