在过去十年中，基础设施的世界发生了巨大的变化，越来越多的组织将其工作负载分布在多个平台上——包括内部部署和云。这将导致我们管理工作负载的方式发生变化，也带来复杂性和风险的增加。工作负载在多个平台上的分布有许多不同的方式，其中最常见的是多云和混合云。
多云最简单的意思是跨两个或多个云基础设施平台部署应用程序的组件。这些平台可以是两个公共云服务提供商，或者两个私有云，或者它们的一些组合。混合云也差不多，只是它总是指公共云和私有云的结合。
多云和混合云应用程序设计模式可以采取多种形式，但有两种最重要：
托管在不同云上的组件—最常见和最简单的模型涉及到分离组件（应用程序层），以便每个不同的组件部署在单个提供者上，整个应用程序分布在多个云上。例如，应用程序的前端可能位于公共云上，中间件位于私有云上，数据库位于内部裸金属机集群上。
以一个以前端为中心的流量很大的web应用程序为例，它可能经常更新，以对后端资源进行备用调用。将应用程序前端安装在公共云上可以快速、动态地扩展此资源以响应流量，并且可以简化临时（但资源密集型）过程，如频繁发布新版本的蓝/绿部署。将中间件放在私有云上可以实现类似但更受限的灵活性和更严格的安全性。在裸金属上运行数据库提供了最高的可调性和性能，同时为关键和/或受监管的数据提供了最大的保护。
单个组件，分布在多个云中——我们很少使用单个应用程序组件并将其分布在多个云中。这个模型的挑战是，在单个应用程序组件中引入了延迟和潜在的其他网络挑战等问题。
例如，当组织扩大公共云服务的使用并寻求成本优化时，他们经常会遇到所需资源不可用的情况（例如，区域接近容量，没有所需类型的“点实例”可用）。在这种情况下，Kubernetes federation之类的技术可以用来支持容器工作负载，甚至原则上，对等微服务水平扩展以执行单个应用程序功能，从而“跨越”公共云之间的鸿沟。然而，编写基于这种架构的微服务和应用程序意味着要预测一系列延迟和其他条件，而这些条件是在单个基础设施上运行的应用程序并不经常遇到的。
多云优势
多云为帮助开发人员更轻松地使用来自多个云提供商的资源和服务提供了许多优势，包括以下几点。
杠杆——你希望能够对供应商施加一定的杠杆作用，以便能够协商尽可能最佳的价格并确保尽可能最佳的服务级别。如果你被锁定在一个单一的供应商（或垄断），你就失去了杠杆作用。你很容易受到成本上升和服务级别下降的影响。
性价比——访问多个公共云的能力使你能够不断优化性价比（不仅针对工作负载托管，还针对与服务应用程序相关的所有其他性能因素和成本（例如网络出口成本、互联性、延迟））。但是，通过在供应商和基础设施之间移动组件和工作负载，最大限度地提高成本和性能优化的自由度，意味着限制你对所使用的平台和提供商的差异化功能和服务的依赖性。Kubernetes和容器可以在这里扮演重要的角色，形成跨越多个云和基础设施的一致基础。
风险缓解——在上述基础上，你需要能够轻松地将鸡蛋转移到另一个篮子里。云提供商的定价很复杂，很难观察和预测，而且几乎不需要注意就可以改变。服务可以停用。服务提供商的政策也会发生变化，而且服务提供商在执行方面也会变化无常，服务协议的条款使得客户在发生纠纷时几乎没有追索权。因此，提前计划，提供冗余，并确保关键数据库和其他难以移动的组件不会锁定到特定的供应商，是非常有意义的。
位置——公共云提供的一个关键服务是将工作负载和数据放到特定区域的能力。利用位置的能力可以进入利润丰厚的市场——它对应用程序性能（例如，最小化延迟）、存储和传输成本以及（在某些情况下）特定服务的可用性和规模至关重要。
合规性——对工作负载和数据位置（静态数据和动态数据）的控制对于实现合规性、数据主权和数据保护的管辖权战略也至关重要。对于寻求服务全球市场的组织来说，符合GDPR、Privacy Shield和其他法规的管辖权和客户要求的能力至关重要。
多云挑战
策略是确保多云带来好处而不给开发人员、DevOps和运维团队带来额外挑战所必需的。
一致性至关重要。通过确保跨私有云和公共云的应用程序平台的一致性，你可以帮助确保应用程序能够在任何地方运行而无需更改；并且可以在单一通道中维护配置、运维自动化、CI/CD和其他辅助代码库。Kubernetes是目前用于跨越公共云和私有云基础设施以及裸金属的最佳可用平台，它提供了一系列抽象机制，用于将工作负载与底层基础设施隔离开来，在底层基础设施出现问题的情况下保持工作负载的活力，并允许快速、高效、低影响的应用程序更新、扩展和生命周期管理。
但是单靠Kubernetes是不够的——组织需要在任何基础设施上提供一致的Kubernetes，这些Kubernetes易于定制、易于扩展、完全可观察、功能齐备、安全、普遍兼容和运维人员友好的应用程序环境，这些应用程序环境都是由一个中央资源提供的。单一集群模型加快了运维速度，实现了容器、配置和自动化可移植性，同时还提高了安全性（消除了未知和变化，从而减少了攻击面），促进了策略管理并简化了合规性。
使用一个集中管理的系统来交付、更新和管理跨多云的集群，也为提高生产率打开了大门。一块用于可观察性和手动运维的“玻璃”，全自动和无中断的更新，一组用于构建自助服务应用程序和按需交付集群的API（无论你在哪里需要它们）。通过“提供者”中间件（中央命令和控制设施）操纵各种公共云和私有云基础设施，有助于确保你获得特定于平台和公共云的服务的好处，同时还强制执行应用程序运行所在的Kubernetes集群的一致配置和行为。
自由选择与这种模式是一致的。一个集中管理的多云基础设施应该让你的运维人员和开发人员可以在公共云和私有云中自由选择，同时还支持使用一系列操作系统和一系列自动化、CI/CD、安全性和其他工具。
集中式监控和容量管理也很重要，可以确保你清楚地了解系统的性能以及它们消耗的资源，以便你能够正确地决定应该在何处运行应用程序。
在核心需求列表中排名靠前的还有易用性。如果系统过于复杂，无法使用，或者要求开发人员必须学会处理新的或奇怪的系统，这将极大地阻碍采用。
选择多云可能需要放弃什么
当然，选择多云策略并确保使用公共平台跨多个平台部署和管理一致的Kubernetes（以及可能在Kubernetes之上运行的应用程序）也有一些缺点。其中最主要的是，你可能无法（直接）利用公共（和私有）云提供商提供的所有很酷的附加服务，包括“一键式Kubernetes”版本。
很难反驳方便和无成本/低成本/低摩擦启动，但并非不可能。考虑以下几点。
个人试用公共云托管的Kubernetes解决方案所需的努力并不代表一个组织大规模交付多个相同类型的开发、测试和生产集群所需的努力。后者要大得多——处理平台的身份和访问管理，用适当的组和用户填充新的集群，管理（和成本优化）快速增长的Kubernetes集群群（加上它们的相关网络和辅助服务配置），可能跨越多个提供商区域。考虑到所有这些都可能与其他提供者和平台上概念相似但代码不兼容的设置不同。要点：在现实世界中，在真实的尺度下，这个模型不是多云友好的。只有当你深度使用一个公共云或私有云平台时，它才能优雅地工作。
根据你选择的集中式部署/更新/运维/观察解决方案，跨多个提供商和平台大规模交付和管理集群的摩擦可能非常小，（例如，通过针对解决方案的API运行的简单自助自动化）几乎为零。你也可以通过这种方式使用“一键集群”，即使用于生产也是如此。
同样，根据你选择的集中式解决方案，你应该可以从许多核心公共云服务中获得间接收益。这是因为你的解决方案供应商已经设计（并将继续更新）其特定于提供商的配置和部署中间件，以便在合理的情况下优化使用每个公共云提供商的服务组合。不同之处在于，你不需要弄清楚如何围绕Kubernetes集群及其入口使用（和自动化）AWS Route53、Azure DNS、OpenStack Designate、VMware等，就可以在多个平台上建立生产集群。
云提供商服务在集中式的Kubernetes机制下仍然是完全可访问的，并且可以自由使用。你也可以使用AWS Lambda功能和集中式、多云Kubernetes管理。
最重要的是：入门服务（包括Kubernetes产品）让初创企业可以轻松使用。但是，在没有集中化解决方案提供的抽象和调解的情况下，你投入的越多，对提供者服务组合的挖掘越深入，你就越被锁定。使用多云意味着在每个供应商上重复（有差异）在企业级开始的工作，并维护你为此创建的工具的所有并行通道。因此，将运维和业务的任何部分从一家供应商“lifting and shifting”到另一家供应商，就成了一个多层次的挑战。
