作者：David S. Linthicum 是德勤咨询公司的首席云战略官，也是一位国际公认的行业专家和思想领袖。
随着我们的想法围绕多云而转，我们可能进入到一个新的 开放 时代。
XX 2.0 正变得有点乏味无聊。我们业界使用这个常见术语表示某种技术可能会改变游戏规则，但我们能不能更有创新一点、更有创意一点？
就拿多云来说，因大多数企业使用多个公共云品牌而出现的 1.0 版本正在使用多个公共云。它们通常采用一种专有的 CMP（云管理平台）或 CSB（云服务代理），使用单一界面或抽象（又叫 单一管理平台 ）来管理许多云原生服务。
这就是如今管理大多数多云部署环境的方式。如果你没有 CMP 或 CSB，就得使用公共云供应商为你提供的任何云原生控制台来处理各项云原生服务。
因此，如果你的多云环境中有三个公共云，就需要三个不同的界面和三种类型的技能组合。从长远来看，很难实际操作，实在太复杂了。
如今出现的 2.0 版本 改用一种不同类型的多云：一种使用联合 Kubernetes（federated Kubernetes）作为管理容器化应用程序和数据的手段的多云，这些应用程序和数据在不同的公共云提供商上运行，但意识到彼此的存在。
联合 Kubernetes 方法的有用之处在于，这种架构让用户可以轻松处理在多个云上运行的多个集群。这有赖于使用两项主要的基本功能。第一项基本功能是跨集群同步资源的功能。正如你所料，跨集群同步资源将是部署多云 Kubernetes 的那些用户面临的主要挑战。 Kubernetes 内部的机制可以自动同步多个集群上的部署环境，在许多公共云上运行。其次是集群间发现功能。这意味着能够自动配置 DNS 服务器和负载均衡系统，而后端支持跨多个公共云运行的所有集群。
考虑到你可以跨多个公共云复制主动/主动集群，充分利用多云/联合 Kubernetes 的好处包括高可用性。因此，如果一个公共云出了故障，另一个公共云就可以顺畅无阻地接过处理任务。
此外，你可以避免那该死的提供商锁定现象。这归因于 Kubernetes 是个抽象层，能够让你无需操心每家公共云提供商的复杂性和本身细节。因此，它一下子取代了 CSB 和 CMP。
如果一家云提供商销声匿迹或涨价过高，没什么大不了。你只要另找市场上的其他云提供商。公共云提供商成为了大众化集群处理系统。另外，请记住 Kubernetes 是开源的。
这里没有什么灵丹妙药。的确，在本地或云端构建 Kubernetes 的那些人仍面临一份很复杂的工作。使用联合架构构建 Kubernetes 甚至会来得更复杂。
然而，支持这种方法的工具和最佳实践的数量开始多了起来。此外，我在市场上看到了更多的联合 Kubernetes 技能。的确，这可能是搞多云的一种更好的方法。我肯定是那些率先看到这方面进展的人士之一。
