今天我们来聊聊，但不从技术细节角度，聊为什么容器、Kubernetes是值得使用和整合到你的项目堆栈中的。我们的目标是给你们提供一个关于应该如何思考你的底层构架以及将它可视化问题，从这个角度来谈我们的话题：Kubernetes为什么重要？

提纲：

1. 简介
2. Kubernetes的Root
3. 为什么Kubernetes重要 
4. －K8S功能 
5. －不同人员的任务角色
6. 整体情况
7. 结论

简介：

Kubernetes旨在作为你容器的管理层。然而，它的重点是无缝提供给你的应用程序真实实在的需要，满足你的应用程序所依赖的需要。举个例子，这些应用所需就是由Kubernetes提供的：访问与供应商无关的数据卷、负载均衡、冗余控制、弹性扩容、滚动更新以及配置密钥管理。

有了例如上述的性能和特点，再加上由Docker和容器本身运行时提供的打包件，管理应用程序的实践（不是servers）才开始通过使用Kubernetes展开。

Kubernetes的起源

Kubernetes的开始起源于谷歌，它在谷歌系统中有自己的起源：Borg和Omega。许多基于这些系统的设计和安装的相同概念，已经作为一个新的表现形式渗入Kubernetes，这个表现形式包括现今的标准，合并了很多谷歌在过去十年里吸取到的实践经验教训。

Kubernetes不是像很多人开场白讲得那样，是Borg或者Omega的“开源”版本；而是一个谷歌花了很多力气来为你的工作和服务创建的新管理工具。Kubernetes在谷歌是利用许多年的架构和实践经验开始的，但是因为它是开源项目，而且已经证明它可以真正简化开发、操作和管理职责，所以自从它的初始公开版本在2014年6月提交后，就积累了越来越多的代码提交贡献。

这是Kubernetes自从2015年以来收到的代码提交数量的一个截图：

这些图简短地描述了一个真实的、合作的Kubernetes技术社区。

导言

就像我们之前提到过的，有很多人以个人名义或者是公司名义加入到Kubernentes。然而，真正的问题是，你有没有像最初开始的那样，按照谷歌的方式来运行你的应用程序和服务呢？

我们现在了解到的是，Kubernetes不仅仅只是一个容器管理系统，它也从内部查看了谷歌为实践每一个服务和产品：从Gmail、搜索、地图到GCE（服务产品清单还在持续增长），是如何运行他们的基础设施的。

因此，Kubernetes也是运行谷歌的一种方式，所以本质上来说，你注册就是为了能够访问一组指定的设计原则，这组原则会让你的应用程序有效运作，像谷歌那样轻松建立和管理您的应用程序。这并不是说，底层系统例如OpenStack或者AWS处理IaaS资源，就不能用了，而是说这些系统都尽可能做到最好，而Kubernetes就是为带来你的应用程序所需要的一切而生。最终，融合Kubernetes会创建一个良好组件的结合。

所以，如果你正在为你的项目考虑Kubernetes，那么你必须信任项目所呈现的基础和范式，从Pod开始，然后剩下的concepts自然会跟过来。这将给用户非凡的组合功能和灵活性，Kubernetes本身的视野在重新定义你的应用程序是如何构建的上体现了辅助作用。

Kubernetes为什么重要？

就像最近的关于Borg、Omega和Kubernetes的那篇论文里提到的细节（论文戳这里：Borg, Omega和Kubernetes：谷歌十几年来从这三个容器管理系统中得到的经验教训），Kubernetes帮助建立成套工具来辅助管理和缩放你的应用程序。

以下是Kubernetes如何让改进应用程序开发的方法：

功能：

1. 容器将应用环境封装，从应用程序开发者和基础设施层面抽象掉很多机器和操作系统的细节。
2. 管理API从面向机器转到面向应用程序，程序部署和检查极大提高，数据中心也由面向机器转向面向应用程序。
3. 应用程序API的转换可以让团队无需担心机器和操作系统的细节特性。
4. 专注于机器上的应用程序，这也允许团队以更灵活、更模块化的方式来操作。

原因是Kubrnetes是pod的常见使用模式实例，或者说是一个组件，是一个复杂应用程序中可以编写，运行以及被一个小团队全权负责管理功能的组件

甚至其它的Kubernetes旨在提高你的应用程序的组件，是建立在例如像ReplicationsSets，部署，服务之类的概念之上，因此，合并巩固所有的应用程序需求，业务政策以及团队，就变得简单，可以无缝衔接。你可以探测不同的Kubernetes的概念，不仅仅跟Pod互相作用，而且允许你为你的应用在《用户指南词汇表》里创建新功能。

