【.com快译】来自公有云供应商的ManagedKubernetes服务提供了弹性和高可用的Kubernetes控制平面部署。该服务与各个云提供商的本机功能以及本地Kubernetes部署相集成。然而，此类服务并不总是与其他云提供商的产品集成，至少不是很容易或顺利。如果您决定采用云提供商并将所有编排流程与该提供商平台上的部署相关联，最好使用托管Kubernetes服务，例如AmazonElasticContainerServiceforKubernetes(EKS)、AzureKubernetesService(AKS)和GoogleKubernetesEngine(GKE)。您的应用程序对此规则带来的例外情况越多，单个托管Kubernetes服务适合您的可能性就越小。决定与多个云提供商合作的企业应该预料到跨多云部署集成容器编排的任务可能很困难。要评估托管Kubernetes服务的优缺点，请遵循以下三个步骤。1.规划您的部署。任何容器编排策略的第一步都是规划托管空间，即列出用于托管应用程序的整套资源。这可能包括本地数据中心和多个公共云提供商。对于每个应用程序，确定其部署范围，包括您将在何处托管其组件。此步骤指示您的Kubernetes部署将有何不同。适合托管Kubernetes服务的组织将拥有显示两个重要方面的编排图：首先，他们计划仅使用一个云提供商，并准备在更换提供商时重新实施其运营策略。其次，任何其组件托管在云和数据中心的应用程序都很少执行故障转移或突发操作。另一方面，不适合托管Kubernetes服务的企业是计划使用多个公共云提供商并在它们之间快速移动应用程序的组织。此外，如果公司计划将所有托管资源（包括本地数据中心）用作应用程序组件可以利用的巨大资源池，则此托管服务也不合适。2.确定多云目标。大多数公司都介于这两个极端之间。如果是这种情况，下一步就是定义多云策略。确定您是否拥有静态多云模型（即应用程序组件放置在固定的云提供商托管组中）或动态多云模型（即组件可以在不同云提供商的平台之间自由移动）。对于使用静态模型的企业来说，在每个公共云中使用托管Kubernetes服务可能非常有意义，但前提是云提供商将Kubernetes与Istio等可以分配工作和管理分布式流程的工具紧密集成。在这种情况下，使用每个云提供商的工具可能会提高容器托管能力。但是，使用动态多云模型的企业可能不会从云提供商的托管Kubernetes服务中受益。相反，他们需要一种可以自由跨越云边界的总体编排方法。此类企业应考虑使用与云无关的工具部署自己的Kubernetes编排平台。3.选择您想要贡献的方式。云托管的托管Kubernetes服务无法与其他云提供商的本地功能集成。这意味着，如果您在多云模型中承诺使用这些服务，在大多数情况下，还承诺额外编排每个公共云。如果您选择Kubernetes软件发行版，例如RedHatOpenShift，您必须在每个云域中部署应用程序和Kubernetes。您还可以管理Kubernetes元素及其控制平面连接的可用性。Kubernetes的一个常见多云框架是Stackpoint.io，它支持三大公共云提供商：AWS、Azure和谷歌，以及本地环境。借助Stackpoint.io，企业可以创建一个通用的多云Kubernetes控制平面，以便统一部署。有许多商业供应商提供Kubernetes和Stackpoint.io版本以及附带的支持，包括DigitalOcean、RedHat和VMware。最后，考虑您的云提供商对容器和Kubernetes的承诺。谷歌对两者都表现出强烈的支持，但谷歌云最近的领导层变动可能预示着方向的改变。至于微软，它似乎几乎和谷歌一样坚定，但AWS在改进自己的容器托管和编排服务方面进展缓慢，其新的Firecracker微型VM产品可能预示着更加关注虚拟机。原标题：WeighttheprosandconsofmanagedKubernetesservices，作者：TomNolle
