(Source: Google)
在本文中，我们从技术细节中抽离出来，从更抽象的层面上评估一下为什么容器、Kubernetes 以及它呈现出的编程范式值得你去使用和整合到自己的技术栈中。
我们的目标是在如何审视和可视化你的基础设施这个问题上，提供一个全局观，进而理解本文标题的精髓：Kubernetes 为什么很重要？
引言
● Kubernetes 的根源
● Kubernetes 为什么很重要
● 功能
● 角色
● 大局观
● 结论
● 引言
Kubernetes 的目的是成为容器的管理平面，同时它一直致力于满足真实世界中 app 运行和依赖的环境需求。一些例子能够说明 Kubernetes 能为 app 提供了什么，比如：存储卷访问、负载均衡、冗余、弹性伸缩、发布更新、以及配置和敏感内容的管理。
应用为中心的实践（而非服务器为中心），正是有了上面提到的 kubernetes 的能力和特性，加上 docker 等容器引擎提供的打包功能，才得以快速发展。
Kubernetes 最初起源于 Google，它的前辈有 Borg 和 Omega。这些系统的很多设计和实现理念都已经以不同的形式融入到 kubernetes 中，其中包括今天分布式系统的标准，也包括 Google 在过去很多年里积累下的最佳实践。
Kubernetes 最初被认为是 Borg 或 Omega 的 “开源版”，事实并非如此。Kubernetes 是一个全新的管理工具，专为 job 和 service 设计。它是完全开放的，任何人都可以提供意见。
Kubernetes 最初充分利用了 Google 多年的架构和运维经验。2014 年 6 月开始接受公开的 commit，后被证明能够充分简化开发、运维和管理负荷，很快吸引了一大批追随者和贡献者。
下图是社区活跃度快照：
(Source: Google)
(Source: Google)
(Source: RedMonk)
这些图表充分展示了一个真实、独特和协作的技术社区。
>>>>认同
我们刚才已经提到，已经有大量的个人和企业认可 Kubernetes。然而，真正的问题是，你是否愿意使用 Google 的方式运行你的应用和服务。
我的意思是说，Kubernetes 不只是容器管理系统，通过它你可以深入了解谷歌是如何运作他们的基础设施的，这些基础设置支撑了 Gmail、搜索、地图、甚至是谷歌云引擎（GCE）等产品。
相应地，通过 Kubernetes，你可以学习 Google 运行应用的方式。也就是说，你需要遵循一组约定俗成的设计原则，使您的应用程序能够高效地工作，具有良好的记录，能够轻松地扩展、管理您的应用程序。这并不意味着抛弃 OpenStack 或 AWS 等处理 IaaS 资源的工具，只是意味着这些系统留在原地做他们最拿手的工作，然后引入 Kubernetes 来满足您所有的应用程序需求。最终，集成 Kubernetes 和您喜爱的组件。
因此，如果你考虑在当前的技术栈中使用 Kubernetes，你必须信赖该项目所给予的基础和范式：从 Pod 开始，其它概念自然就接受了。这样做，将会使功能和灵活性达到空前的结合，此外，Kubernetes 设计上的前瞻性有助于重新定义应用程序的构建。
在一篇关于 ACM、Borg、Omega 和 Kubernetes 的最新论文中有详细的说明，Kubernetes 可以帮助建立一个工具集，帮助管理&扩展您的应用程序和团队。
Kubernetes 改进应用程序开发的方法如下︰
>>>>功能
● 容器封装了应用环境，从应用程序开发者和部署基础设施中抽象掉很多机器和操作系统的细节。容器封装了应用运行环境，将机器和操作系统从开发人员和基础设施的许多细节中抽象出来。
● 将管理 API 从机器为中心转变为应用为中心，极大优化了应用部署和回滚的体验，数据中心的” primary key” 也由” 机器” 转变为” 应用”。
● API 向应用为中心迁移，团队不再需要关心特定机器和操作系统。
● 关注于跨机器的应用程序，允许团队以更灵活、细粒度、模块化的方式进行开发和运维。
Kubernetes 的常用模式是，Pod 用来承载一个应用实例，而不是一个模块或复杂的应用。这个实例可以由一个小团队去开发和维护。
Kubernetes 其他组件都是建立在 POD 概念上的，如 ReplicaSets、Deployments、Services 等，从而大大简化应用程序需求、业务策略和团队的协调工作。你可以充分 Kubernetes 中的概念，这些概念不仅与 POD 交互，还允许你为应用程序添加更多的功能和特性。
>>>>角色
Kubernetes 也会通过吸引到大量的不同的角色来协助你的组织：
1.开发者： 不仅可以创建多种多样的应用程序，还可以利用集群的内在特性实现应用程序的特殊要求
这专门针对某些应用场景。比如开发人员想要针对特定的节点、节点集合、或者能够代表不同硬件资源的特定标签，以便进行 Pod 级别的调度。举个例子，要把应用程序运行在 AMD 而不是 Intel 的 CPU 架构上，或者希望充分利用 GPU，甚至拥有超大内存的节点。
消费同质化机器组成的机组 Kubernetes 中是完全可行的。Kubernetes 的管理下，这些机器表现为为一个通用的计算资源池。
当作宠物还是牲畜，Kubernetes 的哲学不仅体现在管理应用程序上，也体现在管理机器上。
2.DevOps： Kubernetes 中 Deployments、ReplicaSets、Services 等概念，都有助于环节运维压力，它一方面保证每个应用程序拥有一个声明式的控制策略，另一方面保证这些规格和策略时刻被遵循。
3.管理员： 作为 Kubernetes 的一部分，管理员有权限使用 heapster 和 cadvisor 等工具管理容器资源的利用率、检查集群事件、API 请求、监控数据，并且使用一些新特性，比如 kubedash 进行分析。
多种不同的度量指标不仅能够帮助管理员了解 kubernetes 集群，也提供了应用程序粒度的数据。
在其它系统中，从应用程序层面进行数据分析需要用户自己去实现。Kubernetes 内置分析功能，并不是说为应用程序快速增长做准备，而是说这些分析信息是应用程序所必须的，你不应该自己去实现，而是由管理系统提供。
4.其他角色： 许多不同的角色可以在最基础的层面与 Kubernetes 交互，比如在进行其他操作（创建、查询）时使用 dashboard 对集群进行可视化。
为了让您对 Kubernetes 的运作机制有一个大局观，这里会用一些图来协助你理解这个项目的方方面面。
正如 James Burke 的格言一样：
以史为鉴，方能面向未来。
Borg 是 Kubernetes 的始祖，它创造的集群认知理论为 Kubernetes 的诞生提供了基础。
我们会从 Borg 论文中选取一些图标，这些图表不仅会帮助我们理解 Borg 的部署方式，也会说明同样的模型如何适用于 Kubernetes。
在这里，我们采用从自顶向下的方法，将云计算架构可视化：
（Borg 跨数据中心部署）
我们进一步放大，查看 DataCenter（DC Site）中的每个 Building 都包含至少一个 Borg 集群（Cluster），它表现为一个 Cell，包含大概 10000 台机器（Machine）：
(审视数据中心内特定的一个集群）
进一步放大，观察每个 Cell，可以发现控制平面组件（controll plane）与工作节点（workers/Nodes）是分离的。Borg alloc（与 Kubernetes Pod 类似）是应用程序或服务部署的唯一最小单元：
（审视数据中心内一个特定的 Cell）
现在你可能已经注意到了，某些组件在 Borg 和 Kubernetes 系统中并行存在，尤其是 1:1 比例映射的集群和 Pod 的构成 — — 考虑到联邦 Kubernetes 部署时，这些相似之处更有意思。
目前，虽然 Kubernetes 无法像 Borg 一样单个集群支撑 10000 个节点，但是最近的优化允许 Kubernetes 单个集群支持多达 1000 个节点和 30000 个 Pods，同时 99% 的 API 调用响应低于 1 秒、99% 的 Pods（镜像预先拉取）在 5 秒内启动。支撑规模是之前的 10 倍，Google 官方声称是 14 倍。
Kubernetes 无疑是最好的阶段，不仅因为很多公司将其用于生产环境（见上面的图），更是得益于它优异的性能和扩展性。
我们希望你能更好地理解 Kubernetes 的重要性，以及如何开始组织构建你的集群以允许 kubernetes 集成。
拥抱 Kubernetes 哲学最初看起来像补救技术债，但是它的设计哲学是经过深思熟虑的，展示的不仅是软件开发的正确方法，但对于从 ops 到管理等每个环节都很重要。
直到下一次！
本文由时速云翻译，如若转载，需注明转载自 “时速云”
原文链接：https://corekube.com/2016/03/31/why-does-k8s-matter/
