Kubernetes已经成为容器编排系统的事实标准，是现在主流的跨云容器化应用操作系统。但是，Kubernetes的目标并不是容器本身，而是承载其上的应用，本质上是为了解决（容器化）应用上云这个难题。容器和K8s的出现， 提供了一套统一的抽象核心，使得围绕他们实现多云业务成为可能。

那么，非容器化应用怎么办？

本篇将告诉你，K8s不管的，我们怎么管：容器化应用怎么跑多云？我们从K8s学到了三个大招非容器化应用怎么跑多云？多云环境下，如果某些云出现不可抗拒性故障时，对上层企业应用有多少影响？

非容器化应用，即不支持容器化的应用，既包括了Legacy APP，也包括那些因为商业原因不支持容器化的应用，比如很多传统HPC应用。我们面向的像生命科学／半导体／汽车制造这些行业用户很多时候使用的就是非容器化应用。

       基于本地＋多云的系统架构，大致分为以下四个层面：应用层，业务调度层，资源配置层，云提供商层。

云提供商提供的是底层基础设施和资源。资源配置层是把云提供商的资源进行集群化管理，再进一步池化，抽象，变成一个动态的池子。因为我们的用户的需求不是一个恒定的值，是有波动的，有时候短期内会有很大的需求，但除了这些时间之外，大部分时候没有那么大需求，所以我们需要动态管理／动态申请云资源的抽象。业务调度层解决的问题是怎么把应用把跑在我们抽象好的这些资源上面，跑在哪里，怎么跑，这些问题。

1

容器化应用怎么跑多云

对于容器化应用来说：
K8s解决了业务调度这一层，怎么把应用跑在我们配置的环境上面，容器化应用提供了统一的调度对象。因为K8s有一个统一的抽象了，所以你可以把K8s部署在不同的云上面，通过统一的管理方式，实现多云的工作负载分配。

但是K8s没有解决的问题是，怎么构建各个云上的K8s集群。虽然说CNCF（云原生计算基金会）社区里有很多各种各样的工具，比如说像terraform，可以帮助用户构建集群，但是毕竟它是一个独立的工具，难免会增加用户的学习成本。而且，你如果想要控制某一个workload，动态地申请这些资源，就得自己去开发定制这些额外的东西。对用户来说，这些都是实现多云的阻碍。  

2

我们从K8s学到了三个大招

统一的抽象层通过抽象统一的控制界面（API），可以屏蔽掉底层的区别，来管理不同的云上类似的资源。用户不需要直接接触使用底层的资源，我们可以根据这个抽象来提供更可扩展的stack。 声明式的基础架构描述方式利用抽象出来的控制界面，统一描述云上互相关联的计算资源，而这同一套描述可以应用在不同的云上。K8s描述的是一个状态，我们觉得这是一个很好的东西。为什么呢？因为声明式的构架描述的是状态，所以把怎么样达到这个状态这件事情，交给了平台本身，我们就可以根据现在平台的状态以及这些资源的状态，比如说价格这些方面来调配我们怎么样去达到这个状态。 自动化管理利用API，大多数的业务流程可以实现自动化，减少维护人员负担。例如根据业务的规模和用户指定的策略，动态地伸缩集群规模，实现最大化地利用资源。对于一些可被替换的计算实例，同时可实现自动化替换和计算恢复等。

3

非容器化应用怎么跑多云？

我们要解决的核心需求是：对于不适合容器化的应用，我们也可以采用声明的方式定义资源需求和运行方式，在不改变应用内部逻辑的情况下，将应用运行在多云的环境中。用户在使用这些应用的时候会有一个顺序，比如说先跑某个应用，然后产生了一些中间数据，中间数据会被喂给下一级的应用，被下一级的应用消耗，以这样的工作流达到最终他要的目的。这个流程就变成我们用来调度和抽象，分配这些应用的点。 我们的系统里面设计了五个主要的组件：云服务抽象层统一集群描述系统智能策略调度系统工作流引擎分布式文件缓存系统

云服务抽象Serverless层

云抽象层把每个云上面常用的一些组件，比如说像instance虚机，网络，镜像，子网、防火墙，对这些常见的功能我们做了抽象。将所有的云资源，不管是本地还是公有的，变为一个大的资源池。并且能够把功能和资源拆分开，利用下层的异构的多云的计算资源，动态地为用户提供服务。对于每种资源的操作，转换为对应云提供商API的操作。

