为什么越来越多企业托管Kubernetes了？

在过去几年，三大公有云提供商亚马逊云服务(AWS)、谷歌云和微软Azure的托管Kubernetes方案(又叫Kubernetes即服务，KaaS)都取得了长足的进步，帮助客户运行和编排他们的容器化工作负载，无需了解YAML配置文件的基本细节，也无需操心自动扩展、更新和集群管理。

[[415034]]

Stephen O'Grady是面向开发人员的调研公司RedMonk的联合创始人，他说："当企业认为某个系统具有战略意义时，本意是想自己运行。后来随着逐渐适应，他们渐渐认识到：自己运行没有带来任何竞争优势，供应商有可能比他们运行得更好。"他补充道："每家企业都在走这条路吗?还没有，但是走这条路的愿望和方向似乎很明确。"

以下是考虑采用托管Kubernetes服务的六大原因：

降低管理成本

不妨先从一个显而易见的原因说起。Sylvain Roy是旅游业技术公司艾玛迪斯(Amadeus)主管技术平台和工程的高级副总裁，他说："要弄清楚一点，我们的工作量减少了。有人替我们运行，这很重要，因为我们很难雇佣到运行Kubernetes所需的所有人。"

同样，自2006年以来，建筑公司Strabag的一小群工程师就一直在自己运行容器，在过去四年里，他们改用了自我管理的开源Docker和Kubernetes环境。现在，这群人正考虑尽可能提高集群管理的自动化程度，他们决定：更新改造现有的应用程序，将管理底层Kubernetes集群的任务移交给谷歌云;或者授权开发人员使用Anthos服务，在云端或混合环境中运行新的应用程序，特别是需要一些本地数据传输时。

Strabag的云服务团队负责人Mario Kleinasser说："首先要移交适合移交的任务。"

金融数据巨头彭博社计算基础架构主管Andrey Rybka也表示，"如果没有SRE(软件可靠性工程)团队或管理Kubernetes发布周期的团队，对专注于运行应用程序、不想管理Kubernetes的那些企业来说，充分利用托管供应商是合理的举措。"

如今，彭博社仍在本地运行大部分的Kubernetes工作负载，但它也开始在适当的情况下将三大云供应商都用于托管的工作负载。

只需要少数专家

Kubernetes的管理技能很难获得，且成本很高，自行编写YAML配置文件更是如此。即便你有可以手动调整Kubernetes集群的人员，也可能需要把较为普通的工作负载集群管理任务交给供应商，而让自己的人员腾出手来管理内部平台或任何特别重要或棘手的工作负载。

艾玛迪斯的Roy说："获得和留住这些技术所需的人并非易事，这显然是个挑战。"

更好的可靠性

简而言之，基于工程团队的规模、客户部署的多样性，以及可以访问这些部署环境底层的遥测数据，大型云供应商常常比你自己更有能力管理Kubernetes集群。

RedMonk的O'Grady说："供应商很可能更好地运行Kubernetes集群。供应商有遥测数据，其优势在于可以看到所有客户运行集群的情况，而不像单个企业只有自己的数据模型可供使用。"

以彭博社为例，它在2015年的盛行期转而采用Kubernetes，当时Kubernetes仍只是alpha测试版。等到运行结果证明：必要的持续集成、监控、测试与预期相符，Kubernetes就在2017年进入到了生产环境。Rybka表示，虽然彭博社的工程师仍在很大程度上为本地应用程序自行管理Kubernetes集群，但是当工作负载在公有云上运行时，使用托管方案显得越来越合理，"从可靠性的角度来看"更是如此。

不用担心升级和补丁

对于自行管理Kubernetes的任何企业来说，升级和补丁是最枯燥乏味的两项工作，这就是为什么托管提供商优先考虑替您处理这些任务。

AWS计算服务副总裁Deepak Singh说："自行打补丁、更新和管理Kubernetes非常复杂，而且是完全没有乐趣的苦差事。"

保持云发展势头

对于大力推行公有云优先策略的组织而言，采用更多的托管服务有助于提升势头。

艾玛迪斯最近与微软签署了一笔交易，就是为了做到这一点。Roy说："公有云发展迅猛，我们希望从中受益，于是我们每次都会考虑使用更多的托管服务。在我看来，这是得益于这股势头的途径。"

现在，供应商们正将各自在Kubernetes最佳实践方面的知识和经验转化为更自成一体的Kubernetes服务版本，并简化了采用路径，比如GKE Autopilot。

谷歌的首席工程师Kelsey Hightower说："一些人会将Autopilot视为备胎，而我将其视为安全带。汽车行驶的速度一样，但默认情况下更安全，这是一种万无一失的配置。人们总是问我们有何最佳实践、问他们要做出什么样的决定，Autopilot给出了答案。"

同样，AWS的Singh表示，该公司正变得更擅长运用大规模运行Kubernetes所获得的经验，将这种"运作经验结合到EKS中……这让我们的服务提供商可以将其直接集成到这些托管服务中。这是你会看到这股潮流愈演愈烈的另一个原因。"

然而，这类服务往往让人担心供应商锁定。"之所以Autopilot比较难选择，是由于这个问题：既然没人另换供应商，为什么关注Kubernetes这个中间件层。答案是我可以撒手不管。"RedMonk的O'Grady说，"你越依赖针对特定供应商的选项，越无法做到可以撒手不管，因此这对企业而言是艰难的选择。"

是开源、可移植的

托管提供商必须赢得开源社区和客户的信任，客户要确保自己使用的Kubernetes发行版尽可能接近普通开源版本，以提高可移植性，并避免锁定现象。

谷歌的Hightower说："Kubernetes面市时，有人担心它是挂羊头卖狗肉，是供应商与开放社区抢地盘，它会演变成开放核心。差不多过了五六年，才证明并非如此。"

同样，AWS的Singh表示，对一些客户而言，EKS与Kubernetes的开源发行版保持关系密切很重要，"没有会造成差异的怪异巫术。"AWS最近在GitHub上开源其EKS发行版，证明了这一点。

Kubernetes的联合创始人兼VMware Tanzu的首席工程师Joe Beda承认："谈到这个话题很难不提到锁定。"他敦促做出这种购买决定的任何人都应适当评估风险。

Beda说："你离开的可能性有多大?如果离开，迁移成本会有多大?你需要重写多少代码、需要多少的再培训?这方面进行投入的任何人都需要了解面临的需求、风险和取舍。"

云原生计算基金会(CNCF)开展了一项Kubernetes认证合格计划，该计划确保一套安装系统与下一套安装系统可实现互操作性，不管认证的供应商是哪一家。

那么，为什么有的企业没有选择它?

对于艾玛迪斯和彭博社等庞大的复杂组织而言，无论是敏感数据安全问题、棘手的本地依赖项还是过度保护的平台团队想要手动调整自己的集群，可能总会有一些工作负载是你不放心交给托管服务提供商处理的。

谷歌的Hightower说："那些想要自我管理部件/组件的人会担心数据平面;他们需要在某些方面进行定制或专门化。他们不介意托管的控制平面。"

然而实际上，自己运行Kubernetes的种种理由变得越来越缺乏说服力。

RedMonk的O'Grady说："也许你认为这是一项现有投入，没有人希望将其作为沉没成本一笔勾销，或者偏于保守的组织对一系列工作负载或业务交给外人心存担忧。或者有人会为一部分具有战略意义的基础设施不受自己控制而担忧。但是当你看到同行采用托管方案时，这种担忧就会烟消云散，你会看到更多人在获得切实的好处。"