Kubernetes 就像一辆翻斗车。它非常适合解决它所针对的问题，但你必须首先掌握其学习曲线。

在为什么说 Kubernetes 是一辆翻斗车中，我谈到了一个工具如何优雅地解决它所设计用来解决的问题 —— 只是你要学会如何使用它。在本系列的第 2 部分中，我将更深入地了解 Kubernetes 的学习曲线。

Kubernetes 的旅程通常从在一台主机上运行一个容器开始。你可以快速了解运行新版本软件的难易程度，与其他人分享该软件的难易程度，以及对于这些用户按照你预期方式运行它的难易程度。

但是你需要：

• 两个容器
• 两个主机

使用容器在端口 80 上启动一个 Web 服务器很容易，但是当你需要在端口 80 上启动第二个容器时会发生什么？当你构建生产环境时，需要容器化 Web 服务器在发生故障时转移到第二个主机时会发生什么？在任何一种情况下，这个答案简单来说就是你必须采用容器编排。

当你开始处理两个容器或两个主机问题时，你将不可避免地引入了复杂性，因此，这就是一个学习曲线。这个两个服务（容器的更通用说法）或两个主机的问题已经存在了很长时间，并且由此带来了复杂性。

从历史上看，这将涉及负载均衡、集群软件甚至集群文件系统。每个服务的配置逻辑都嵌入在每个系统（负载均衡、集群软件和文件系统）中。在负载平衡器后运行 60 或 70 个集群的服务是复杂的。添加另一个新服务也很复杂。更糟糕的是，撤下服务简直是一场噩梦。回想起我对生产环境中的 MySQL 和 Apache 服务器进行故障排除的日子，这些服务器的逻辑嵌入在三、四个或五个不同的地方，所有这些都采用不同的格式，让我头疼不已。

Kubernetes 使用一个软件优雅地解决了所有这些问题：

1. 两项服务（容器）：✅
2. 两台服务器（高可用性）：✅
3. 单一配置来源：✅
4. 标准配置格式：✅
5. 网络：✅
6. 储存：✅
7. 依赖关系（什么服务与哪些数据库对应）：✅
8. 易于配置：✅
9. 轻松取消配置：✅（也许是 Kubernetes 最强大的部分）

等等，这样初看起来 Kubernetes 非常优雅、非常强大。 没错。你可以在 Kubernetes 中建模一整个微型 IT 世界。

所以，是的，就像开始使用巨型翻斗车（或任何专业设备）时，有一个学习曲线。使用 Kubernetes 还有一个学习曲线，但它值得，因为你可以用一个工具解决这么多问题。如果你对学习曲线感到担忧，请仔细考虑 IT 基础架构中的所有底层网络、存储和安全问题，并设想一下今天的解决方案 —— 这并不容易。特别是当你越来越快地引入越来越多的服务时。速度是当今的目标，因此要特别考虑配置和取消配置问题。

但是，不要混淆了建造或配置 Kubernetes 的学习曲线（为你的翻斗车挑选合适的挡泥板可能很难，LOL）和使用它的学习曲线。学习用如此多的不同层次（容器引擎、日志记录、监控、服务网格、存储、网络）的技术来建立自己的 Kubernetes 有很多不同的选择，还有每六个月维护每个组件的更新选择，这可能不值得投资 —— 但学会使用它绝对是值得的。

我每天都与 Kubernetes 和容器泡在一起，即使这样我都很难跟踪几乎每天都在宣布的所有重大新项目。 但是，每一天我都对使用单一工具来模拟整个 IT 多个方面的运营优势感到兴奋。此外，记住 Kubernetes 已经成熟了很多，并将继续发展下去。与之前的 Linux 和 OpenStack 一样，每一层的接口和事实上的项目都将成熟并变得更容易选择。

在本系列的第三篇文章中，我将深入挖掘你在驾驶 Kubernetes “卡车”之前需要了解的内容。

via: https://opensource.com/article/19/6/kubernetes-learning-curve

作者：Scott McCarty 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

翻斗车是解决各种基本业务问题的优雅解决方案。

这篇文章写于 Kubernetes 的生日（6 月 7 日星期五）前夕。

翻斗车很优雅。说真的，不信你听我说。它们以优雅的方式解决了各种各样的技术问题。它们可以搬动泥土、砾石、岩石、煤炭、建筑材料或道路上的障碍。它们甚至可以拉动拖车及它们上面的其他重型设备。你可以给一辆翻斗车装上五吨泥土，然后自驾游遍全国。对于像我这样的电脑极客来说，那就是优雅。