这个抽象层还可以帮助我们实现一些有的云有，有的云没有的功能。比如AWS现在有一个Spot Fleet的功能，你可以告诉它我需要多少台机器，什么样的机器，然后你可以在一个范围里去选择。这个功能我们在阿里云或者其他云上没有见到，现在我们可以通过抽象来自己实现这样一个功能。很可惜，不是所有的云资源都能通过这样统一的抽象，特别是一些高端的资源，比如AWS Lambda这种我们就没法抽象。因为它是利用了底层资源做了一个更高级别的优化，或者说是更高级别的简化而形成的，在不同的云上是不一样的，有些云可能没有。 统一集群描述系统我们学习了K8s，在这个基础上提供了一个统一的基础架构描述系统，通过声明式描述来定义基础架构。简单来说，你要的这些虚机或者是这些虚机之间的关系是怎么样去定义的。像Hashicorp提供的terraform就提出“infrastructure as code”，架构即代码。我们也用了这个理念，好处是你能够明确看到你的架构是什么样的，并且你可以描述这个状态。比如说你在一个云上面定义并实现了这样一个架构，你就可以把它搬到另一个云上去，而且不会出错。实现“Write once， run anywhere”的跨云浮动。

智能策略调度系统有了前面两个作为基础，我们就可以实现根据用户偏好的智能调度。前面我们提过我们的集群是一个动态的集群，是可以根据某种策略或者云上的状态来决定这些业务跑在哪里的一个过程，所以我们有一个智能调度策略系统，它会根据用户的输入，这个数据有多大，用户的偏好是什么来进行调度。如果用户偏好是成本，可以接受一定程度上的慢。我们就可以找一些便宜的资源，比如像AWS的Spot instance（spot是我们可以以很低的价格来使用的资源），但这种资源并不保证一直都有。如果用户选择了这样的偏好，我们系统会在一定程度上去等这个资源，当这个资源有的时候我们去跑，可以在晚上，或者有资源的时候再跑这个任务。如果用户非常希望很快地把结果算出来，我们可以调动云上我们可以申请得到的最快的资源来帮用户把这个事情给计算出来。 工作流引擎通常，用户在使用他们的应用的时候会有一个工作流程。比如第一步使用什么程序，第二步使用什么程序。我们在系统里集成了一个工作流引擎，用户可以通过图形化的方式来编辑这个工作流。而且系统里已经预装了一些常见的流程，支持顺序地执行任务。不同的步骤有不同的特点。比如有些步骤可能需要很多节点同时来执行一些任务，并发量比较大，有些步骤可能没有那么大。我们可以根据这个工作流来调整我们的集群规模，这样也可以帮用户节省成本。

分布式文件缓存系统

这是一个比较重要的点：数据访问。一个程序或者一个应用是不能单独完成工作的，肯定需要数据。传统应用大部分是设计在Linux／UNIX上面的，用户可以直接通过文件的方式访问这些数据的。

所以我们需要两点：一、有一个直接访问数据的方式，并且把数据访问构建在多云上面。二、用户的数据可能已经存在现有的一些存储系统上，比如S3／OSS／NFS。我们觉得应该直接去利用用户现有的这些数据，而不是再复制一遍，做一个新的存储系统。一种常见方式是：把集群建立起来，建立一个临时的数据仓库，把数据从原来的地方复制到这个数据仓库里使用，使用完了之后再复制回去。我们想建立这样的一个缓存系统来避免这种复制，这样可以节省用户集群构建的时间。很多时候用户都是把数据放在一个很大的集合里，原来那种方式很难避免把不需要用的数据也复制过来。比如说我们有一个分布式计算，这个计算中不需要使用的数据我们也要把它复制出来。考虑到这一点，我们只把需要使用的那个部分缓存到现有系统里来，计算完后再写回到目标的存储系统里面。

而且这个设计是一个scale out架构，当性能达不到用户要求的时候，可以通过增加节点的方式来扩展性能。
我们还支持不同的缓存策略。可以有多个不同的data server，数据服务器可以在不同的云上，这样的话就把数据缓存在了计算真正需要的地方，可以加速数据访问。比如说我的计算是在这个云上面，算完之后，希望把它写回到某个目标的存储上面。 支持自动预取和手动预取。意思是说，我们在做计算的时候知道应用放在哪里，所以我们可以告诉我们的缓存系统，需要把数据先迁移到哪里去，这样就避免了不必要的拷贝，在访问的时候能够很快地去使用数据。  

4

多云环境下，如果某些云出现不可抗拒性故障，对上层企业应用有多少影响？

具体的影响需要看具体的部署方式和应用本身来分析。

我们采用的是双层调度的概念：第一层调度分配业务位置，解决的问题是我要把资源放在哪里。第二层调度分配业务内部工作负载。我已经决定把工作负载放在这个云上的时候，我会在这个云上建立一个集群。任务的一部分就会在这个集群里运行，我们在整个过程都是在监控的，如果某种原因某个地方被停掉了，发生障碍，上层调度会发现这件事情，我们会自动把任务调度到另外一个地方去，或者另一个云上。一般调度时， 业务整体会被分配到一个云上。如果由于某种原因整个云上资源不可访问时，第一层调度会把业务调度到另外的云上。所以我们才能支持使用spot这种可被抢占的资源，可以及时调度到另外的地方去。   

－ END －