非技术咖眼中： Kubernetes 为什么那么重要？

摘要

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

简介

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

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

Kubernetes 的起源

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

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

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

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

导言

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

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

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

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

Kubernetes 为什么重要？

就像最近的关于 Borg 、 Omega 和 Kubernetes 的那篇论文里提到的细节， Kubernetes 帮助建立成套工具来辅助管理和缩放你的应用程序。

http://mp.weixin.qq.com/s?__biz=MzIzMzExNDQ3MA==&mid=402412524&idx=1&sn=61962944124a5372e7c105c1c6d16a9e&scene=21#wechat_redirect

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

功能

① 容器将应用环境封装，从应用程序开发者和基础设施层面抽象掉很多机器和操作系统的细节。

②管理 API 从面向机器转到面向应用程序，程序部署和检查极大提高，数据中心也由面向机器转向面向应用程序。

③应用程序 API 的转换可以让团队无需担心机器和操作系统的细节特性。

④专注于机器上的应用程序，这也允许团队以更灵活、更模块化的方式来操作。 原因是 Kubrnetes 是 pod 的常见使用模式实例，或者说是一个组件，是一个复杂应用程序中可以编写，运行以及被一个小团队全权负责管理功能的组件。

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

不同人员的任务角色

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

开发者（ developers ）：不仅可以创建通用的应用，他们还可以使用集群本质的属性来完成任何应用的特定需求。

在使用案例之中， devs 想要把一个特定的 Node 作为目标，或者将一组 Nodes 作为目标，表示不同的硬件细节的特定标签可以用于个人 Pod 调度。也就是，如果你想要在 AMD CPU （而不是 Intel ）架构上运行你的应用程序，或者你希望利用 GPU ，甚至是有大数量的 RAM 的 Node 。

消耗各种不同的机器在不仅在 Kubernetes 上是可能的，而且它事实上将所有的机器都拉平衡，并且将他们呈现为一个通用的计算资源。

这不仅由你的应用程序体现了 Pets vs. Cattle 的意识形态，你的机器也是。

运维（ Devops ）： Kubernetes 概念，比如像 Deployments ， replicaSets ， Services 等等，所有这些都会帮助减轻运维，确保每个应用都有一个描述性的系列业务政策，而且这些规格都是随时实施和维护的。

管理员（ Admins ）：作为 Kubernetes 的一部分， admins 可以通过使用例如像 Heapster 或者 cAdvisor 一样的工具来获得访问权和流程容器资源，同样的，检查集群的事件， API 请求，监测数据，和利用 Kubedash 做分析。

这些不同的软件度量不仅提供检测 Kubernetes 集群服务，而且还提供一个对这些应用程序自身的细粒度理解，因为他们都是单独控制的。如果不把一些复杂沉重的安装留给用户的话，很多在其他系统里的应用程序层面的分析是不可能完成的。这些在 Kubernetes 上的本地功能说明了项目的努力不仅是针对你的应用程序的增长，而且这个水准的信息是一个为你的应用程序确定的需求，你不该自己创建这个功能，而是该功能应该被通过系统提交给你。

其他：最近，许多不同的任务角色可以跟 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 当然是为“黄金时间段”准备的，不仅是因为许多 company 都在生产过程中使用，而且还单纯因为它的性能和规模。

结论

我们希望你能够有更好的理解在现今的软件发展时代“ Kubernents 为什么重要”的原因，也希望你能够更好理解如何组织以及构架你的集群来使之整合。去接受 Kubernetes 的规范，可能一开始看起来像是消防水龙带但本质上是深思熟虑之后的设计原则，这原则不仅为软件开发展示适当的方法考虑，还为每一个从 ops 到管理系统的不论重要还是辅助的应用程序组件都考虑到了。