【51CTO.com快译】公共云提供商的托管Kubernetes服务提供弹性且高度可用的Kubernetes控制平面部署。这种服务与各自云提供商的原生功能以及本地Kubernetes部署集成起来。然而，这种服务并不总是与其他云提供商的产品集成，至少集成起来不是很容易或很顺畅。
如果你决定采用一家云提供商，并将所有编排流程与该提供商的平台上的部署关联起来，***使用托管Kubernetes服务，比如Amazon Elastic Container Service for Kubernetes(EKS)、Azure Kubernetes服务(AKS)和谷歌Kubernetes引擎(GKE)。你的应用程序在此规则方面带来的例外情况越多，单个托管Kubernetes服务适合你的可能性就越小。
决定与多家云提供商合作的企业要料到，跨多云部署环境集成容器编排任务会变得很难。
想评估托管Kubernetes服务的优缺点，请遵循这三步。
1. 规划部署。
任何容器编排策略的***步是规划托管空间，也就是列出用来托管应用程序的整套资源。这可能包括本地数据中心和多家公共云提供商。针对每个应用程序，确定其部署范围，包括你将在哪里托管其组件。这一步可大致表明你的Kubernetes部署将如何不同。
适合托管Kubernetes服务的企业会有编排图，显示了两个重要的方面：首先，它们只计划使用一家云提供商，如果另换提供商，准备好重新制定运营策略。其次，组件托管在云和数据中心的任何应用程序几乎不执行故障切换或突发操作。
另一方面，不适合托管Kubernetes服务的企业是这类组织：计划使用多家公共云提供商，并在它们之间迅速移动应用程序。此外，如果公司计划使用所有托管资源(包括本地数据中心)作为应用程序组件可以利用的庞大资源池，不适合这种托管服务。
2. 确定多云目标。
大多数公司介于这两个极端之间。如果是这种情况，下一步是定义多云策略。确定你是有静态多云模式(即将应用程序组件放入固定的云提供程序托管组)，还是动态多云模式(即组件可在不同云提供商的平台之间自由移动)。
对于使用静态模式的企业来说，在每个公共云中使用托管Kubernetes服务很可能非常合情合理，但前提是云提供商将Kubernetes与像Istio这些可分配工作并管理分布式流程的工具紧密集成。在这种情况下，使用每家云提供商的工具可能会提升容器托管能力。
然而，使用动态多云模式的企业很可能无法得益于云提供商的托管Kubernetes服务。相反，它们需要一种能够自由跨越云边界的总体编排方法。这类企业应考虑部署自己的Kubernetes编排平台，使用与云无关的工具。
3. 选择你想要如何投入。
云托管的托管Kubernetes服务无法与其他云提供商的原生功能集成。这意味着，如果你致力于多云模式的这些服务，在大多数情况下，还要致力于另外编排每个公共云。
如果你选择Kubernetes的软件发行版，比如Red Hat OpenShift，就得在每个云域中部署应用程序和Kubernetes。你还要管理Kubernetes元素及其控制平面连接的可用性。
面向Kubernetes的一个常见的多云框架是Stackpoint.io，除了本地环境外，它还支持三大公共云提供商：AWS、Azure和谷歌。借助Stackpoint.io，企业可以创建一个通用的多云Kubernetes控制平面，从而可以统一部署。有许多商业供应商提供Kubernetes和Stackpoint.io版本，并附带支持，包括DigitalOcean、Red Hat和VMware。
***，考虑一下你的云提供商对容器和Kubernetes的承诺。谷歌已表明了对两者都大力支持，但谷歌云最近的领导层更迭可能预示着方向有变。至于微软，它似乎几乎和谷歌一样坚定，但AWS在改进其自己的容器托管和编排服务方面起步缓慢，其新的Firecracker微虚拟机产品可能表明会更关注虚拟机。
原文标题：Weigh the pros and cons of managed Kubernetes services，作者：Tom Nolle
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