但是，它们并不容易使用。驾驶翻斗车需要特殊的驾驶执照。它们也不容易装配和维护。购买翻斗车和各种维护时要做很多选择。但是，它们可以优雅的搬动那些垃圾。

你知道搬动垃圾有什么不优雅的地方吗？假如你有一款新型的紧凑型轿车，它们到处可以买到，易于驾驶、更易于维护。但是，用它们来装泥土就很糟糕。这需要跑 200 趟才能运走 5 吨垃圾，而且，之后没人再会想要这辆车了。

好吧，你可以买一辆出售的翻斗车，而不是想自己造一辆。但是我不同，我是个极客，我喜欢自己造东西。但……

如果你拥有一家建筑公司，你就不会想着自己造一辆翻斗车。你肯定不会维持一条供应链来重构翻斗车（这可是一条很大的供应链）。但你可以学会驾驶一辆。

好吧，我的这个比喻很粗糙，但很容易理解。易用性是相对的，易于维护是相对的，易于装配也是相对的。这实际上取决于你想要做什么。Kubernetes 也不例外。

一次性构建 Kubernetes 并不太难。配置好 Kubernetes 呢？好吧，这稍微难一些。你如何看待 KubeCon？它们又宣布了多少新项目？哪些是“真实的”呢？而你应该学习哪些？你对 Harbour、TikV、NATD、Vitess，开放策略代理有多深入的了解？更不用说 Envoy、eBPF 和 Linux 中的一系列底层技术？这就像是 1904 年工业革命爆发时建造翻斗车一样，你要弄清楚使用的螺钉、螺栓、金属和活塞。（有没有蒸汽朋克在这里吗？）

像翻斗车一样构造和配置 Kubernetes 是一个技术问题，如果你从事金融服务、零售、生物研究、食品服务等等，这可能不是你应该做的事情。但是，学习如何驾驶 Kubernetes 肯定是你应该学习的东西。

Kubernetes 就像一辆翻斗车，因其可以解决的各种技术问题（以及它所拖带的生态系统）而优雅。所以，我会给你一句引用的话，这是我的一位计算机科学教授在我大学的第一年告诉我们的，她说，“有一天，你会看到一段代码并对自己说，‘真特么优雅！’”

Kubernetes 很优雅。

via: https://opensource.com/article/19/6/kubernetes-dump-truck

作者：Scott McCarty 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

一旦公司越过了“让我们看看这些容器如何工作”的阶段，他们最终会在许多不同的地方运行容器

需要快速、高效地交付程序的公司 —— 而今天，哪些公司不需要这样做？—— 是那些正在转向 Linux 容器的公司。他们还发现，一旦公司越过了“让我们看看这些容器如何工作”的阶段，他们最终会在许多不同的地方运行容器。

Linux 容器技术不是新技术，但它随着最初由 Docker 发明的创新性打包格式（现在的 OCI 格式）以及新应用对持续开发和部署的需求开始变得流行。在 Red Hat 的 2016 年 5 月的 Forrester 研究中，有 48％ 的受访者表示已经在开发中使用容器，今年的数字预计将达到 53％。只有五分之一的受访者表示，他们在 2017 年不会在开发过程中利用容器。

像乐高积木一样，容器镜像可以轻松地重用代码和服务。每个容器镜像就像一个单独的、旨在做好一部分工作的乐高积木。它可能是数据库、数据存储、甚至预订服务或分析服务。通过单独包装每个组件，从而可以在不同的应用中使用。但是，如果没有某种程序定义（即 指令手册 instruction booklet ），则难以在不同环境中创建完整应用程序的副本。那就是容器编排的来由。

容器编排提供了像乐高系统这样的基础设施 —— 开发人员可以提供如何构建应用程序的简单说明。编排引擎将知道如何运行它。这使得可以轻松创建同一应用程序的多个副本，跨越开发人员电脑、CI/CD 系统，甚至生产数据中心和云提供商环境。

Linux 容器镜像允许公司在整个运行时环境（操作系统部件）中打包和隔离应用程序的构建块。在此基础上，通过容器编排，可以很容易地定义并运行所有的块，并一起构成完整的应用程序。一旦定义了完整的应用程序，它们就可以在不同的环境（开发、测试、生产等）之间移动，而不会破坏它们，且不改变它们的行为。

仔细调查容器

