容器化近年来备受关注，围绕着容器技术很多不同的项目也降生了。这些项目中的一类就触及到容器编排。以后已出现了许多不同的方案，针对云专有的处置方案，例如Amazon ECS，开源的处置方案有如Kubernetes。这些方案都有一个相反的目的，那就是使容器编排更复杂。但是，这些工具所提供的真的如它们所宣称那样，管理更复杂，部署更复杂吗?

在本文中，我们先简明议论下容器化概念，前面我将运用两种不同的编排办法来部署一个AI-API架构，一个包含复杂API的AI聊天机器人。一种是运用Kubernetes，另外一种是只运用基于容器的手动控制管理平面。

容器与虚拟机

在AWS末尾在云上提供虚拟机(VM)后，全球大少数效劳器部署如今都在运用某类虚拟化系统。假设你一直可以100%应用资源的话，那么在价钱与功用方面，虚拟机往往愈加昂贵。假定你是购置基于它们构建的收费效劳层的话，例如RDS，它们如今能更容易，更快地部署，更易于管理并且需求的维护更少。就像物理效劳器和虚拟机之间的差异一样，容器化使得管理和部署效劳器或效劳变得愈加容易。

虽然虚拟机可以共享物理资源，但它们必须在其之上引入本人的操作系统，当然包括内核。虽然这能创立一个理想的隔离环境，但它也会产生本人的成绩，例如运转多个内核和操作系统时糜费的资源以及出于安全缘由的更新和维护。容器化就是经过应用内核命名空间创立具有本人的文件系统的隔离任务区。因此仅运用一个操作系统并共享相反的内核，来运转多个(效劳器)运用顺序，这就是容器的意义所在。

容器同时也具有分层镜像的功用，虽然虚拟机处置方案中也存在这样的东西，但它没有像容器那样充沛应用。大少数运用顺序有时需求数小时才能构建和安装，而一个运用顺序镜像甚至可以在几秒钟内下载并运转。假设你需求运转容器化的WordPress安装，那么你需求运转Docker来运转WordPress。容器镜像可以缓存无需屡次重复下载。

接上去我们末尾讨论容器编排。

容器编排

创立和管理容器的便捷性使许多自动化任务流程得以完成。在最后，一切基于容器的部署都运用一些专有技术栈来编排和运转它们。但是在Docker开源并末尾统治该范围之后，它逐渐成为运转容器的标准，因此Docker镜像也逐渐成为分发容器镜像的标准方式。所以很多关于自定义编排的项目出现时都会以Docker为基础。

下图是我想要创立的第一种编排类型。但我需求处置的一个很重要的成绩就是启动时间。我们的软件启动时间很长，所以我们希望一直有一个效劳处于就绪形状可以效劳于每个央求。在我的架构中，我希望有一个控制器容器可以在我预备新的容器时作为负载平衡器以及HTTP效劳器将央求转发到正确的AI容器去。

我运用docker-py库来完成这项任务，并运用了flask来提供HTTP央求。Docker.py库有着很好的文档而且很容易运用，只需为控制器和AI运用辨别创立了一个Dockerfile。这个进程很复杂，在开发进程中我学到了更多关于Docker的知识。虽然这是我创立的一个十分原始的专有容器编排处置方案，但它总算完成本人的使命。

好了，接上去是时分引见下Kubernetes了，由于基本上它为编排提供了相似的目的，我曾经创立了基于Kubernetes的处置方案来增加需求编写的代码量。

为了在Kubernetes中运用相反的思绪，我不得不从一末尾就重新思索我的架构。由于Kubernetes仅仅只需求你提供一个部署的形式(像Amazon ECS那样)并尝试将该形式保持在波动形状。当我为下次央求创立本人的容器时，编排系统应该能适时在相似这样的进程中预备或是处置一些事情，经过一番搜索，我发现可以运用Kubernetes的标签功用来完成我的顺序。

我的想法是将一切新创立的AI容器打上assigned:not_assigned的标签，使之运用到每个容器。我需求声明，我想要其中3个包含标签assigned:not_assigned。当新央求到来时，我的控制器容器应该将此标签更改为assigned:assigned。更改标签会惹起形状改动，3个已部署容器中的2个将会带有assigned:not_assigned的标签。当Kubernetes察看到形状被变更时，它将用assigned:not_assigned标签启动另一个新的容器。

因此，只是为了管理Kubernetes集群，我又编写了另一个类。它实践上并不需求完成如创立或管理容器的某些功用，但它需求能转发央求并删除标签。完成这个任务删除了少量代码，可想而知维护的代码行数量也增加了，这意味着攻击面更小了。在Pod中创立与Kubernetes主机的衔接十分复杂。尔后我又花了一些时间来创立效劳并将央求路由到正确的容器。

结论

在这个实验中，我尝试运用现成的容器编排处置方案和我本人编写的编排工具。编写我本人的编排处置方案很快，其中的概念并不生疏，并且会有很多文章指点如何去做。但是当切换到Kubernetes时，一切都变了。为了可以运用Kubernetes，关于容器的知识是不够的，我必须学习新的概念和一种新的思想方式以便可以按我的需求来运用它，例如在Kubernetes中部署和效劳作为第一公民，而不是容器。但最后，我们可以担忧肠假定，运用Kubernetes停止容器编排能使我的架构更安全，更波动，由于我的软件中的大少数复杂的部分，例如维持波动数量的容器，这些都是在Google运用并推行的一个开源项目的协助下完成的。

【编辑引荐】

为什么说无效劳器是2018年构建API的独一之道？

开发者都应该知道的15个API

再谈前后端API签名安全？

(责任编辑：admin)