混合云平台如今开始分为两大类：基于Kubernetes的云平台和不基于Kubernetes的云平台。因此，在组织构建将内部部署或托管基础设施与公共云集成的架构时，这必须做出的一个基本决策。

Kubernetes和混合云

当然，开源容器编排器Kubernetes不仅仅是一个混合云平台。这是在任何内部部署基础设施或公共云或其组合上运行应用程序的一种方法，尤其是在容器中运行的应用程序。支持混合云架构甚至不是Kubernetes项目的重点。

尽管如此，Kubernetes为混合部署提供了关键优势。它提供了一种统一的方式来部署和管理应用程序，无论它们在哪种基础设施上运行。它通过从应用程序环境中抽象底层基础设施来实现这一点。当组织在Kubernetes上部署应用程序时，无论是在公共云、托管数据中心，还是用于测试的笔记本电脑中进行部署，其过程基本相同。

而且，由于Kubernetes可以同时管理跨多种类型基础设施的应用程序环境，因此它提供了一致的部署和管理体验，即使组织的一些服务器和应用程序运行在公共云中，其他服务器和应用程序也可以运行在内部部署设施或托管数据中心设施中。

基于Kubernetes的混合平台

意识到这一点，过去几年中一些供应商采用了Kubernetes优先的混合云方法。最突出的一个例子就是使用Google Kubernetes Engine来管理在任何公共云或私有数据中心中运行的集群的Google Anthos。VMware公司的Tanzu平台是另一个。

AWS公司的EKS Anywhere可以通过Amazon的Elastic Kubernetes服务管理本地集群(以及可能运行在其他公共云中的集群)，也可以用作混合云平台。它不是AWS公司的主要混合解决方案，而是提供更广泛的混合服务的AWS Outposts，但是在一定程度上，EKS Anywhere支持跨越多个托管环境的容器化应用程序的部署，因此符合混合云的要求。

基于Kubernetes的混合平台还包括AWS Outposts、Azure Stack和Azure Arc，使用其他技术作为混合云管理的基础。它们也恰好都是通过混合架构来支持Kubernetes部署的，但是它们并不使用Kubernetes作为底层混合环境的管理层。

为什么不选择混合云上的Kubernetes

一种混合云方法是否比另一种更好?这取决于一些变量。

最重要的是，是否更喜欢通过Kubernetes管理工作负载，而不是通过公共云的标准工具来管理工作负载。诸如Anthos和Tanzu之类的平台使用Kubernetes来统筹一切，而诸如Outposts和Azure Stack之类的解决方案则使用原生管理工具(CloudWatch、CloudTrail、CloudFormation等)来进行应用程序部署和管理。如果更喜欢使用Kubernetes方法进行应用程序部署和管理，那么基于Kubernetes的混合云平台可能更适合。

要考虑的第二个因素是应用程序的容器化程度。Kubernetes可以管理虚拟机以及容器，实际上，虚拟机编排是Tanzu和Anthos的主要功能。但是最终，在Kubernetes内部管理虚拟机可能让人感觉奇怪，Kubernetes的设计首先是为了协调容器。虚拟机通常不会像容器那样快速地启动和停止，并且很少像使用容器那样启动多个虚拟机实例。如果组织的工作负载主要由虚拟机组成，那么不依赖Kubernetes的混合云平台可能会为其提供更好的服务。

同样值得考虑的是问题是，是否认为Kubernetes将长期坚持下去?这个平台如今非常流行(这也是谷歌和VMware选择它作为混合战略基础的部分原因)，但它只有7年的历史。也有人认为Kubernetes更像是一种时尚技术，而不是一种长期使用的技术。

毕竟，五六年前，当Kubernetes只是一个没有人能说出名字的新项目时，Docker似乎将会持续发展，而当初将工具与Docker结合似乎是一个稳妥的选择，现在人们都知道其结果如何。

因此，承诺使用基于Kubernetes的混合平台，就像在2015年左右全面投入Mesosphere一样，当不再流行时，可能必须重建所有内容。

灵活性是一个需要考虑的最终因素。一般来说，基于Kubernetes的混合云与依赖于云供应商专有工具的混合云相比更加灵活。例如，如果使用Azure Stack，将很难迁移到AWS Outposts，因为其迁移基本上等同于从Azure云平台迁移到AWS云平台。但是从Anthos迁移到Tanzu会更容易，尽管不是无缝的，这因为这两个平台都建立在Kubernetes上。

结论

选择Kubernetes作为混合云战略有着充分的理由。选择一个不需要Kubernetes工具并且支持Kubernetes无法管理的工作负载类型的平台也有一些很好的理由。