很明显，容器是有意义的，越来越多的公司像“对轮胎踹两脚”一样去研究容器。一开始，可能是一个开发人员使用一个容器工作，或是一组开发人员在使用多个容器。在后一种情况下，开发人员可能会随手编写一些代码来处理在容器部署超出单个实例之后快速出现的复杂性。

这一切都很好，毕竟他们是开发人员 —— 他们已经做到了。但即使在开发人员世界也会变得混乱，而且随手代码模式也没法跟着容器进入 QA 和生产环境下。

编排工具基本上做了两件事。首先，它们帮助开发人员定义他们的应用程序的表现 —— 一组用来构建应用程序实例的服务 —— 数据库、数据存储、Web 服务等。编排器帮助标准化应用程序的所有部分，在一起运行并彼此通信，我将这称之为标准化程序定义。其次，它们管理一个计算资源集群中启动、停止、升级和运行多个容器的过程，这在运行任何给定应用程序的多个副本时特别有用，例如持续集成 （CI） 和连续交付 （CD）。

想像一个公寓楼。居住在那里的每个人都有相同的街道地址，但每个人都有一个数字或字母或两者的组合，专门用来识别他或她。这是必要的，就像将正确的邮件和包裹交付给合适的租户一样。

同样，在容器中，只要你有两个容器或两个要运行这些容器的主机，你必须跟踪开发人员测试数据库连接或用户连接到正在运行的服务的位置。容器编排工具实质上有助于管理跨多个主机的容器的后勤。它们将生命周期管理功能扩展到由多个容器组成的完整应用程序，部署在一组机器上，从而允许用户将整个集群视为单个部署目标。

这真的很简单，又很复杂。编排工具提供了许多功能，从配置容器到识别和重新调度故障容器​​，将容器暴露给集群外的系统和服务，根据需要添加和删除容器等等。

虽然容器技术已经存在了一段时间，但容器编排工具只出现了几年。编排工具是 Google 从内部的高性能计算（HPC）和应用程序管理中吸取的经验教训开发的。在本质上，其要解决的就是在一堆服务器上运行一堆东西（批处理作业、服务等）。从那时起，编排工具已经进化到可以使公司能够战略性地利用容器。

一旦你的公司确定需要容器编排，下一步就是确定哪个平台对于业务是最有意义的。在评估容器编排时，请仔细查看（尤其）：

• 应用程序定义语言
• 现有能力集
• 添加新功能的速度
• 开源还是专有
• 社区健康度（成员的积极性/高效，成员提交的质量/数量，贡献者的个人和公司的多样性）
• 强化努力
• 参考架构
• 认证
• 产品化过程

有三个主要的容器编排平台，它们似乎领先于其他，每个都有自己的历史。

1. Docker Swarm： Swarm 是容器典范 Docker 的附件。Swarm 允许用户建立并管理 Docker 节点的集群为单个虚拟系统。Swarm 似乎正在成为一个单一供应商的项目。
2. Mesos： Mesos 是从 Apache 和高性能计算中成长起来的，因此是一个优秀的调度员。Mesos 的技术也非常先进，虽然与其他相比似乎没有发展速度或投资优势。
3. Kubernetes： 由 Google 开发，由其内部编排工具 Borg 经验而来，Kubernetes 被广泛使用，并拥有强大的社区。其实这是 GitHub 上排名第一的项目。Mesos 目前可能比 Kubernetes 略有技术优势，但是 Kubernetes 是一个快速发展的项目，这也是为了长期技术上的收益而进行的架构投资。在不久的将来，在技术能力上应该能赶超 Mesos。

编排的未来

展望未来，企业们可以期待看到编排工具在应用程序和服务为中心的方向上发展。因为在现实中，如今快速应用程序开发实际上是在快速地利用服务、代码和数据的组合。无论这些服务是开源的，还是由内部团队部署的抑或从云提供商处购买的，未来将会是两者的混合。由于今天的编排器也在处理应用程序定义方面的挑战，所以期望看到它们越来越多地应对外部服务的整合。

此时此刻，想要充分利用容器的公司必须利用容器编排。

（题图：Thinkstock）

via: https://www.infoworld.com/article/3205304/containers/orchestration-tools-enable-companies-to-fully-exploit-linux-container-technology.html

作者：Scott McCarty 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

你有没有问过自己，我应该在哪里运行 OpenShift？答案是任何地方 - 它可以在裸机、虚拟机、私有云或公共云中很好地运行。但是，这里有一些为什么人们正迁移到围绕全栈和资源消耗自动化相关的私有云和公有云的原因。传统的操作系统一直是关于硬件资源的展示和消耗 - 硬件提供资源，应用程序消耗它们，操作系统一直是交通警察。但传统的操作系统一直局限于单机 ^注1 。

