数据中心架构，未来谁将主导容器技术？

    未来的数据中心架构，谁将主导容器的编排与控制，Mesos还是Kubernetes？答案可能两者都不是。这一领域还远未发展成熟，由其是在责任分工或替代方法方面仍有很多其他的选择在不断进化。

 

    消费者面临的挑战是，所有这些工具都是并行推进且各自独立发展，而随着市场逐渐趋于适应该领域的业务需求，各项工具的主导企业为寻求收入来保持竞争，现在出现了一些趋同。这是一个活跃的，迅猛发展的领域。

 

    希望这篇文章能够阐述2017年数据中心架构领域存在的各种责任层面，可能应用它们的不同方式，以及各自如何演进。

 

    数据中心架构领域能够提供给开发人员的开发方案，当前业界存在6种：

 

    1.Bare metal machines (PXE)

 

    2.Workload jobs/tasks (HPC clouds)

 

    3.VMs (elastic compute clouds)

 

    4.Containers (container schedulers & runtimes)

 

    5.Applications or Microservices (cloud native platforms)

 

    6.Functions (serverless clouds)

 

    大多数数据中心架构都会同时采用多种方案来应对其特定的需求。下面我们从下到上逐个分析：

 

 

    在新一代的数据中心里，容器应该运行在何处？这里有两种竞争方案：通过裸机PXE驱动，如pxelinux， kickstart， cobbler， Crowbar， OpenStack Ironic， RackHD；通过运行在基础设施云（IaaS）上的VM驱动，常见IaaS包括AWS， GCE， Azure， vSphere， OpenStack， VMware Photon Controller。

 

 

    尽管存在CoreOS的容器镜像格式ACI，Docker已经成为容器镜像格式的事实标准。运行时方面，大多数人认同使用Open Container Initiative（OCI）的runC作为底层CLI和库来运行容器。Docker使用名为containerd的runC实现作为守护进程。更高级别的运行时包括Docker引擎，由CoreOS rkt领导的appC系列和Cloud Foundry的Garden，它支持Droplets，Docker镜像和Windows容器。微软自己在Windows 2016中发布了部分基于Docker技术的Windows容器。

 

 

    容器操作系统的先驱者是CoreOS，现还有陆续出现的rancherVM，Photon Machine和vSphere Integrated Containers，所有这些都可以直接为容器提供硬件层的VM隔离。有迹象表明，微软也将使用HyperV为容器直接提供硬件层的隔离。未来真的会是裸机上的Linux内核吗？敬请关注。

 

 

    所有这些基础架构都具有要管理和配置的服务器/网络/存储，并且容器位于这些基础设施之上。这种方案距离真正解决问题还很远。下一代的基础架构中比较突出的是Hashicorp生态系统（Vagrant，Terraform，Consul等），它们结合的非常好。Cloud Foundry的BOSH在多云和基础架构控制器方面也表现优异，拥有独特的封装，编译，一次性虚拟机和发布管理理念。Docker Machine也在这个领域不断发展。当然，还有Puppet， Chef， RedHat Ansible， 和/或 SaltStack，以及来自BMC（Bladelogic和RLM），CA（App Deployment Automation）和IBM（UrbanCode）的专有产品。

 

 

    现在看看我们如何运行一些实际的工作负载。假设我们有几种不同的需要在一组服务器上运行统一工作负载（Batch批处理，Database数据库，文件系统等）。这些工作负载可能在或可能不在容器中，并且它们可能不包含需要传统无状态横向扩展的冗余复制服务。特别是，它们可能是文件系统和数据库等有状态的服务，因此不能对它们做出太多的假设。如何部署和管理这些工作负载的生命周期（启动/停止）？主导这一领域的是Apache Mesos / Mesosphere DCOS，尽管还有Hadoop的YARN。这里的关键是你必须构建自己的应用调度程序来使用这些框架，如Hadoop，Spark，Cassandra等。如果你想要通用的横向工作负载扩展方案，你实际上想跳到容器调度（Cointainer Scheduler，下面的＃7），并考虑Mesos自己的容器调度框架，称为Marathon。

 

    这个层面，关于这些调度框架是否是一切的新基础，是业界热门的辩论领域。例如Mesosphere所营销的“数据中心操作系统”是否适合Hadoop集群，Spark集群，Twitter或Google这类的大型网站等大型统一的工作负载。CoreOS看上去更符合要求，“你需要的只有＃1，2，3，4和6，然后运行构造（Kubernetes）＃7”！Mesos是谷歌或苹果Siri所代表的“反对HPC集群阵营”中的领导者，这使得裸机再次变得酷炫，而虚拟化则不再是必要的。

 

    因此，当你想要依赖裸机而不希望重新PXE机器来交换工作负载时，Mesos成为无需烧脑的选择。从另一个角度看待这个问题，那就是Mesos的魅力取决于你的基础架构管理（＃4）的好坏。如果你真的讨厌配置管理和设施供给，并希望尽量减少使用，Mesos会变得有趣。如果你喜欢你的基础架构协调，就像你梦想着Chef recipes的精彩，或喜欢观看BOSH分析其自动化部署计划的方式，Mesos的存在就不那么有趣了。

 

 

    唷！最终我们还是在使用容器。那么，如果我不想运行统一的工作负载呢，我只想管理几个容器编排的混合工作负载呢？这就有了Docker Compose，CoreOS Fleet，Mesos Chronos或systemd-nspawn的用武之地。这里的重点是在几台机器上管理简单或定制的过程和/或容器生命周期，而不是下述容器调度器所管理的更统一的“横向扩展”的容器生命周期。

 

 

    更常见的情况，业内关注的重点是如何管理承载于容器内的服务工作负载的负载平衡，横向扩展，可恢复性，并且能够根据需要为工作负载附加存储或网络或其他服务。这就是Kubernetes或Cloud Foundry的Diego所擅长的，还有像Hashicorp Nomad，Docker Swarm，或者Mesosphere的Marathon这样的新秀。在当前容器调度热潮中，向天空扔一块石头，掉下来很可能就会击中2个或3个容器调度器。

 

 

    需要一个面向技术的GUI来管理#6和#7？这就是Shipyard， Docker的 Universal Control Plane，和 Tutum占据的地盘。

 

 

    使用容器时需要我们来构建，维护，存储和分发它们。当你有多个层级和团队时，它不像“Dockerfile＆go”看起来那么简单。上述的大多数容器调度程序都需要某种Docker兼容的存储仓库，因此Cloud Foundry配备了自己的虚拟机和容器Blobstore来辅助Docker应用。Hashicorp的Packer帮助重复创建虚拟机和容器，如同Cloud Foundry的Buildpacks或OpenShift的S2I。CoreOS的Quay是Docker容器构建器和仓库，与Docker的Trusted Registry竞争，尽管后者可以下载，而不仅仅是一个云产品。Concourse CI是一个以容器为中心的持续整合/交付系统，在通过容器组装构建任务方面也很强大。

 

 

    对许多容器系统来说这是一个正在推进的工作，这不是很成熟，但2017年将是至关重要的阶段。这里的关键是为容器启用可恢复的动态调度的持久卷，以便有状态的横向扩展容器工作负载。传统的Docker卷只能绑定到单个主机，即需要卷的容器随主机一起存在或死亡；除非你愿意丢失数据，否则无法迁移它们。

 

    可以像主机上的容器一样在集群内和跨集群快速无缝地迁移，是持久卷需要面对的一个难题。传统的横向扩展工作负载主要针对无状态服务，并将状态管理职责转移到不同的层，例如横向扩展的NoSQL数据库（BigTable，HBase，Cassandra，Riak，Geode / GemFire等），集群文件系统（例如Ceph或GlusterFS）或传统的基础架构/配置管理器方法。这需要容器调度器的一致性调度，例如， Kubernetes的状态集（Stateful Sets）。今天，Kubernetes拥有可插拔的卷管理方法，类似Docker的卷驱动程序。Cloud Foundry Diego的持久卷驱动程序以组合的方式，使用Open Service Broker API来配置卷本身，使用Docker卷驱动程序API来管理容器内的卷生命周期。