在本文中，我们从技术细节中抽离出来，从更抽象的层面上评估一下为什么容器、Kubernetes以及它呈现出的编程范式值得你去使用和整合到自己的技术栈中。

我们的目标是在如何审视和可视化你的基础设施这个问题上，提供一个全局观，进而理解本文标题的精髓：Kubernetes为什么很重要？

文章概要

引言

● Kubernetes的根源 ● Kubernetes为什么很重要 ● 功能 ● 角色 ● 大局观 ● 结论 ● 引言

Kubernetes的目的是成为容器的管理平面，同时它一直致力于满足真实世界中app运行和依赖的环境需求。一些例子能够说明Kubernetes能为app提供了什么，比如：存储卷访问、负载均衡、冗余、弹性伸缩、发布更新、以及配置和敏感内容的管理。

应用为中心的实践（而非服务器为中心），正是有了上面提到的kubernetes的能力和特性，加上docker等容器引擎提供的打包功能，才得以快速发展。

Kubernetes的起源

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设计上的前瞻性有助于重新定义应用程序的构建。

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概述

为了让您对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/