那么，在原生云的世界里，现在意味着这个概念扩展到包括多个操作系统实例。这就是 OpenStack 和 OpenShift 所在。在原生云世界，虚拟机、存储卷和网段都成为动态配置的构建块。我们从这些构建块构建我们的应用程序。它们通常按小时或分钟付费，并在不再需要时被取消配置。但是，你需要将它们视为应用程序的动态配置能力。 OpenStack 在动态配置能力（展示）方面非常擅长，OpenShift 在动态配置应用程序（消费）方面做的很好，但是我们如何将它们结合在一起来提供一个动态的、高度可编程的多节点操作系统呢？

要理解这个，让我们来看看如果我们在传统的环境中安装 OpenShift 会发生什么 - 想像我们想要为开发者提供动态访问来创建新的应用程序，或者想象我们想要提供业务线，使其能够访问现有应用程序的新副本以满足合同义务。每个应用程序都需要访问持久存储。持久存储不是临时的，在传统的环境中，这通过提交一张工单实现。没关系，我们可以连到 OpenShift，每次需要存储时都会提交一张工单。存储管理员可以登录企业存储阵列并根据需要删除卷，然后将其移回 OpenShift 以满足应用程序。但这将是一个非常慢的手动过程，而且你可能会遇到存储管理员辞职。

在原生云的世界里，我们应该将其视为一个策略驱动的自动化流程。存储管理员变得更加战略性、设置策略、配额和服务级别（银、黄金等），但实际配置变得动态。

动态过程可扩展到多个应用程序 - 这可能是开发者测试的业务线甚至新应用程序。从 10 多个应用程序到 1000 个应用程序，动态配置提供原生云体验。

下面的演示视频展示了动态存储配置如何与 Red Hat OpenStack 平台（Cinder 卷）以及 Red Hat OpenShift 容器平台配合使用，但动态配置并不限于存储。想象一下，随着 OpenShift 的一个实例需要更多的容量、节点自动扩展的环境。想象一下，推送一个敏感的程序更改前，将网段划分为负载测试 OpenShift 的特定实例。这些是你为何需要动态配置 IT 构建块的原因。OpenStack 实际上是以 API 驱动的方式实现的。

OpenShift 和 OpenStack 一起更好地交付应用程序。OpenStack 动态提供资源，而 OpenShift 会动态地消耗它们。它们一起为你所有的容器和虚拟机需求提供灵活的原生云解决方案。

注1：高可用性集群和一些专门的操作系统在一定程度上弥合了这一差距，但在计算中通常是一个边缘情况。

via: https://blog.openshift.com/openshift-on-openstack-delivering-applications-better-together/

作者：SCOTT MCCARTY 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

某一天，我和我的一个机械工程师朋友聊天的时候。 他最近在做一个给半挂卡车的电子辅助刹车系统，他提到他们公司的办公室里都是 Arduinos。这主要是方便员工可以快速的对新的想法进行实验。他也提到了，Arduinos 其实比自己画电路板更加昂贵。对此，我感到非常震惊，因为我从软件行业得到的印象是 Arduinos 比定制电路板更加便宜。

我常常把 Arduinos 和 树莓派 看做是可以制作非常有趣设备的小型、Cool、特别的组件。我主要从事于软件行业，并且总是觉得运行在 x86 和 x86-64 设备上的 Linux 才算是“常规用途”。而事实是，Arduinos 并不是特殊用途。实际上，它们是很常规的用途。它们相当的小、便宜，而且非常的灵活。这就是为什么它们像野火一样流行起来的原因。它们有全品类的输入输出设备和扩展卡。它们能让创客们快速的构建非常 Cool 的设备。它们甚至可以让公司可以快速地开发产品。

一套 Arduino 的单价比批量生产的电路板高了很多，但是，看不见的时间成本却低了很多。当电路板大规模生产的时候，价格可以控制的很低，但是，之前的研发费用却高了很多。所以，总而言之，答案就是，使用 Arduino 划得来。

Unikernel、Rump 内核和容器主机

Unikernel、Rump 内核和迷你 Linux 发行版，这些操作系统是为了特有用途而构建的。这些特有的操作系统，某种程度上就像定制电路板。它们需要前期的投入，还需要设计，但是，当大规模部署的时候，它可以提供强大的性能。

