本文翻译自《What is Kubernetes? How orchestration redefines the data center》。
在短短四年多的时间里，派生于谷歌内部容器管理平台的项目已经颠覆了VMware，微软，甲骨文精心布局的计划以及其他所有以称王为目标的数据中心。那么改变一切的究竟又是什么呢？
对于那些对数据中心建立的目的和功能的概念还停留在操作系统才是所有软件所依赖的平台的时代的人来说，Kubernetes的目的并不是显而易见的。Kubernetes是软件资源的大规模持续重新调整的产物，这些资源共同构成了网络应用程序。它以工作负载的概念为中心，工作负载是一种广义概念，可以是横跨众多处理器的一个或多个应用程序执行的作业(job)，又或一个或多个服务执行的作业。
工作负载是一项作业(job) - 例如，管理供应链，监督物流，跟踪库存，促进证券市场。Kubernetes已成为现如今这个时代的作业控制系统。
“您可以将Kubernetes视为一个应用模式的平台，”Google软件工程师Janet Kuo 在KubeCon 2017大会的辅导会议上解释道。“这些模式使您的应用程序易于部署，易于运行，并且易于持续运行。”
虚拟机的优势正在下降
越来越多的数据中心基础架构旨在专注于工作负载的健康，而不是服务器的健康。无论是物理处理器还是虚拟机，服务器可能会宕机。该故障对这些工作负载的可用性和功能的影响应该小于最小 - 它们根本不应受到影响。
直到2016年，开源社区已经提出了一些方法来协调工作负载以实现最大可用性。在很短的时间内，Kubernetes成为了开源投资企业的选择。至于原因可以写成一本完整的书，如果写得好，它完全可以被改编为一部赢得评论家而不是奥斯卡奖的艺术剧院电影之一。
在这里，或许是唯一重要的原因：谷歌早期推动Linux基金会建立云原生计算基金会（CNCF）的举动让Kubernetes有足够的时间在最广泛的人群中有机地培养追随者。整个开源业务模型围绕着支持的价值。不再希望被锁定在单一供应商的企业都很欣赏支持系统中多元化的新发现价值。一群供应商，如果不是总是一致的话，至少对同一目标进行一些协调，是优于单一供应商在没有特定方向的情况下领导的垄断平台。
为什么Kubernetes现在很重要
Kubernetes并非由任何一家公司所有，尽管它基于一个名为Borg的项目，该项目最初是在Google内部开发的，而Google通常被认为是Kubernetes开发社区的事实领导者。也就是说，微软已经彻底改变了Kubernetes的整个服务器系统理念，并聘请了几位主要创作者。作为一个开源项目，Kubernetes由Linux基金会的代理机构Cloud Native Computing Foundation（CNCF）管理。
谷歌最初设计Borg来满足自己的内部需要。因此，使用谷歌的搜索引擎本身作为一个例子是非常公平的：在搜索查询中搜索匹配条目的基本工作是由数百甚至数千个共同负责的个体服务完成的。我可以说“无数”，但这不仅是错误的，而且与Kubernetes的整个观点相反。它确实在整个网络中统计构成活动作业或作业(s)的所有服务和组件。
DOCKER与此无关吗？
遗憾的是，对于那些包含这些分布式程序的容器来说，目前没有比“容器(container)”更好的术语。（有一段时间，我们称这些东西为“ Docker容器”，这是为了将它们与“特百惠容器区别开来”，但今天，Docker仅包含容器生态系统的一部分而已;此外，还有多种容器格式。）如果您熟悉ZIP文件，就是那种使用数学压缩将几个文件混合组合成一个文件的文件格式，你就已经对现代软件容器有了很多了解了。它们实际上使用相同的方法将几个文件压缩在一起。这些文件只包含程序运行所需的可执行元素和数据，这些元素中的一个实际上可能是一个小型操作系统 - 通常是Linux的小型化版本，或者是来自Microsoft的一个名为Nano Server的微小Windows 。
为此容器化部署方法（例如搜索查询响应）编写的程序可以查看缓存网页的索引以查找尚未选择的条目，检查该条目的语义上下文以匹配查询的内容，对结果进行排名，并将其注册在列表中以供以后收集和检索。最后该程序将终止。这是分布式服务的特征之一，使其与PC应用程序如此不同：它满足请求然后停止。它知道它是更广泛作业的一部分，所以一旦它履行完其功能，它就不复存在了。软件工程师借用现代哲学的概念来描述这一特征：短暂性。与基于GUI的应用程序不同，GUI程序实际上花费大部分周期等待来自其用户的响应，而短暂服务实现其功能后到期(退出)。
在一个容器化的网络中（再次，很遗憾，但没有更好的词），程序是彼此隔离的。即使它们可能共享相同的处理器和内存空间，容器外部的主机操作系统仍保持其分离。（从理论上讲，这种联合依赖是可利用的，尽管目前还没有已知的威胁利用。）通信只能通过软件定义的网络在容器之间进行。更复杂的SDN将策略性地为这些容器提供网络地址，同时考虑如何将它们聚合在一起以执行共同的作业。
编排工作负载意味着什么
这是编排走上舞台的地方。与“容器”不同，“ 编排 ”这个术语完美地描述了Kubernetes扮演的角色。虽然有些人使用乐团指挥说明了这个概念，但是在音乐和分布式应用中，指挥和编排器之间存在很大的差异。编排行为规定了各个应用程序协同工作的模式，相互协调 - 就像乐队中的乐器一样。当作曲家产生软件的原始模式，包括其旋律线和节奏（组装软件容器的术语实际上是组合）时，编排器让其发声成为可能。
“这就是我将Kubernetes称为'可组合平台'的原因，”Red Hat产品战略总监Brian Gracely在最近的公司网络研讨会上解释道。“它有一个应该是什么样子的框架 - 其中一些来自Kubernetes社区，其中一些来自社区多年和多年的经验，如何部署应用程序。”
编排器的主要工作是维护其信任的应用程序的运行状态。在另一个时代，这项工作被委托给操作系统。但那时平台是一个单处理器，只有一组内存和专用存储设备。今天，将容器化服务与任何更广泛的应用程序环境实质上联系起来并不多。实际上，正是编排器采用了所有这些服务的功能和工作产品，通过某种形式清单组织它们，并定义了一些应用程序的外部入口。更改清单，您可能会有一个不同的应用程序。
Kubernetes与任何其他类型的应用程序没有任何结构上的独特之处。它不是虚拟机。它的orchestrator在一个操作系统上运行。在运行时，它维护一个节点集群，这是一种更抽象的方式来引用可能是物理或虚拟的服务器。在每个节点上都有容器的Pod。在每个节点上中都有一个名为kubelet的客户端代理，它代表编排器独立管理功能，并用于其被分配的节点。但即使它也是一个与其他任何项目一样的程序。
所以Kubernetes不像Hadoop，它真正改造了服务器中运行的应用程序的结构。尽管如此，这个编排器带来的分布式模型与2016年之前流行的模型截然不同。部署模型不会随着时尚，美食或政治平台等时代而变化。如果我们说实话，Kubernetes突然崛起并不是因为世界上所有企业突然意识到需要在云端投入少量应用程序。Kubernetes是Google需要使其全球可访问的工作负载在数万个节点上可管理的产物。世界上很少有其他组织类似谷歌，或者拥有谷歌的数据中心档案。并非每家公司都有自己的搜索引擎 -
分布式系统的吸引力
那么，为什么Kubernetes或容器编排确实对企业有任何吸引力呢？其真正吸引力的原因与工作负载本身关系不大，而且与周围的开发和部署模型有很大关系：
连续性 - 当应用程序由一定粒度的组件组成时，通过单独更新和改进这些组件，可以更加轻松地演进该应用程序。编排器可以根据这些个别更改对整个工作负载的影响进行评估和适当调整。而不再需要对应用程序进行功能改进才能进行大规模的大修 - 这通常会对其可用性产生负面影响。持续集成和持续交付的概念（CI / CD，“D”通常代表“部署”）更容易通过一开始就以更小、更易于管理的步伐而设计的平台实现自动化。
弹性 - Kubernetes维护容器组的活动副本组，称为副本集。用于表述在任何容器或容器分组（Kubernetes称为pod）失败的情况下保持容器正常运行时间和响应性。这意味着数据中心不必复制整个应用程序，并在主要应用程序发生故障时触发负载均衡器切换到辅助应用程序。实际上，副本集中的多个pod通常在任何一个时间运行，并且编排器的工作是在应用程序的整个生命周期中保持多个。
可扩展性 - 根据预先设定的策略，使用Kubernetes协调分布式工作负载的组织的巨大回报是工作负载在必要时通过系统内置能力实现倍增 - 再次扩展和缩减。为了最大限度地减少混乱的可能性，Kubernetes将相关容器组合在一起作为pod。一个可以称为自动缩放器的服务可以设置为自动将pod复制到不同的节点，当它确定分配给这些pod的资源没有尽可能多地使用时。
KUBERNETES是平台还是其他什么？
与Microsoft Windows平台或VMware vSphere是一个平台先比，Kubernetes是否是一个平台仍然存在一些不确定性 - 平台应该是可以提供所有托管软件高效运行所需的所有服务和资源。但不可否认，Kubernetes是一个“引擎”，是为分布式软件系统提供动力的主要元素。然而，Kubernetes本身并不提供这些元素，就像Windows的前任MS-DOS最初没有提供自己的硬盘优化器或备份程序一样。
但正如许多用户所声称的那样，作为有效的引擎，Kubernetes是一个平台的中心，平台则是由任意数量的能够串联工作的服务组成。有人会说今天的CNCF的目的是维护，编组和培养多个其他独立的开源项目 - 例如，Prometheus等监控系统，Fluentd（不是拼写错误）等日志数据管理器，以及可信内容验证器，例如Notary - 可以共同构成平台。在撰写本文时，CNCF已经认证了59个发行版，其中许多是商业版，其中包括编排器以及其他CNCF工具或其供应商各自的工具。
“你会发现Kubernetes没有提供所有这些东西，”Red Hat的Gracely说道。“通过不同的供应商，他们是社区的所有领域，通过开源附加项目，为市场提供了很多选择，给予他们选择，让他们可以插入这些不同的元素，并允许公司最终决定，在这个更广泛的框架内，我如何为我们想要做的事情构建最佳平台，选择对我们有意义的最佳作品，但仍然可以互操作和支持？“
然而正如Gracely的评论本身所表明的那样，由于任何这些系列的产品无疑是一个平台，而Kubernetes是其中心的推动者，因此所有这些结果都应该是“Kubernetes平台”。红帽的OpenShift就是一个突出的例子，最新的2.0版Rancher也是。
单体程序的去向？
无论Kubernetes被数据中心经理和CIO视为平台还是引擎，都不是一个深奥或微不足道的事情。如果编排者要继续在企业中取得进展，它就不能被视为实验室实验，或者是开发人员喜爱但却没有人理解的那些疯狂工具之一。“引擎”意味着需要一个完整的底盘（或者，从我的另一个演出借用一个短语，一个“新的堆栈”），从而给一些评估者一种设计不完整的印象。
平台必须为企业提供希望，它可以很快托管其所有应用程序，而不仅仅是带有卷曲Q和微服务的时髦应用程序。出于这个原因，CNCF已经将Kubernetes作为一个平台，能够通过集容器化方式托管新旧应用程序，即便从虚拟机到容器的旧应用程序转移的好处还有待评估。
与分布式模型相比，容器化时代之前的应用的一个明确特征是它们无法分解、细分或缩放。现代开发人员称这些应用程序是单体的。在最近的一次开源峰会期间，CNCF执行董事Dan Kohn吹捧了称为“升力换挡”的整体式过渡模型的优点。
他将其定义为“您可以实际使用任何软件编写的概念，并且可以将其包装在容器中。我们已经训练过将容器视为这些非常精致的东西，只有最少的库并且确切地说是运行所需的最小软件。但是如果你有一个8GB的Java应用程序，你可以用一个容器包装它。只是容器化它的行为，实际上确实为你创造了一些价值，甚至在你之前把它移到了云端。“
在起跑门聚集起来
讨价还价的Kohn和其他Kubernetes支持者向企业提出的建议是，基于Kubernetes或与Kubernetes集成的平台至少能够支持已有的应用程序 - 尽管是在不同的背景或主题中 - 同时它是值得信赖，迎来这个全新的，看似陌生的建筑。
帮助CNCF实现其目标将成为托管应用程序的一系列基于公共云的平台，尽管使用容器而不是VM作为其业务模型的基础。 Google Kubernetes Engine（GKE，以前的Google容器引擎），Azure Kubernetes服务（AKS，以前的Azure容器服务），IBM Cloud Kubernetes服务（以前的IBM Bluemix容器服务），Kubernetes的亚马逊弹性容器服务（EKS），Pivotal Container Service（ PKS，也许你感觉到一个主题是“K”代表“C”字，最近的VMware Kubernetes引擎，所有这些都是非常真实的容器即服务（CaaS）概念，推进着PaaS的演变形式。所有这些都是Red Hat的OpenShift Online的补充，它早在Kubernetes就开创了CaaS概念。
现在，您可以使用Docker组合容器，并使用任何这些CaaS平台在自己的Kubernetes集群上托管该容器。在所有这些情况下，容器将替换VM成为消耗单位，因此您不再需要在云端站在自己的虚拟基础架构之上，您只需运行应用程序即可。
这是Kubernetes革命获得回报的地方。截至目前，在托管应用程序的基础上提供基于云的资源的市场非常健康，而不是安装它们的虚拟化操作系统。它是如此健康，如此突然的市场，VMware除了加入它之外别无选择。随着新的，非单一的应用程序在公共云中产生，培育和成熟，这个市场成功的标志将是企业多久不再担心是否或如何实施提升和转移。
-------
讲师主页：tonybai_cn
实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》
免费课：《Kubernetes基础：开启云原生之门》