基于Kubernetes的混合云的优缺点

Kubernetes和混合云

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

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

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

基于Kubernetes的混合平台

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

AWS的EKS Anywhere可以通过Amazon的Elastic Kubernetes服务管理内部集群（也可能是运行在其他公共云中的集群），可以算是某种混合云平台。它并不是亚马逊主要的混合解决方案（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可以管理虚拟机和容器，事实上，VM编排在Tanzu和Anthos中都是重要功能。但归根结底，在Kubernetes中管理虚拟机可能会让人感到奇怪，Kubernetes的设计首先是编排容器。虚拟机的启动和停止速度通常不如容器快，而且你很少像容器那样启动多个虚拟机实例。如果你的工作负载主要由虚拟机组成，那么最好使用不围着Kubernetes转的混合云平台。

同样值得考虑的是，你是否看好Kubernetes。这个平台如今非常流行（这也是谷歌和VMware选择它作为混合战略基础的部分原因），但它只有7年的历史。有理由认为Kubernetes更像是一种时尚，而不是一种长期的技术主流。

毕竟，五六年前，当Kubernetes只是一个没有人能说出名字的新贵项目时，Docker似乎要永远统治世界，那时候把你的工具与Docker结合似乎是一个稳妥的选择。但现在完全不是如此。

那么，致力于一个基于Kubernetes的混合平台，就有可能像是在2015年左右全力以赴押注Docker：只要炒作持续下去，它就会起作用，但当时尚消退时，你可能不得不重建一切。

灵活性是另一个需要考虑的因素。一般来说，基于Kubernetes的混合云比那些依赖云供应商专有工具的混合云更灵活。例如，如果你使用Azure Stack，那么很难迁移到AWS Outposts，因为这基本上相当于从Azure迁移到AWS。但是从Anthos迁移到Tanzu会更容易（虽然不是无缝的），因为这两个平台都是建立在Kubernetes之上的。

结论

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