在所有软件依赖操作系统平台的时代，数据中心已经确立了其目的和功能，Kubernetes的功能显得并不那么显著。Kubernetes是一个大规模的、正在进行的软件资源重组的产物，这些资源共同组成了一个网络应用程序。这种一致性围绕一个称为workloads的概念展开，workloads是一个或多个应用程序或者一个或多个服务跨多个处理器执行工作的广义概念。
“您可以将Kubernetes视为应用模式的平台，”Google软件工程师Janet Kuo在KubeCon 2017大会专题会场上解释道。 “这些模式使您的应用程序易于部署，易于运行，并且易于继续运行。”
虚拟机的衰落
越来越多的数据中心基础设施致力于关注workloads的健康状况，而不是服务器的健康状况。无论它们是物理处理器还是虚拟机，服务器都可能失败。故障对这些workloads的可用性和功能的影响应该小于最小阈值——它们看起来根本不应该受到影响。直到2016年，开源社区已经提出了一些方法来协调workloads，以获得最大的可用性。在很短的时间内，Kubernetes成为了在开源领域进行投资的企业的选择。至于原因，足够写一本完整的书，如果写得足够好，说不定它还可以被改编成一部艺术影院电影，赢得评论家的青睐，不过却永远无法赢得奥斯卡奖。
也许，这是唯一重要的原因：谷歌早期推动Linux基金会建立云原生计算基金会（CNCF）的举动给了Kubernetes足够的时间在最广泛的人群中有机地培养一批追随者。整个开源商业模式围绕着支持的价值。那些不再希望被局限于单一供应商的企业（诚然，并不是所有的企业）欣赏支持系统中多元化的新价值。一群供应商的行动（如果不总是一致地），至少在同一目标上进行一些协调，则优于单一供应商，在没有特定方向的情况下领导垄断的平台。
为什么现在Kubernetes兴起？
Kubernetes不属于任何一家公司，尽管它基于一个名为Borg的项目，最初是在谷歌内部开发的，谷歌通常被认为是Kubernetes开发社区的实际领导者。也就是说，微软已经完全围绕Kubernetes重新调整了它的整个服务器系统理念，并雇佣了几个主要的创建者。作为一个开源项目，Kubernetes由Linux基金会的一个代理机构——云原生计算基金会（CNCF）管理。谷歌最初设计Borg是为了适应它自己的内部用途。因此，以谷歌的搜索引擎本身为例是非常公平的：在搜索查询中搜索匹配条目的基本工作是由数百个（可能是数千个）分担责任的单个服务执行的。我会说“数不清”，但这不仅是错误的，而且与Kubernetes的观点相反。它确实统计了整个网络中组成活动作业（或作业）的所有服务和组件。
Docker是不是和这个有关？
遗憾的是，对于包含这些分布式程序片段的容器来说，目前没有比“容器”更好的术语了。(有一段时间，我们称这些东西为“Docker Containers”，以区别于“Tupperware containers”，但如今，Docker只是容器生态系统的一部分；另外，容器的格式不止一种。如果您熟悉ZIP文件，它使用数学压缩将多个文件组合成一个文件，那么您已经对现代软件容器有了相当多的了解。它们实际上使用相同的方法将多个文件压缩在一起。这些文件仅由程序需要运行的可执行元素和数据组成，而不需要查看网络中的其他地方。这些元素中的一个可能实际上是一个小型操作系统——通常是Linux的微型化版本，或者来自微软（Microsoft）， Windows的一个小亲戚，名为Nano Server。为此容器化部署方法（例如搜索查询响应）编写的程序可以查看缓存网页的索引以查找尚未选择的条目，检查该条目的语义上下文以匹配查询的内容，对结果进行排名，并将其注册在列表中以供以后收集和检索。 该程序将终止。这是分布式服务的一个特征，它使它与PC应用程序如此不同：它满足请求然后停止。 它知道它是更广泛工作的一部分，所以一旦它履行其功能，它就不复存在了。 软件工程师借用现代哲学的概念来描述这一方面：Ephemeralism。 与基于GUI的应用程序不同，它实际上花费大部分周期等待其用户的响应，短暂服务实现其功能然后到期。
在一个容器化的网络中（再次表示遗憾，没有更好的词来描述），程序彼此孤立地运行。 即使它们可能共享相同的处理器和内存空间，容器外部的主机操作系统也会保持其分离。 （从理论上讲，这种联合依赖是可利用的，尽管自然条件下还没有已知的威胁）通信只能通过软件定义的网络在容器之间进行。 更复杂的SDN将战略性地为这些容器提供网络地址，同时考虑如何将它们收集在一起以执行共同的工作。
ORCHESTRATE WORKLOADS是什么？
这是orchestration的使用场景。与“container”不同，“orchestration”这个词完美地描述了Kubernetes所扮演的角色。虽然有些人已经用乐队指挥来说明这个概念，但是在音乐和分布式应用中，指挥家和orchestrator之间存在着很大的区别。orchestration的行为为单个应用程序提供了协同工作的模式，就像乐队中的乐器一样。当作曲家创作出软件的原始模式，包括它的旋律线条和节奏（组装一个软件容器的术语实际上是作曲）时，管弦乐师会让乐曲听起来。“这就是为什么我称Kubernetes为‘可组合的平台’的原因，”在最近一次公司网络研讨会上，Red Hat的产品策略总监Brian Gracely解释道。“它应该是什么样子，有某种框架——其中一些来自Kubernetes社区，一些来自社区多年的经验，关于如何部署应用程序。”
orchestrator的主要工作是在其信任下维护应用程序的运行状态。在另一个时代，这项工作被委托给了操作系统。但那时候，这个平台还是一个只有一个存储库和专用存储设备的处理器。现在，没有什么东西可以将容器化的服务与应用程序的更广泛的上下文关联起来。实际上，协调器获取所有这些服务的功能和工作产品，通过某种形式的manifest来组织它们，并提供某种应用程序的外观。更改manifest，您可能会得到一个完全不同的应用程序。
Kubernetes与其他类型的应用程序在结构上没有区别。它不是虚拟机。它的orchestrator 在操作系统上运行。在运行时，它维护一个节点集群，这是引用物理或虚拟服务器的一种更抽象的方式。每个节点上都有容器的pods 。在它们的每个内部都有一个称为kubelet的客户端代理，它代表orchestrator 独立地管理分配给它的节点的函数。但即便如此，这也是一个和其他项目一样的项目。
所以Kubernetes不像Hadoop，它真正地重构了在服务器上运行的应用程序的结构。尽管如此，orchestrator 带来的分布式模型与2016年之前流行的模型有很大不同。部署模式不会随着时代而改变，比如时尚方向、个人口味或政治取向等。如果我们诚实的话，Kubernetes的突然崛起并不是因为世界上所有企业突然意识到需要在云计算中加入一些应用程序。Kubernetes是谷歌需要在数万个节点上管理其全局可访问的workloads的产物。世界上很少有其他组织类似于谷歌，或者拥有谷歌的数据中心概要。并不是每家公司都有自己的搜索引擎——如果你仔细想想，这就是谷歌存在的原因。
分布式系统的吸引力
那么，为什么Kubernetes或container orchestration对企业这么大吸引力呢?它真正吸引人的原因与workloads 本身无关，更多的是与围绕它们的开发和部署模型有关:- 连续性——当应用程序由粒度组件组成时，通过单独更新和改进这些组件，应用程序就更容易按粒度演进。协调器可以根据各个更改对整体workloads的影响做出适当的调整。应用程序的特性改进不再需要在大规模的检修中实现——这通常会对其可用性产生负面影响。持续集成和持续交付的概念(CI/CD，“D”通常表示“部署”)可以通过一个平台更容易地实现自动化，这个平台从一开始就被设计成理解部署本身的更小、更易于管理的步骤。
- 弹性——Kubernetes维护容器组的活动副本(称为replica
sets)，目的是为了在任何容器或容器分组(Kubernetes称之为pod)失败时保持正常运行时间和响应能力。这意味着数据中心不必复制整个应用程序，并触发负载均衡器，以便在主应用程序失败时切换到辅助应用程序。实际上，复制集中的多个pod通常在任何时候都在运行，协调器的工作是在应用程序的整个生命周期中保持这种多元性。 - 可伸缩性——对于使用Kubernetes协调分布式workloads的组织来说，最大的好处是，根据预先设置的策略，workloads 可以在系统中按需成倍增长，从而再次进行伸缩。为了减少混乱的可能性，Kubernetes把相关的容器组合成一个pod。可以将名为autoscaler的服务设置为自动将pods复制到不同节点，因为它确定分配给这些pods的资源没有得到尽可能多的利用。
KUBERNETES 是平台，还是其他什么？
到底Kubernetes和VMware vSphere谁是平台，仍然存在一些不确定性。不可否认，Kubernetes是一个“引擎”，是为分布式软件系统提供动力的主要元素。然而，Kubernetes并不提供这些元素本身，正如Windows的前辈MS-DOS最初并不提供自己的硬盘优化器或备份过程一样。
但正如许多用户会断言的那样，Kubernetes是一个平台的中心，这个平台可以由任意数量的能够协同工作的服务组成。有人说今天的CNCF是维护的目的,整理和培养其他独立的多元性,开源项目——例如,监控系统,如Prometheus,日志数据经理如Fluentd(不是一个错字),和信任的内容的身份验证器等公证,可能共同组成一个平台。在撰写本文时，CNCF已经认证了59个发行版，其中许多都是商业发行版，其中包括协调器以及其他CNCF工具或其供应商自己的工具。
“你会发现Kubernetes没有提供所有这些东西，”Red Hat优雅地说。“他们都是地方社区,通过不同的供应商,通过开源插件项目,给予市场很多的选择,给他们选择,让他们可插入性为这些不同的元素,并允许公司最终决定,在这个更广泛的框架,如何构建最好的平台,我们想做什么,为我们挑选最好的有意义的部分,但仍拥有一切的互操作性和可支持的?”
然而，正如Gracely的评论本身所表明的那样，由于这些集合的任何一个产品都无疑是一个平台，而Kubernetes是其中心的推动者，那么所有这些结果都应该是“Kubernetes平台”。Red Hat的OpenShift就是一个突出的例子，还有最新2.0版本的Rancher。
大到何种程度？
不论Kubernetes被数据中心经理和CIO认为是一个平台还是一个引擎，这都不是问题。如果orchestrator 要继续在企业中取得进展，就不能把它看作是实验室的实验，或者开发人员喜欢但没有人理解的疯狂工具之一。“引擎”意味着需要一个完整的底盘(或者，借用我的另一个gig中的一句话，一个“新堆栈”)，因此给一些评估人员造成这样的印象，即它在设计上是不完整的。一个平台必须为企业提供这样的方向:它很快就能承载所有的应用程序，而不仅仅是带有curly-Q和microservices的流行的应用程序。由于这个原因，CNCF一直将Kubernetes作为一个平台，能够通过容器化的方式承载新旧应用程序，即使将旧的应用程序从虚拟机转移到容器的好处还有待评估。
与分布式模型相比，预容器时代应用程序的定义特征之一是它们不能被分解、细分或缩放。现代开发人员将这种应用程序称为整体应用程序。在最近的一次开源峰会上，CNCF执行董事Dan Kohn吹嘘了一种被称为"lift-and-shift."的整体过渡模式的优点。
他将其定义为“一个概念，即你可以使用任何一个软件，你可以把它包装在一个容器中。”我们被训练成把容器看作是非常小的东西，只有最少的库，和最少的需要运行的软件。但是如果你有一个8g的Java应用程序，你可以用一个容器来包装它。甚至在你把它移到云计算之前，将它包含在其中就会为你创造一些价值。
各企业在起跑线发力
bargain Kohn和其他Kubernetes支持者提出企业是基于平台，基于Kubernetes或与Kubernetes集成的平台至少能够支持预先存在的应用程序 - 尽管是在不同的背景或主题中 - 同时它是 值得信赖，迎来这个全新的基础架构。帮助CNCF实现其目标的将是一组新的基于云的公共平台，用于承载应用程序，尽管将容器而不是VM作为业务模型的基础。谷歌Kubernetes引擎(GKE,前谷歌容器引擎),Azure Kubernetes服务(部,以前Azure容器服务),IBM Cloud Kubernetes服务(原IBM Bluemix容器服务),亚马逊Kubernetes弹性容器服务, Pivotal Container Service(PKS,也许你感应一个主题与“K”代表“C”字),以及最近VMware Kubernetes引擎,所有人都在推进突然非常真实的概念，即容器即服务(CaaS)，作为PaaS的一种进化形式。所有这些都是除了Red Hat的OpenShift Online之外的内容，OpenShift是早期与Kubernetes共同开发CaaS概念的先驱。
现在，您可以使用Docker组合一个容器，而这些CaaS平台中的任何一个都可以在自己的Kubernetes集群上承载该容器。在所有这些情况下，容器都将VM替换为消费单元，因此您不再需要站在云上自己的虚拟基础设施上，只需运行应用程序。
这就是Kubernetes革命将会得到巨大回报的地方。到目前为止，基于云的资源交付仅用于托管应用程序，而不是用于安装应用程序的虚拟化操作系统，这是一个非常健康的市场。这是一个如此健康、如此突然的市场，VMware只能加入，别无选择。随着新的、非单块的应用程序在公共云中不断成熟，这个市场成功的标志将是企业将在多长时间内不再担心是否或如何实现“lift-and-shift.”。
本文转自DockOne-什么是Kubernetes，以及Orchestration如何重新定义数据中心