迷你操作系统，例如：红帽企业版 Atomic 或者 CoreOS 是为了运行容器而构建的。它们很小，快速，易于在启动时配置，并且很适合于运行容器。缺点就是它需要额外的工程量来添加第三方插件，比如监控客户端或者虚拟化的工具。副作用就是载入的工具也需要重新设计为超级权限的容器。 如果你正在构建一个巨大的容器环境，这些额外的工作量是划算的。但是，如果只是想尝试下容器，那可能就没必要了。

容器提供了运行标准化的工作流程（比如使用 glibc 编译）的能力。一个好处就是你可以在你的电脑上构建和测试这个工作单元（Docker 镜像）并且在完全不同的硬件上或者云端非常顺利的部署，而保持着相同的特性。在生产环境中，容器的宿主机仍然由运维团队进行配置管理，但是应用被开发团队控制。这就是对双方来说最好的合作方式。

Unikernels 和 Rump 内核依旧是为了特定目标构建的，但是却更进一步。整个的操作系统在构建的时候就被开发或者架构师配置好了。这带来了好处，同时还有挑战。

一个好处就是，开发人员可以控制这个工作流程的运转。理论上说，一个开发者可以为了不同的特性，尝试 不同的 TCP 协议栈，并且选择最好的一个。在操作系统启动的时候，开发人也可以配置 IP 地址，而不是通过 DHCP。 开发人员也可以裁剪任何对于应用而言不需要的部分。这也是性能提升的保障，因为减少了不必要的上下文切换。

同时，Unikernel 也带来了挑战。目前，还缺失很多的工具。 现在，和画板子的世界类似，开发人员需要花费很多时间和精力在检查是否有完整的库文件存在，不然的话，他们必须改变他们应用的执行方式。在如何让这个“嵌入式”的操作系统在运行时配置的方面，也存在挑战。最后，每次操作系统的大改动，都需要反馈到开发人员来进行修改。这并没有一个在开发和运维之间明确的界限，所以我能想象，为了接受了这个开发流程，一些组织或者公司必须要改变。

结论

在专门的容器主机比如 Rump 内核和 Unikernel 方面也有一些有趣的传闻，因为，它们会带来一个特定工作流程的潜在变革（嵌入式、云，等等）。在这个令人激动又快速发展的领域请保持你的关注，但是也要谨慎。

目前，Unikernel 看起来和定制电路板很像。它们都需要前期的研发投资，并且都是非常独特的，可以为确定的工作流程带来好处。同时，容器甚至在常规的工作流中都非常有趣，而且它不需要那么多的投入。一个简单的例子，运维团队能方便的在容器上部署一个应用，但是在 Unikernel 上部署一个应用则需要重新设计和编码，而且业界并不能完全保证，这个工作流程就可以被部署在 Unikernel 上。

容器，Rump 内核 和 Unikernel 有一个光明的未来！

via: https://opensource.com/business/16/5/containers-unikernels-learn-arduino-raspberry-pi

作者：Scott McCarty 译者：MikeCoder 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

从根本上说，几乎所有的主要软件，即使是开源软件，都是在基于镜像的容器技术出现之前设计的。这意味着把软件放到容器中相当于是一次平台移植。这也意味着一些程序可以很容易就迁移，而另一些就更困难。

我大约在三年半前开展基于镜像的容器相关工作。到目前为止，我已经容器化了大量应用。我了解到什么是现实情况，什么是迷信。今天，我想简要介绍一下 Linux 容器是如何设计的，以及谈谈镜像签名。

Linux 容器是如何设计的

对于基于镜像的 Linux 容器，让大多数人感到困惑的是，它把操作系统分割成两个部分：内核空间与用户空间。在传统操作系统中，内核运行在硬件上，你无法直接与其交互。用户空间才是你真正能交互的，这包括所有你可以通过文件浏览器或者运行ls命令能看到的文件、类库、程序。当你使用ifconfig命令调整 IP 地址时，你实际上正在借助用户空间的程序来使内核根据 TCP 协议栈改变。这点经常让没有研究过 Linux/Unix 基础的人大吃一惊。

