硅谷速递 | Google、微软、BAT都在探索的Kubernetes，你不了解一下吗?

Kubernetes 是容器编排引擎的事实标准，是继大数据、云计算和 Docker 之后又一热门技术，而且未来相当一段时间内都会非常流行。对于 IT 行业来说，这是一项非常有价值的技术。对于 IT 从业者来说，掌握容器技术既是市场的需要，也是提升自我价值的重要途径。

IT行业从来没有在营销炒作上短缺过，容器编排的新兴标准Kubernetes也不例外。当然，Kubernetes的技术血统是杰出的，因为它源于拥有强大技术背景的谷歌公司。此外， 自2014年作为由CNCF托管的开源项目诞生以来，该项目在丰富的生态系统的推动下，取得了令人瞩目的增长，而且这种趋势正在加剧。

Kubernetes：IT革命的演进

我很幸运能够在Kubernetes最初发布时以及作为稳定的（版本1.0）项目（分别在2014年6月和2015年7月）出现（在云计算风暴的眼中）时，与该领域的尖端工程团队合作，并看到了Kubernetes使用范围不断扩大，成熟度不断提高。该项目经历的里程碑都有详细的记录，但我看到的一些实际采用趋势在时间表上有所变化，如下：

2014年：极早采用该技术的人试图了解Kubernetes的工作原理。

2015年：随着CNCF和Google由GKE管理的Kubernetes，更广泛的软件和系统工程师社区，现在拥有该技术的参考模型，红帽OpenShift从容器PaaS路径开始。

2016年：由于此时只有少量工作负载实际在Google的公共云上运行，因此重点转移到寻找在其他云或本地上安装Kubernetes并启动用于测试应用程序的集群的方法。

2017年：Azure和AWS提供了更多托管的Kubernetes服务，这有效地巩固了Kubernetes的领导地位，成为事实上的容器编排标准。早期采用者拥有顶尖的工程技术人才，可以根据技术大规模部署生产工作负载。主流实际上在使用Kubernetes进行操作的部分仍然集中在了解如何在概念验证级别上安装和管理它。

2018年：甲骨文等公司通过数字海洋推出了多个更受管理的Kubernetes服务，加上前三大云的托管Kubernetes服务的增长，有效解决了简单的安装和管理问题。

这几乎是无处不在的技术方式：云原生生态系统将不可避免地变得更加成熟和商品化，我们中有些人的年龄足以记住建立一个自定义网站的费用可能高达数十万美元，但是今天只需要使用方形空间或Wix模板；对于这个市场，我们不应该承担任何其他要求。考虑到商品化，围绕Kubernetes投资定制技术是否有意义？我认为，从中长期来看，IT买家应该寻找被广泛使用，可扩展且经过生产验证的解决方案，然后再决定是否投资内部运营（开源）或托管/商业软件模型。

Kubernetes可以从Apple与Android大战中学到什么？

苹果和安卓采用了截然不同的市场路径，Apple一直致力于提供全面统一的用户体验和直观的可用性，因此选择了较慢的发布周期和更精美的产品。与Apple不同，Android选择了更快的发布周期以及许多设备制造商可以定制的操作系统。

反对者有时会认为Android的方法受到每个设备制造商以不同方式为每个设备包装操作系统的阻碍。最终结果是，运行在Android之上的不同组件和应用最终无法很好地协同工作，通常会导致不良且不直观的用户体验。 

自Android最初发布以来，Google介入其中，对供应商如何操作该软件施加了更大的控制权。当前的策略反映了苹果采取了更全面的方法。如今，用于自动化、部署、扩展和管理容器化应用程序的开源系统Kubernetes处于类似的转折点，并且该技术的未来必须包括更全面的方法。

Kubernetes管理平台必须跨越各种硬件设备，更重要是它要跨混合基础架构并保持一致性，在本地使用一种方法来管理Kubernetes，而在云中使用另一种方法则会导致灾难，因为这种方法创建了双重系统，带来了复杂性、高成本和不兼容性。

在这里，苹果的做法同样具有启发性，苹果公司的操作系统使得应用程序可以跨设备进行移植，包括iPhone和iPad。苹果还跨多个设备同步用户数据，因此体验在任何地方都是一致的。苹果公司了解，底层数据的可移植性与应用程序本身的可移植性同等重要。

当前的Android智能手机市场或许能够说明问题，这种碎片化使得开发人员很难创建一些能够在这些不同产品上运行的应用程序。今天，Kubernetes网站列出了65个分销合作伙伴。如果没有统一的Kubernetes方法，不可能跨发行版移植数据和应用程序。

