让Kubernetes成为需要容器编排平台的企业和用户最喜欢的秘诀是什么？

Kubernetes于2017年11月29日赢得了容器编排最有力支持。那天AWS发布了基于Kubernetes的Elastic Container Service（EKS）。

亚马逊宣布之前，Mesosphere，Pivotal和Docker为Kubernetes提供了原生支持。这些是容器业务流程空间中大多数关键产品的提供者。继谷歌和Azure在基础设施上提供托管Kubernetes服务和OpenShift基于Kubernetes的支持之后。为什么所有这些提供商都选择支持Kubernetes？例如，为什么亚马逊AWS提供EKS？

对于亚马逊AWS来说，这是因为客户需要它，所以许多AWS客户已经在AWS上运行Kubernetes，许多人自己管理他们的集群。鉴于Google和Azure提供更易于管理的Kubernetes服务，因此AWS使AWS Kubernetes体验更加轻松。

但是，当其他提供商已经提供托管服务时，为什么用户还要选择在AWS上运行Kubernetes？可能许多人更喜欢AWS作为云提供商，但这是唯一的原因吗？如果是这样，为什么有如此多的用户要通过AWS ECS选择Kubernetes？

Kubernetes成功的秘诀？

云原生计算基金会2017年3月的调查结果显示，企业非常清楚的首选在AWS上运行Kubernetes，而不是其他云计算：

请注意，本地数据中心的排名也很高。我们可以通过查看CoreOS发布的有关容器编排的调查结果来了解这种模式。应用程序可移植性以及混合和多云解决方案非常突出：

集群federation是Kubernetes成功的一个重要因素，因为它可用于支持多云或混合云用例，因此它比AWS ECS更具优势。但仅此一点并不能解释为什么Kubernetes相对于其他工具变得如此受欢迎。

通过查看各种因素，我们可以更好地理解这一点。我们将了解组织如何希望Kubernetes具有灵活性，以实现混合云，多云和其全面的可扩展性。决策者试图保持灵活性并利用其现有基础设施的原因吗？

混合云

我们已经看到，企业热衷于混合云。在RightScale的2018年调查中，这一点更加清晰，发现高达51％的大型企业使用混合云。

混合云的原因包括利用现有硬件以及需要满足监管或安全限制等要求将数据保留在本地的问题。它也可以是有弹性的，并且能够在失败的情况下保持某种程度的服务。

多云

根据RightScale的调查，高达81％的大企业正在选择多云策略。CoreOS表示，其中很大一部分原因是对商业锁定的警惕，Stratoscale的一项调查表明，高达80％的企业认为云锁定是一个主要问题。

如果你的软件需要重写才能将其转移到另一个云提供商，那么你去其他地方的成本很高。所以如果价格上涨，那么你要么承受这种痛苦，要么被价格上涨吞噬。为了缓解这种风险，企业可能会被多云吸引。

如果你致力于多云策略，那么即使你通常不在单个项目中使用多个云，也可以选择在不同的云上运行相同的编排技术。它可以让你在选择云提供商之前为特定项目选择你的编排技术，并确保编排技能可以跨项目重用。

看来市场希望能够独立于他们的云提供商而选择编排工具，并且能够使用多个提供商。鉴于AWS的普及，很多人都希望能够选择Kubernetes作为编排工具，并在其设置中使用AWS。考虑到Kubernetes并不是由AWS提供的，而是作为其他提供商提供的托管服务提供，而使用AWS带来了额外的好处，即证明你选择的编排工具确实独立于你选择的云提供商。

AWS可能不仅为大量计算的工作节点，而且还用于自管理设置中的主节点。尽管托管Kubernetes服务的可用性，但由TNS进行的2018年分析显示91％的Kubernetes部署正在内部处理。此路径具有挑战性，但可以确保你可以充分自定义设置，并在需要时进行添加。一旦有足够的用走这条道路并分享他们的经验，这可能产生雪球效应。

开放和可扩展

由于市场致力于避免云锁定，Kubernetes在AWS ECS方面拥有巨大的优势。但是市场上的其他竞争者呢？Kubernetes是如何的？在这里，Kubernetes的开放性和可扩展性非常重要。

Kubernetes相对于Mesosphere DC/OS，Docker Swarm或Pivotal Cloud Foundry centers的成功不是因为他们选择编排产品而不想被锁定到工具或语言中。其中一些可能是关于企业和开源产品之间的界限，以及与编排工具本身的锁定。但更重要的是编配层可以保持开放的选项范围。编排工具对各种基础设施，工具和语言堆栈（特别是企业现有工具）的支持在TNS 2016年的调查结果中很大程度上体现为对容器编排的评估标准。

Kubernetes被设计为可扩展，并且人们真的在扩展它（例如OpenShift）并贡献开源项目。关键的编排概念被抽象出来，而不是针对特定语言或工具特定的。对支持的语言没有限制。这种方法与CNCF建立广泛的企业合作伙伴，并鼓励将Kubernetes作为社区项目（而不是将项目与特定供应商联系）的信心。GitHub的2017年Octoverse报告揭示了Kubernetes周围充满活力的开源文化：

充满活力的开源文化以及可插拔设计意味着广泛的选项，插件和工具。

Kubernetes的成功意味着开源以及有云选择的用户的成功。它也反映了希望迁移到云但谨慎行事的企业的意愿，并利用其现有工具和基础设施的诉求。

Kubernetes真的赢了吗？

“赢”没有明确的定义。但是Kubernetes看起来将成为一种标准。虽然还不是，但更多事实上的共同点已经浮现。业界已经发现自己需要一个编排标准来平衡Docker已经成为容器标准的方式 ，而Kubernetes看起来就是这样。