过去，用户空间中的类库支持了与内核交互的程序（比如 ifconfig、sysctl、tuned-adm）以及如网络服务器和数据库之类的面向用户的程序。这些所有的东西都堆积在一个单一的文件系统结构中。用户可以在 /sbin 或者 /lib 文件夹中找到所有操作系统本身支持的程序和类库，或者可以在 /usr/sbin 或 /usr/lib 文件夹中找到所有面向用户的程序或类库（参阅文件系统层次结构标准）。这个模型的问题在于操作系统程序和业务支持程序没有绝对的隔离。/usr/bin 中的程序可能依赖 /lib 中的类库。如果一个应用所有者需要改变一些东西，就很有可能破坏操作系统。相反地，如果负责安全更新的团队需要改变一个类库，就（常常）有可能破坏面向业务的应用。这真是一团糟。

借助基于镜像的容器，比如 Docker、LXD、RKT，应用程序所有者可以打包和调整所有放在 /sbin、/lib、/usr/bin 和 /usr/lib 中的依赖部分，而不用担心破坏底层操作系统。本质上讲，容器技术再次干净地将操作系统隔离为两部分：内核空间与用户空间。现在开发人员和运维人员可以分别独立地更新各自的东西。

然而还是有些令人困扰的地方。通常，每个应用所有者（或开发者）并不想负责更新这些应用依赖：像 openssl、glibc，或很底层的基础组件，比如，XML 解析器、JVM，再或者处理与性能相关的设置。过去，这些问题都委托给运维团队来处理。由于我们在容器中打包了很多依赖，对于很多组织来讲，对容器内的所有东西负责仍是个严峻的问题。

迁移现有应用到 Linux 容器

把应用放到容器中算得上是平台移植，我准备突出介绍究竟是什么让移植某些应用到容器当中这么困难。

（通过容器，）开发者现在对 /sbin 、/lib、 /usr/bin、 /usr/lib 中的内容有完全的控制权。但是，他们面临的挑战是，他们仍需要将数据和配置放到 /etc 或者 /var/lib 文件夹中。对于基于镜像的容器来说，这是一个糟糕的想法。我们真正需要的是代码、配置以及数据的隔离。我们希望开发者把代码放在容器当中，而数据和配置通过不同的环境（比如，开发、测试或生产环境）来获得。

这意味着我们（或者说平台）在实例化容器时，需要挂载 /etc 或 /var/lib 中的一些文件或文件夹。这会允许我们到处移动容器并仍能从环境中获得数据和配置。听起来很酷吧？这里有个问题，我们需要能够干净地隔离配置和数据。很多现代开源软件比如 Apache、MySQL、MongoDB、Nginx 默认就这么做了。但很多自产的、历史遗留的、或专有程序并未默认这么设计。对于很多组织来讲，这是主要的痛点。对于开发者来讲的最佳实践是，开始架构新的应用，移植遗留代码，以完成配置和数据的完全隔离。

镜像签名简介

信任机制是容器的重要议题。容器镜像签名允许用户添加数字指纹到镜像中。这个指纹随后可被加密算法测试验证。这使得容器镜像的用户可以验证其来源并信任。

容器社区经常使用“容器镜像”这个词组，但这个命名方法会让人相当困惑。Docker、LXD 和 RKT 推行获取远程文件来当作容器运行这样的概念。这些技术各自通过不同的方式处理容器镜像。LXD 用单独的一层来获取单独一个容器，而 Docker 和 RKT 使用基于开放容器镜像（OCI）格式，可由多层组成。糟糕的是，会出现不同团队和组织对容器镜像中的不同层负责的情况。容器镜像概念下隐含的是容器镜像格式的概念。拥有标准的镜像格式比如 OCI 会让容器生态系统围绕着镜像扫描、签名，和在不同云服务提供商间转移而繁荣发展。

现在谈到签名了。

容器存在一个问题，我们把一堆代码、二进制文件和类库放入其中。一旦我们打包了代码，我们就要把它和必要的文件服务器（注册服务器）共享。代码只要被共享，它基本上就是不具名的，缺少某种密文签名。更糟糕的是，容器镜像经常由不同人或团队控制的各个镜像层组成。每个团队都需要能够检查上一个团队的工作，增加他们自己的工作内容，并在上面添加他们自己的批准印记。然后他们需要继续把工作交给下个团队。

（由很多镜像组成的）容器镜像的最终用户需要检查监管链。他们需要验证每个往其中添加文件的团队的可信度。对于最终用户而言，对容器镜像中的每一层都有信心是极其重要的。

作者 Scott McCarty 于 8 月 24 日在 ContainerCon 会议上作了题为 Containers for Grownups: Migrating Traditional & Existing Applications 的报告，更多内容请参阅报告幻灯片。

via: https://opensource.com/bus/16/8/introduction-linux-containers-and-image-signing

作者：Scott McCarty 译者：Tanete 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出