容器集群稳定性
容器以多种方式移动目标。 凭借多种工具，框架，实现和用例来完成任何任务，这可能是一个快速发展的混乱的容器世界，这是年轻和流行的自然结果。
好消息是，所有这种创造性的孵化都非常有生产力，而且由于它是开源的，每个人都可以分享所有这些奇妙的创造性的好处。 坏消息是，这是一个充满活力的巨大猫群。 我们如何知道该朝哪个方向前进？ 我们是否必须计划要在几个月后过时的今天的工作？ 而且，可移植性如何？
我想提供一些关于容器的未来的见解，以及我们可以期望的最先进技术的发展方向。
容器标准已成为一种正式的对话，是一种政治对话。 但是，目前在此方面的进展更加标准化和可支配，并且围绕所有相关人员之间的交互具有一些正式规则。 在过去的几年或至少三年之前，唯一的标准是配置文件上的任何给定工具或实现方法。
Systemd有自己的做它的方式nspawn ，和Linux的容器（LXC）有自己的做它的LXC的方式。 他们与该工具有自己的交互性，但是当它涉及到这个问题时，很多人都在问（“我如何开始使用容器？”），您只需自己动手制作。 根本没有分配图像的想法。 您只需要自己弄清楚，自己搞定工作即可。
然后Docker出现并引起了人们的关注。 Docker带给桌面的一件事实际上是一个新的元软件包。 许多人已经熟悉RPM和Debian软件包，然后熟悉Java应用程序的JAR文件，Ruby gems和NPM节点软件包等等。 但是，他们希望将所有内容放在一起，这是一个容器映像，就像一个大型的汇总元数据包。 然后，开发人员想要分发此元软件包。
在过去的一两年中，曾经有一种基于人们对Docker厌倦的非正式标准，现在他们正在构建这些Docker软件包，并希望以不同的方式进行部署，因此他们需要弄清楚它们的使用方式案件。 由于此方法受到关注，因此已成为非正式标准。
看到人们在哪里标准化很有趣，看到一些相互竞争的标准也很酷。 例如，在网络空间，还有多克的集装箱联网模式（CNM），然后有另外一个叫CNI的集装箱网络接口 。 他们采用不同的方式来解决一些类似的问题，但是人们选择使用一种解决另一种使用情况。 尽管Kubernetes编排在Docker的基础上进行了大量构建，但最终还是围绕Docker的CNM模型工作并采用了CNI网络规范。
另一个新兴标准是Open Container的运行时规范和Open Container的映像规范。 运行时规范的主要用例是必须具有用于启动容器的已定义调用模型。 一些用例只需要运行命令，并让所有的麻烦都由更高层次来处理。 运行时规范的参考实现是runC 。 即使在Red Hat，runC也被用于早期启动容器。 在启动Docker守护程序之前，甚至可能需要完成一些工作。
这些容器仍然需要分发给主机，这是OCI映像规范的所在。用于分发容器映像的已定义布局，您可以在其中选择签名和联合以及在各种工具之间移植容器映像。 有诸如skopeo之类的工具可以促进推，拉和签名，并在OCI和docker之间具有互操作性。 rkt的最新版本现在也支持OCI映像。
随着标准的发展，我们已经有了竞争的标准。 在OCI之前，有一个appc规范 ，涵盖了分发，图像分配，运行时以及图像本身。 尽管开放容器倡议仅涉及appc的几个方面。 但是我们两者之间确实存在很多异花授粉。 每个维护者都在为另一个规范做出贡献，OCI上有来自appc的维护者，反之亦然。
基本上，一种工具并不适合所有工具。 人们会有不同的用例。 这就是为什么您看到有些人甚至拥有runC类型的工具来运行微型管理程序（ runv ）的原因。 现在，容器不仅仅是一个容器，它实际上是一个虚拟机（VM）。 但是您所提供的只是一个根文件系统，然后它可以运行具有相同布局的小型VM。 图像规范仅具有您可能内置的互操作性。
您可以选择Docker， Rocket ，LXC，runC甚至是sytemd-nspawn…或其他一些非root容器的容器工具，例如bubblewrap 。 在处理用例时，仍然可以具有相同文件系统的可移植性。 您可以具有该文件系统的可移植性并分配该文件系统。 然后选择最适合您的用例的工具。
通过这种方式，标准非常重要。
我们已经看到开发人员在过去一两年中取得了长足的进步。 尽管下一个范式转变将很快发生。
当前，开发人员正在将他们熟悉和熟悉的应用程序放入一个容器中。 然后，他们提出了许多与VM有关的问题。 我觉得下一轮开发者不仅会把现有软件塞进盒子里，而是会在考虑容器概念和基础的情况下编写或重写现有软件或新软件，这将使他们更加了解这些限制。他们的应用程序给出了什么。 这将是一个有趣的空间，因为对于某些人来说，这可能是非常令人兴奋的，他们从未陷入内核级别。 而且他们并不真正在乎功能，seccomp，系统调用，SELinux，AppArmor以及所有这些东西。 他们只想把它塞进盒子里然后运行。 他们可能仍在考虑虚拟机。
但是开发人员的下一个迭代版本将需要更加意识到以下事实，即当他们的应用程序投入生产时，他们将不会在主机上拥有根目录。 他们在运行它的计算机上没有打开权限； Capabilites是受限制的。 他们应该为自己的软件假设最狭窄的世界。
使开发人员能够看到，访问该应用程序并对其应用程序进行配置非常重要，因为即使您正在编写一些高级Ruby或Python Web应用程序，也需要知道该应用程序实际要求的功能或系统调用。 您的块I / O或网络I / O行为在哪里？ 这些都是很好的问题。 这将在容器世界中产生很大的不同，因为您的应用程序可能会立即投入到在受限环境下运行的基础结构中，然后您会陷入不确定的行为中，这可能很难调试。
我觉得开发人员考虑编写软件的方式将会发生变化。 例如，当他们考虑是否需要MySQL时。 也许他们只需要其中的某些方面。 数据库可能开始更改。 人们编写和思考应用程序的方式正在开始改变。 将会有更多的工具可以使您更轻松地看到此类内容。
而且，不仅是标准，还将成为工具。 一旦有了标准，各种工具基础结构（例如调试和工具）将具有非常一致的期望。 就像在映像的可移植性或映像的运行时一样，他们可以在映像的基础上构建。 只要这是一个不断变化的目标，大多数人都会坐下来等到事情变得更加稳定。 这对开发人员来说非常重要。 他们喜欢它的热，他们喜欢它的快速，但他们也不想调试数周的未定义行为。
每个人都在关注的最大问题是如何最好地对冲碎片化。 不幸的是，随着容器的流行，快速移动和发展，容器具有蔓延，冲突和碎片化的机会均等，而没有人需要。 只要人们正在解决特定的用例，并且能够适应所有使用中的不同用例，容器中就会有很多很棒的东西。
不利的一面是没有竞争标准。 这是一个古老的事物，其中您对某件事有两个实现，而又没有一个完全解决它，因此您进行了第三个实现。 现在您有三个问题。 这是有道理的，因为如果前两个不能解决所有需要的用例，那么显然还需要其他一些用例。 因此，公正而友善地做到这一点将是最大的持续挑战，因为我们都是人。
Vincent Batts 在安大略省多伦多举行的LinuxCon + ContainerCon North America 2016上发表演讲。 他以前的几场会议演讲都可以在YouTube上找到：
无论如何，我们在容器中想要什么？
通用容器标准-过去，现在和将来
Docker在5分钟内
Vincent Batts在奥斯汀OSCON上的采访
Docker：贡献与协作101
翻译自: https://opensource.com/business/16/8/inside-look-future-linux-containers
容器集群稳定性
