一项技术成熟的标志不仅仅在于它有多流行，还在于它有多不起眼并且易于使用。比如，没有人会去思考墙上的插座，除非你恰好需要给你的手机充电但又一个都找不到，这只是我们日常生活中所用到的大量技术的一个例子而已。
自从Google受到它内部集群和容器管理系统Borg以及Omega的启发，在四年多之前率先开源了Kubernetes容器控制器之后，我们就一直在打赌它会在公有云和私有云的容器管理上一统天下。具有讽刺意味的是，当初负责Google基础架构管理的人并不是很情愿将这样的知识产权公开，但是开源信徒们正确地预测到，将Kubernetes贡献给世界之后，Google将会从开源社区得到巨大的信誉，并且有利于创造一个和Google类似的容器化私有云环境，也可能将Goolge的模式传播给竞争对手的云产品，同时也能帮助其扩张自身的云平台。
可以肯定地说，掌舵Kubernetes以及相关监控工具Prometheus的云原生计算基金会（CNCF），已经完成了Google及其成员所安排的工作，就是将Kubernetes转变成一个由横跨各种平台、供应商和客户的生态系统所支撑的工具，这也是为什么几个月前它在CNCF的状态从孵化变成了毕业，一种正式通过的礼仪，同时也有了很多重量级的生产环境用户。但Kubernetes依然只是一个半成品，还远未达到像Linux内核及其周围操作系统组件在过去25年中所做到的那种“隐形”状态（实际上可能只花了15年就达到了那个层次）。随着最近Kubernetes容器编排系统1.11版本的官宣，我们不禁陷入了沉思，Kubernetes到底何时才会消于无形却又无处不在。
社区无疑是非常强大的。下面的数据虽然有点旧，但是也体现了2016年11月到2017年10月之间，GitHub上2800万用户的8500万个软件项目的活跃程度排名：
![github-top-30-projects.jpg]( "github-top-30-projects.jpg")
这是一个气泡图，Y轴绘制了每个项目的issues以及pull requests的数量，X轴则绘制了项目成员所完成的提交数量，气泡本身则显示了社区的相对大小。这个大小其实是每个项目中作者数量的平方根，Linux内核在当时以2843个作者居首，紧随其后的是Kubernetes的2380个和Docker的1346个。
Kubernetes很明智地将容器的运行格式“割让”给了Docker，并且在几年前就和曾经拥有rkt格式的CoreOS握手言和，再加上由于大家都已经认可Docker就是容器的格式，很显然也认可了Kubernetes将会成为管理由容器组成的那些复杂Pod的方法，这些Pod实际上包含并体现了现代微服务应用，甚至是一些传统的巨石型应用。
西方经济体中的公有云三巨头——亚马逊AWS，微软Azure和Google云平台——都支持Kubernetes，而OpenStack和CloudStack开源云控制器也都有方法来运行Kubernetes。正如我们已经讨论过的，VMware提供了很多种不同的方法来交付Kubernetes容器服务（鉴于它的企业客户群保守的天性，或许太多了）。今年早些时候，RedHat收购了CoreOS，现在它有了自己的基于CoreOS Tectonic和OpenShift工具集的Kubernetes软件栈。Docker也已经不可避免地将Kubernetes作为它自己企业级软件栈中Swarm容器控制器的一个替代品。在中国，百度为了它的PaddlePaddle机器学习框架，也在其云上拥抱Kubernetes，并且已经有了基于Kubernetes的云容器引擎。阿里巴巴有云容器服务，腾讯则有Kubectl容器引擎。Windows Server也将在2019年初支持原生的Kubernetes。
这其实影响了企业中的许多根基（原文：This covers a lot of bases in the enterprise），现在世界上大多数人都能够按照Google想要的方式来编排容器——当然，还有社区的意见。Google通过Kubernetes将Borg开放（也确实让它成为了多用户模式并且更好用）的行为是一个开明自利的完美案例。现如今，理论上讲，将业务负载从本地数据中心或者竞争对手的公有云上转移到Google云平台上将会简单很多。当然，反过来也一样。如果客户对Google云平台不满意，他们也可以轻松地将他们的容器化应用从上面转移回到其竞争对手那里或者本地的服务器上。对于如何吸引客户并将他们留在自己的云平台上，Google完全掌握了主动权，这似乎是个相当不错的激励（原文：It is up to Google to attract customers and keep them on its cloud, which seems like a decent incentive）。
一种技术想要达到那种无处不在的形态，必须在其消于无形之前与其他的技术很好地整合在一起。反之亦然。他们总是齐头并进。但很明显，有一个巨大的开发者社区和一个巨大的平台生态系统都已经拥抱了Kubernetes，现在我们就看看到底Kubernetes会被如何接受并且是否能像我们猜想得那样变得无处不在。
我们之前与Josh Berkus进行了一次有关Kubernetes 1.11版本的对话，他是在Red Hat工作的Kubernetes社区管理员并且主导了这次更新，我们还聊了一点关于Kubernetes的潜能。结果我们得知，为了让Kubernetes更好地适应大范围的使用，底层的大量工作已经完成——当然还有更多的工作有待完成。
在这一点上，Kubernetes 1.11版本是个不错的案例。Berkus说在这个版本中新增或改进的25个核心功能当中，有7个是面向用户的功能——即用户能实实在在看到和感受到——而另外18个则是Kubernetes内部的一些重构——用户看不到但同样也会从中受益。
“我们还难以弄清楚何时会将Kubernetes当做一个成熟的产品来看待，因为一些像这样的重构工作还很繁重，”Berkus告诉The Next Platform，提及了其中一项关于和公有云对接的重构任务，它会在接下来的几个版本中持续进行。“在最早的Kubernetes 1.0版本中，与云的整合功能在核心代码中。所以，一个像Digital Ocean这样新的云服务供应商想要提供Kubernetes服务，他们必须拿到被Kubernetes认可的补丁才能让他们的所有功能都正常工作。这显然很糟糕，也没人认为这是一件好事。我们的云服务供应商团队一直在努力将云服务供应商的整合工作转变为一种定义清晰且相较而言功能经得起验证的API（原文：The cloud provider team has been working hard in turning the cloud provider stuff into a clearly defined and relatively feature proof API.）。在Kubernetes中，实际上我们已经移除了第一个云平台，那就是OpenStack，他们本来就要彻底重构自己的云服务供应商代码而且自愿成为第一批从Kubernetes核心代码中移除并完全使用API的人。有一堆这样的事情需要我们去做。我们需要将云供应商们移出并让他们使用云API，也需要将所有的存储供应商转移到云存储接口（CSI）API上去，还需要移动容器运行的所有东西，确保它正在使用容器运行的API而不是背后的通道（原文：We need to move all of the container runtime stuff and make sure it is using the container runtime API and not using back channels.）。按照代码的数量，这是当下Kubernetes项目中最主要的工作。所以，当我们将所有的东西都转变成API的时候，也就是Kubernetes变得成熟并且你们也不会期待任何激进改变的那个时间节点。”
这个时刻的到来可能还要好几年时间，Berkus也同意，因为当API推出之后，它们的缺陷也会暴露出来——正如所有代码被创造出来时一样——它们将不得不缓慢且谨慎的迭代，从而不会破坏兼容性。考虑到那个让Kubernetes可以部署（尽管不成熟）的1.0版本刚刚走过第三个年头，从四年前Google将代码转储到GithHub开始，发展速度已经很快了（原文：Considering we are coming up on the third anniversary of the 1.0 release that made Kubernetes deployable (though not mature), and that is still a pretty fast ramp from a code dump from Google onto GitHub four years ago.）。Google的那份代码的确让自己占据了主动——那是一个用Go语言开发的简化版Borg，比起原版只适用于Google内部的特殊场景来说，它变得更加通用。Google不仅有效地“外包”了一部分可以让这个Borg的衍生品跨平台移植的工作，同时还让社区的合作伙伴们踊跃地参与到这部分工作中来。
这才让我们接受了Kubernetes（原文：That brings us to Kubernetes adoption.）。没有人确切地知道，它一直是一个开源软件栈（原文：No one knows for sure, this being an open source software stack）。大部分参与到云计算技术中的公司，不管是在本地数据中心还是在公有云上，都在通过某种方式使用Kubernetes，但是对于那些一般的公司，它们在数量上仍然占了80%左右（粗略猜测）并且可能在计算资源上的开销（也就是直接购买硬件的开销）占据了市场的一半，这些公司还没有到那一步。但是他们也正在慢慢接受Kubernetes了。
Kubernetes 1.11版本有一些可以让其更容易被接受的功能特性。一个自家的KubeDNS服务系统项目正在转换成为一个CNCF项目——CoreDNS规范，另外Berkus还说有一套更好的规范得到了社区更广泛的支持。1.11这个升级版本也支持Kubelets动态配置（通过一个配置文件或者一份ConfigMap），它是运行在一个容器集群中的所有系统上的Kubernetes守护进程；过去，管理员不得不进入Kubernetes中修改启动参数，然后再重启系统。自定义资源定义（CRDs）已经做了改进，可以更轻松地创建将Kubernetes集群视为一个系统的应用程序，它们不用直接深入到容器的粒度（这正是Borg的天才之处）。这些CRDs是Kubernetes得以扩展的主要方式，再加上允许Kubernetes深入到集群中并且控制虚拟机管理程序（Hypervisors）以及虚拟机的KubeVirt组件，这也只是其中一个例子。这个版本也包含了任务优先级和抢占功能，这意味着Kubernetes可以接受一项高优先级的任务并且立刻执行，即使这意味着要将其他应用中断，延后执行。最后一个重大变化是内核IPVS负载均衡工具，它能在集群上自动平衡Kubernetes服务所承受的负载。
本文转自DockOne-Kubernetes何时才会消于无形却又无处不在