不同人员的任务角色：

Kubernetes也会通过吸引大量不同的任务角色来给你的公司构架提供帮助。

1. 开发者（developers）：不仅可以创建通用的应用，他们还可以使用集群本质的属性来完成任何应用的特定需求。
2. 在使用案例之中，devs想要把一个特定的Node作为目标，或者将一组Nodes作为目标，表示不同的硬件细节的特定标签可以用于个人Pod调度。也就是，如果你想要在AMD CPU（而不是Intel）架构上运行你的应用程序，或者你希望利用GPU，甚至是有大数量的RAM的Node。
3. 消耗各种不同的机器在不仅在Kubernetes上是可能的，而且它事实上将所有的机器都拉平衡，并且将他们呈现为一个通用的计算资源。
4. 这不仅由你的应用程序体现了Pets vs. Cattle的意识形态，你的机器也是。
5. 运维（Devops）：Kubernetes概念，比如像Deployments，replicaSets，Services等等，所有这些都会帮助减轻运维，确保每个应用都有一个描述性的系列业务政策，而且这些规格都是随时实施和维护的。
6. 管理员（Admins）：作为Kubernetes的一部分，admins可以通过使用例如像Heapster或者cAdvisor一样的工具来获得访问权和流程容器资源，同样的，检查集群的事件，API请求，监测数据，和利用Kubedash做分析。
7. 这些不同的软件度量不仅提供检测Kubernetes集群服务，而且还提供一个对这些应用程序自身的细粒度理解，因为他们都是单独控制的。如果不把一些复杂沉重的安装留给用户的话，很多在其他系统里的应用程序层面的分析是不可能完成的。这些在Kubernetes上的本地功能说明了项目的努力不仅是针对你的应用程序的增长，而且这个水准的信息是一个为你的应用程序确定的需求，你不该自己创建这个功能，而是该功能应该被通过系统提交给你。
8. 其他：最近，许多不同的任务角色可以跟Kubernetes互相作用，在基础水准上，通过利用dashboard将你的集群可视化，同时运行措施：比如创建一个新的资源，比如为对资源利用标签进行查询，比如检查或生成报告。

整体情况

为了帮助大家理解Kubernetes大框架是如何运作，我们来展示的一些图，可以帮助大家更好的理解这个项目。

就像James Burker说的：

只有你知道自己去过哪里，你才会知道你想去往哪里

基于这个话，我们要考虑Kubernetes的鼻祖就是Borg以及它和Borg的极大渊源。从这句话出发，我们可以考虑该如何有组织的思考集群。

让我们先来看一些从Borg的论文里读到的情况，这不仅可以让我们一窥Borg是如何配置的，还可以让我们知道同样的模型是如何应用到Kubernetes上面的。

这里我们可以看到我们的首要云架构从上面看是怎么样的。

（跨数据中心的Borg部署）

如果我们进一步放大，我们可以检测到每个在数据中心的建设包括了至少一个Borg集群，它被分成了约10000个机器：

（图：Borg系统里的一个集群）

再进一步观察这个“细胞”，我们可以一睹控制台的组件和工人／Nodes的不同，以及Kubernetes Pods和Borg里十分相像，对于任何应用程序后者在整个过程中的服务，是唯一的原子单元。

（图：Borg系统里面一个数据中心里的一个cell，即Borg系统里一个集群）

可能就像你现在注意到的那样，这里有很多平行的Borg组件，还有现在存在于Kubernetes之中的，特别是1:1相对应的集群和Pods——这些相似点会让你在思考联合Kubernetes配置的时候更快想明白。

虽然Kubernetes目前还不能像Borg那样每个集群规模达到10000个节点，但是它最近已经优化到可以允许集群支持最多1000个Nodes和30000个pods，而且99%的API可以在1秒内呼叫回应，还有99%的Pods（已经有先拉下来的镜像）在5秒内开启——巨额收益代表规模增长10倍，据报道称根据谷歌的内部人士称，实际是增长将近14倍。

Kubernetes当然是为“黄金时间段”准备的，不仅是因为许多公司都在生产过程中使用，而且还单纯因为它的性能和规模。

结论：

我们希望你能够有更好的理解在现今的软件发展时代“Kubernents为什么重要”的原因，也希望你能够更好理解如何组织以及构架你的集群来使之整合。

去接受Kubernetes的规范，可能一开始看起来像是消防水龙带但本质上是深思熟虑之后的设计原则，这原则不仅为软件开发展示适当的方法考虑，还为每一个从ops到管理系统的不论重要还是辅助的应用程序组件都考虑到了。