Kubernetes需要更高层次的观点

尽管业界对可用的Kubernetes选项的广泛性感到兴奋，但我们仍然需要在更高层次上考虑Kubernetes。将Android操作系统的易用性与Apple的易用性进行比较，可以说明原因。

Android是为自定义而构建的。一旦用户花时间翻转控制杆并根据自己的喜好更改设置，Android OS就会成为高效的系统。这就要求人们至少对这些设置的含义以及它们如何影响用户体验有基本的了解。另一方面，Apple提供的可定制性较差，但开箱即用易于使用，降低设备使用进入门槛无疑有助于推动苹果的普及。

Kubernetes需要类似的公司生态系统来帮助实现其潜力，即必须有打包的解决方案和方法，以确保不同用户可以在混合云基础架构或硬件中部署它。苹果更严格的控制消除了复杂性，它着重于应用程序和产品之间的紧密集成。简单地说，它就是有效的，并推动了主流采用。尽管Kuberenetes越来越受欢迎，但分散的分销市场可能将其转变为另一个Android。

对于Kubernetes来说，已经存在一个用于更全面方法的框架。容器化并不是新事物；这个概念建立在成熟的技术之上。Kubernetes在Google基础架构的启发下以新颖的方式运用了其概念。Kubernetes的目标应该要更像苹果的方法，任何用户都可以轻松地在混合云基础架构之间移植应用程序和数据。这些现有框架可以帮助指导Kubernetes走向更全面的未来。 

最后，对于组织而言，拥有在群集或站点发生故障时快速恢复应用程序和数据的工具至关重要。决策者应研究前瞻性解决方案从多种故障模式中恢复无状态和有状态应用程序和数据的能力。如果组织从整体上考虑其未来需求，那么Kubernetes策略可以帮助解决当前和未来的业务问题。

Kubernetes是否杀死了OpenStack工程师？无服务器会杀死Kubernetes吗？

几年前，许多人认为OpenStack将接管世界。这是不可避免的，没有人对此提出质疑。Docker改变了格局，然后出现了另一个改变游戏规则的Kubernetes。今天，每个人都在兴奋地谈论无服务器（功能即服务）。Kubernetes是否杀死了OpenStack工程师？无服务器会杀死Kubernetes吗？

过去五年来，云技术的创新步伐令人震惊。毫无疑问，该技术正在以惊人的速度发展。几年后，有些人认为公司应该全力以赴，并使用无服务器来编写整个应用程序堆栈。

云基础架构不是游戏

无服务器并不没有要销毁Kubernetes，云基础架构空间竞赛不是一场游戏。Kubernetes是OpenStack之后的一个明显的发展，可以在其中成功运行。在未来很长一段时间内，OpenStack的用户都会出现，这也是许多公司从OpenStack转向Kubernetes的原因。无服务器是前瞻性开发团队的另一个工具，它可以在Kubernetes之上运行（请参见Knative），使你能够从无服务器的简单性和Kubernetes的复杂性中获得好处，这对堆栈中的两者都有意义。最终，我们甚至可以整理出分布式数据。

如今，无服务器架构可以通过在由公司自己构建和维护的集群中运行Knative来实现。但即使是云提供商提供的第三方服务，这其实并不相关，随着项目以惊人的速度不断成熟，底层技术将在越来越多的地方成为Kubernetes。

无服务器只是另一个工具

Serverless并没有像容器摆脱操作系统一样抹去Kubernetes，这两者将越来越错综复杂地交织在一起——站在开源巨头的肩膀上，迭代创新成为可能。当团队坐下来设计下一步时，很少有人会全力以赴地使用完全没有服务器的堆栈。尽管如此，越来越多的公司将使用无服务器技术来实现其堆栈的一部分，因为对于某些特定的问题，它无疑是最好的工具。

采用云原生开源技术的趋势将类似于一根曲棍球，而我们只是刚刚开始着手，或者更准确地说，才刚刚开始爆炸。每年都会有新技术建立在今天的基础上，但是你会听到关于Kubernetes更多的声音，因为它为它上面的一切形成了如此重要的基础。

 参考文章：

[1] Udi Nachmany.Kubernetes: Evolution Of An IT Revolution .

[2] Brian WaldonForbes Councils Member.What Kubernetes Can Learn From The Smartphone Wars.

[3] Kendall Miller.Forbes Councils Member.Serverless:Is It The Kubernetes Killer?