Kubecon告诉你，你的容器安全吗?
您的容器安全吗?您是否对将 Linux 名称空间作为安全边界感到满意?在本次KubeCon大会上，将会有来自阿里巴巴的高级技术专家Lei Zhang 和来自HyperHQ 的工程师Fupan Li来为大家分享他们关于容器安全方面的宝贵经验。
他们希望通过与 containerd 的集成，集中讨论如何利用基于硬件虚拟化的运行期(特别是 KataContainers)在 Kubernetes 集群中的设计和实现。并将演示他们是如何将 KataContainers 重构为containerd 的插件的，运行时插件如何通过容器运行期接口来处理网络，并通过自定义卷插件解决基于管理程序的容器运行时的低性能问题。
在这之前，我们有必要先详细了解一下containerd 和KataContainers这两个概念。把基础知识夯实更有利于大家汲取更高级的知识。
关于containerd
containerd的发音是“container-dee”，正如它的名字，它是一个容器守护进程，而不是“收集-迷，contain-nerd”。它最初是作为 OCI 运行时(就像 runC一样)的集成点而构建的，然而在短短一年中它增加了许多特性，使其达到了像 Docker 这样的现代容器平台以及像 Kubernetes 这样的编排平台的需求。
近年来，containerd 被用于 Docker、Kubernetes CRI、以及一些其它的项目，在这些平台中事实上都使用了 containerd，而许多人并不知道 containerd 存在于这些平台之中。
那么，使用 containerd 能做些什么呢?你可以拥有推送或拉取功能以及镜像管理。可以拥有容器生命周期 API 去创建、运行、以及管理容器和它们的任务。一个完整的专门用于快照管理的 API，以及一个其所依赖的开放治理的项目。如果你需要去构建一个容器平台，基本上你不需要去处理任何底层操作系统细节方面的事情。关于 containerd 中最重要的部分是，它有一个版本化的并且有 bug 修复和安全补丁的稳定 API。
由于在内核中没有一个 Linux 容器这样的东西，因此容器是多种内核特性捆绑在一起而成的，当你构建一个大型平台或者分布式系统时，你需要在你的管理代码和系统调用之间构建一个抽象层，然后将这些特性捆绑粘接在一起去运行一个容器。而这个抽象层就是 containerd 的所在之处。它为稳定类型的平台层提供了一个客户端，这样平台可以构建在顶部而无需进入到内核级。因此，可以让使用容器、任务、和快照类型的工作相比通过管理调用去 clone() 或者 mount() 要友好的多。与灵活性相平衡，直接与运行时或者宿主机交互，这些对象避免了常规的高级抽象所带来的性能牺牲。结果是简单的任务很容易完成，而困难的任务也变得更有可能完成。
图：containerd
关于KataContainers
kata containers是由OpenStack基金会管理，但独立于OpenStack项目之外的容器项目。它是一个可以使用容器镜像以超轻量级虚机的形式创建容器的运行时工具。
kata containers整合了Intel的 Clear Containers 和 Hyper.sh 的 runV，能够支持不同平台的硬件(x86-64，arm等)，并符合OCI(Open Container Initiative)规范，同时还可以兼容k8s的 CRI(Container Runtime Interface)接口规范。目前项目包含几个配套组件，即Runtime，Agent， Proxy，Shim，Kernel等。目前Kata Containers的运行时还没有整合，即Clear containers 和 runV 还在独立的组织内。
如果大家了解Docker技术，就会知道，真正启动Docker容器的命令工具是RunC，它是OCI运行时规范 (runtime-spec)的默认实现。
Kata containers其实跟RunC类似，也是一个符合OCI运行时规范的一种实现(即Clear Container和runV 都符合OCI规范)，不同之处是，它给每个容器(在Docker容器的角度)或每个Pod(k8s的角度)增加了一个独立的linux内核(不共享宿主机的内核)，使容器有更好的隔离性，安全性。
容器技术发展如火如荼，其安全问题也随之变得愈发重要。本次会议上，专家们还将介绍容器运行期接口的设计和实施，这已经引发了 Kubernetes 社区容器运行时的第二次风靡时期。最后，将解释为什么管理程序运行时不仅仅是关于安全性：旧版应用程序和硬件多租户，它已为世界 containerd + KataContainers 做好准备。
本期则隆重推荐：
Lei Tang , Google软件工程师
Lei Tang博士是谷歌的软件工程师。他目前在做的项目包括云服务网格和云服务的安全系统。他获得莱斯大学(Rice University)计算机科学博士学位。他荣获第十二届移动 Ad Hoc 网络和计算 ACM 国际研讨会(ACM MobiHoc 2011)最佳论文奖。他是“IEEE Transactions on Industrial Informatics”期刊的副编辑。已经在国际期刊和大会发表了 15 份研究论文，他的论文被国际研究论文引用超过 740 次。
Scott Nichols , Google软件工程师
Scott Nichols 是一名谷歌人，从事 CloudEvents 等相关执行工作。Scott Nichols曾在 2018 年参加哥本哈根大会的演讲，演讲关于使用 OSBAPI 控制家居自动化。
KubeCon + CloudNativeCon 2018即将开始，请立即购票，勿失良机!
余票所剩无几，欲购从速，票价如下：
标准注册2400元;
贵宾注册6000元;
学术或爱好者注册500元;
更多精彩内容请搜索 KubeCon 前往官网进行了解!
下周二，我们与您在上海见面!
———————————感谢活动赞助商———————————
钻石赞助商
阿里云
华为云
IBM Cloud
Tencent Cloud
铂金赞助商
灵雀云
才云
Google Cloud
英特尔
京东
Microsoft Azure
Rancher
VMware
黄金赞助商
SUSE
白银赞助商
BoCloud
Cloud Foundry
DaoCloud
EasyStack
Eclipse Foundation
Elastic
GitLab
Mesosphere
NGINX
PingCAP
Red Hat
YAHOO! JAPAN
初创企业赞助商
Aljabr
AMPERE
CStack
EMQ
Giant Swarm
谐云科技
inwinSTACK
KONTENA
蓝灯数据
LF DEEP LEARNING
PlanetScale
时速云
睿云智合
媒体合作伙伴
开源中国社区
极客邦科技/ InfoQ
TFIR
THE NEW STACK
社区合作伙伴
ServiceComb
ArcBlock
容器时代
中国电子技术标准化研究院
中国开源软件(OSS)推进联盟
异步社区
掘金
开源社
Ladies Who Tech
开源中国社区
云计算开源产业联盟
WOMEN WHO CODE
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
