什么是Kubernetes 您的企业需要知道的一切

什么是Kubernetes?

Kubernetes的定义在不断变化，因为随着它的不断发展，Kubernetes改变了它周围的世界。现在是2019年秋季版：Kubernetes是一种工作负载分配和编排机制，用于数据中心中的集群服务器，可确保同时提供多个服务的资源可用性，可访问性和均衡执行。

在这种方案中，Kubernetes可以同时使任意数量的多种服务器(相隔任意距离)共享公共租户的工作负载。然后，将这些工作负载作为服务呈现给客户端-意味着，客户端系统可以通过网络与它们联系，将一些数据传递给它们，然后等待一两分钟后，收集响应。

这是分布式数据处理，它通常在单个整体应用程序的范围内进行。Kubernetes使整个过程具有可观察性和可管理性。

在管理这些服务时，Kubernetes会根据需要更改网络的布局。随着越来越多的客户端提出某种类型或类别的工作负载请求，业务流程协调器使更多副本可用。同样，随着请求的减少，它减少了副本的数量。这是使Kubernetes声名fa起的过程，IT运营商分别称其为横向扩展和横向扩展。当服务细分为单独的功能或微服务时，它们通过网络而不是通过它们本来要共享的内存和处理器相互联系，Kubernetes可以横向扩展单个微服务，并随着需求的增加和减少而缩减它们。就像它们是完整的应用程序一样。

Kubernetes的商业案例

建立我们的业务，我们的商业系统以及社会的相当一部分的信息技术平台正在显示其时代。取代它们是一个收益大于成本的问题。正如任何正在努力应对5G无线过渡的电信服务提供商所证明的那样，组织很难证明更换整个基础架构的成本是合理的，除非其近期的商业模式能够接近保证盈利的水平。

Kubernetes不仅在论证业务盈利能力，而且还在提出一些测试案例来证明自己。越来越多的证据表明，组织为维护其现有基础架构而付出的不断增加的成本正变得越来越不合理：

云基于第一代虚拟化，该虚拟化已过时，并且可能在适当时候变得无关紧要。通常会安装在服务器主硬盘上的软件映像会呈现在远程服务器的内存和存储中，以便软件可以像以前一样在此处运行。现在，无需像以前一样运行软件。即使在大型多人在线游戏的基础专有平台是其制造商专有领域的情况下，继续生产整体应用程序的商业案例也已消失。

Internet是使用域系统映射的，该域系统将地址映射到其注册所有者，而不是所使用的功能和服务。 服务网格将那些地图与更相关的地图覆盖在一起，从而使分布式应用程序可以在分散的网络上相互查找。这些服务网格与Kubernetes紧密绑定，在工作负载编排之后提供了系统中第二重要的服务。

移动设备依赖于向客户端分发“智能”功能的移动应用程序，主要是为了最大程度地减少客户端和服务器之间交换的信息。随着无线带宽不再是一种高级商品，将功能转移回服务器端可能变得更加实用和更具成本效益，从而使新型设备比以前的设备明显“笨拙”-尽管功能非常强大相机-可以以更高的速度完成相同的任务。

公共云数据中心是大型的“超大规模”设施，可同时为数以万计的租户提供服务，通常距离数百英里。对于可分配性更高的计算，拥有更多，更小且分布在更靠近其用户的更小数据中心可能变得更加实用和合乎需要。

人工智能构成了上层软件，主要是因为其在内存，存储和其他资源上的成本相对较高。使用分布式服务模型，其中包括无数个容器，每个容器都具有较小的占地面积，就可以得出更好推断的软件(例如，“寻找30码以外的那棵树!”)而言，人工智能可能变得更加普遍。被称为“智能”，而不是被称为“标准操作设备”。

容器化使业务软件更易于管理。 在基于服务器的计算的上下文中，容器是一个软件包，可以使工作负载虚拟化(可移植，自包含，独立运行)，同时仍由操作系统(与虚拟机管理程序相对)托管。通过将应用容器化，可以使现代应用程序在服务器之间移植，这不仅与打包部署有关。在容器化环境中，从存储库(某些公共的，另一些私有的)中检索或“拉出”软件代码，然后立即在生产环境中部署和运行。这种自动部署方法不仅可以每18个月左右(甚至可能每天)对软件进行一次改进，不仅可以由其创建者而且可以由用户对其进行改进。反过来，这极大地提高了数据中心系统的完整性和安全性。

“编排”是什么意思

编排是有效管理和执行同居IT平台的多个工作负载。在Kubernetes的情况下，某些工作负载可能已到达已经细分为微服务的平台上。他们仍然一起工作，但作为独立单位。Kubernetes编排使这些单元可以根据需要进行复制和重新分配，并在不再使用时逐步淘汰。

像乐队指挥一样?

比喻是错误的。指挥确保以适当的时间和节奏执行乐曲。在数据中心，操作系统继续扮演这个角色-Kubernetes不会改变这一点。协调器协调合成中所有部分的执行，以实现最大的效率和流畅的性能，因此一个部分不能淹没另一部分，并且所有部分都可以有效地发挥其作用。由于这些零件可能在多个位置之间广泛分布，因此协调员还聚集了零件可能需要用于完成手头同一任务的所有资源。

与操作系统中的协调器形成对比

除了别的以外，计算机上的操作系统使由其处理器安全地并按预期执行程序成为可能。Kubernetes同时为多个工作负载履行该角色，这些工作负载分布在集群中的多个服务器之间。

这并不是说Kubernetes是已扩展的操作系统。操作系统仍然扮演着编组每个程序执行的角色。在容器化环境(至少是其最初设计的本机环境)中，每个容器的主机不是虚拟机管理程序(与vSphere或KVM一样)，而是操作系统。

但是，从一个方面来说，操作系统是单台计算机，编排器是服务器集群：它监督系统中的软件的执行，该系统的基础结构资源(其处理能力，内存，存储和网络设施) -已全部合并。Kubernetes在极短的时间内解决了数据中心希望使用哪个协调器的问题，例如解放科威特的盟军。像“沙漠盾牌行动”一样，Kubernetes的战略很简单，可以迅速执行。

所有软件都放在哪里?

在现代数据中心中，不需要在计算机上“安装”软件。相反，它更像是从图书馆借来的一本书，只有一本能够在借出之前出版该书。在容器化领域，此库称为注册表。从注册表借用的开源软件包放在完全组装好的容器中。通过注册表使应用程序或服务可用以引入Kubernetes管理的环境的行为称为部署。因此，当我们谈论“部署工作负载”时，我们指的是准备要交付给服务器群集的软件的行为，在服务器群集中对其进行管理和编排。

Kubernetes的构建旨在从注册表中检索工作负载包，将它们打包以在系统中进行部署，管理它们所监管的集群之间的分布以及管理对通过这些集群提供的资源的访问。

如果容器化可以具有如此糟糕的名称，为什么容器化如此重要?

容器化是由Docker Inc.正式开始的趋势，然后由Google推动其迅速发展，如今，该平台领域的大多数其他人(包括Microsoft和VMware)也加入了这种趋势。我们四年前被告知，这是数据中心管理的一个深奥的方面，日常用户不会注意到。但是，即使Netflix和Amazon Prime的每一位用户都无法确定其来源，但他们都亲身感受到了这种影响。将数据中心管理的重点从机器转移到工作负载，彻底改变了应用程序和服务的交付方式。

与其说听起来像是使特百惠派对工业化的一种方式，不如说是“容器化”，它可以被称为“工作量革命”。网络现在被路由到功能而不是机器。如果没有足够的现实世界比喻，很难在实践中看到此想法的重要性：您想起了多少个电话号码?既然智能手机具有联系人列表并且可以响应您的声音，您脑海中会出现更多还是更少的数字模式?

“工作量”业务是什么?

在计算机上运行的程序仍然是“软件”，它引用了NASA工程师最初在阿波罗时代创造的双关语。并且，应用程序仍然是旨在由多个用户操作并以名称引用的程序。

相比之下，“工作量”有点模糊。它由一个或多个软件组成。它可以使用一个数据库，尽管它可以与其他工作负载使用相同的数据库。它可能包含一个注册表中的多个程序包，这些程序包是即时组装并在集群 享功能。但是，它通常有一个主要目的，即使具有任何数量的复合部件，也可以作为一个内聚单元工作。

软件开发人员通常不会坐下来坐下来，就无法负担工作量。他们仍然在编写程序。但是，在部署围绕这些程序组装的容器的过程中，最终给协调器(如Kubernetes)的指令最终声明了活动工作负载的工作参数。因此，在部署过程中，软件成为工作量。可以衡量和减轻其对数据中心资源消耗的影响，就像可以衡量和减轻员工在人和事物的日常领域中的工作负荷的影响一样。

那么，什么是“服务”?

现代数据中心中的服务与应用程序完全不同。这似乎并不明智，因为应用程序通常被描述为执行有用的服务。但是从架构上讲，服务是一种软件，可以在给定指定输入并指向相关数据的情况下，产生一组可预测的输出。通常使用服务来查询数据库。

应用程序为其用户提供可以使用服务的环境(通常是视觉环境)。服务不必自己关心该功能。

今天，大多数精心策划的容器化程序都是服务。它们可能执行应用程序中最重要的业务，但是它们是独立的单元。微服务是独立的，独立的，自力更生的服务，往往很小(尽管最近，软件架构师认为，它们不一定如此)。协调器可以调用(或“实例化”)必要或允许的尽可能多的微服务克隆，以响应定向到微服务的请求。

API(最初是“应用程序接口”的缩写)是一组具有指定通信协议的服务。在网络计算中，API被设计为通常通过Web浏览器使用旨在将命令或语句中继到接收服务器的URL进行远程联系。该命令还可以沿途上传数据包。该命令的响应者是服务。Kubernetes的长处是编排服务。

是的，服务是一种工作负载。现代服务体系结构最突出的例子也许就是所谓的无服务器功能。之所以这样称呼，是因为它的源(托管它的服务器或服务器集群)不必通过名称来寻址，甚至不必间接地由另一个服务或其用户来调用。相反，这些详细信息代表请求者填写，结果是该功能的用户可以假装该功能在客户端本地存在。就像智能手机上的联系人列表一样，它使您认为数字已变得无关紧要。

Kubernetes的组成

您可能已经注意到，本文通过前十段进行了转义，而未使用“容器”一词或不那么解释的“容器化”一词。Kubernetes与容器的解耦是近几个月来Kubernetes范围内最令人意外的变化之一。片刻之后，您将了解原因。

编排的主要目标之一是使事物在网络中可用。到现在为止，我们主要将这些东西称为“容器”，尽管我们注意到，从一开始，Kubernetes便将其协调并有效地编排为Pod的实体。在这种情况下，术语“荚”已经被简单地定义为“一组容器”。

控制平面上的容器和资源

Kubernetes集群中的每个服务器(物理服务器或虚拟服务器)都称为节点。如果它托管Kubernetes的某些方面并且可以通过协调器维护的网络进行寻址，那么它就是一个节点。有一个主节点和任意数量的工作节点(有时称为奴才)。负责控制系统的组件网络与所有其他网络分开，以形成控制平面。在这个专属平面上，您会发现三个组成部分：

API服务器 (kube-apiserver)，用于验证所有传入请求，包括对在pod内运行的服务的请求。

控制器管理器 (kube-controller-manager)。Kubernetes的直接负责管理系统内某些资源的各个组件称为控制器。例如，为基于Pod的服务提供作业以进行承接是作业控制器的任务。这就是有趣的地方：可以通过添加其他控制器来扩展Kubernetes，使其成为容器以外的其他事物的协调器。

调度程序(kube-scheduler)，与其说是时间，不如说是将工作负载委派给Pod。设置Pod后，鉴于其当前的可用性状态，调度程序会将其委托给最适合处理它的工作程序节点。

控制器位于Kubernetes控制平面内部。对于Kubernetes随附的服务器，其主要功能是监视网络基础结构上的资源状态，以查找任何更改。它需要一个事件(这种变化的信号)来触发评估函数，该函数确定最佳响应方式。可以委派响应任务的服务类别是运营商。为了使协调器能够自动化更复杂的系统，服务架构师会将控制器添加到控制平面以制定决策，并由后端的操作员根据这些决策采取行动。

定制资源

最终，该控制器方案的可扩展性可能是巩固Kubernetes在数据中心中地位的绝妙手法。作为称为自定义资源定义(CRD)的架构添加的结果，Kubernetes可以编排除这些容器之外的内容。换句话说，如果您可以设计一个控制器来有效地教导Kubernetes将其他事物识别为编排的资源，那么它将做到。我们在这里谈论什么-“其他”可能是什么?

虚拟机(VM) -经典的，由管理程序驱动的实体，支持全球大多数企业工作负载。VMware的vSphere平台是VM管理方面的主要商业领导者，该公司已经启动了一个使Kubernetes成为其主要VM编排器的项目。

近年来，其引擎和控制工作已转移到诸如Hadoop和Apache Spark之类的专用系统的海量数据库，并且可以想象，如果开发人员能够再次自由地使用除少数几种语言之外的其他语言编写工作负载，则这些数据库可能会脱离这些平台。 Java，Scala和R。

超级计算机的高性能计算(HPC)工作负载在历史上一直由专用调度程序(例如Slurm和最近的Apache Mesos)控制。随着Kubernetes接近普及，现在它们在数据中心中作为面向时间的调度代理的优点受到质疑。

机器学习模型，需要并行访问以及确定性调度的大数据量。您可能会认为，仅凭这些因素就不能使Kubernetes成为协调器或基础结构协调者，但有些项目(例如Kubeflow)中确实提供这些功能的数据库提供程序和调度程序本身就是由Kubernetes提供的。

数据平面上的对象

所有这些类型的承载工作量的实体都被收集到Pod中，再加上Kubernetes将来可能会编排的其他任何东西，都因缺乏更好的词汇而成为对象。

向协调器解释这些对象之一的是一个文件，它用作其身份证明文件，称为清单。这是代码元素，使用一种称为YAML的语言编写，用于声明该对象期望使用的资源。在这里控制器可以预览对象将消耗多少燃料，即该对象将消耗多少存储空间，哪些数据库类别，哪些网络端口。控制器会尽最大努力满足这些要求，因为知道群集如果已经超负荷运行，它可能必须尽其所能。

每个吊舱内部都有一个名为kubelet的远程代理，该代理接收来自操作员的请求并管理吊舱的组件。在传统的基于容器的系统中，正是kubelet产生了容器引擎的流程。这是Docker过去在Kubernetes桌子上保留位置的地方-它曾经是容器引擎的事实上的独家提供者。它甚至创建了一个通用的运行时，称为runC(发音为“ run·see”)，并将其发布给了开源社区。现在，Kubernetes项目催生了自己的替代方案，称为CRI-O(“哭泣”，尽管有时像“克里奥尔语”这样说)，。

Kubernetes的竞争对手

在许多技术媒体普遍意识到服务器集群编排空间是现代数据中心最热的战场之前，这场战斗已经结束。大宗商品市场很少能长期接受竞争标准。这就是为什么只有一个HTML，一个Facebook和一个Kubernetes的原因。

码头工人

Docker Inc.是一家公司，其工程师负责引发容器革命，该公司在大规模商业化大规模部署，安全性以及对自由和开源内核的支持的基础上，早就确立了经营理念。收入将来自Docker品牌的Docker核心的附件和增强，但对于它称为“已包括电池但可更换”的业务模型，通常可以使用其替代品。Docker的领导人坚持认为，如果容器变得无处不在，那么就不应以使容器成为商品的东西为由，无论是知识分子还是其他方面，都不应主张任何权利。该公司认为，更广阔的市场将导致更多的意愿客户。

为此，在Linux的主持下，Docker在2015年支持了Open Container Initiative(OCI，最初是Open Container Project或Open Container Foundation，尽管出于多种原因需要更改名称)的创建。基础。当时的首席技术官所罗门·海克斯(Solomon Hykes)在公司会议上宣布这一消息时，告诉听众他不喜欢标准战争，他称标准战争是“细节，例如盒子的大小和形状”。因此，Hykes宣布用runC替换Docker容器的运行时组件(使它们可以在网络上运行的部分)。

在同一周，OCI的许多创始成员宣布成立了Cloud Native Computing Foundation，这是Linux Foundation的另一个项目。表面上看，CNCF的任务是促进和推进开源应用程序部署技术的使用。从明年三月开始，CNCF的第一个项目将是Kubernetes，该项目起源于Google。

同时，在进行了一些通用性较差的尝试(有时是对部署平台的笨拙尝试)之后，Swarm成为了Docker的协调器。多数人认为，Swarm是一个值得竞争的人。管理员表示，它的学习曲线要​​轻松得多。它的覆盖网络模型可以将容器间流量与主机流量分开，每个主机流量在其平面中都通过它们之间的桥梁进行划分，这被认为是聪明的，特别是与Kubernetes的平面网络覆盖模型相比。在多云部署模型中，可以将Swarm容器集群委派给速度较慢的公共云，而将控制平面上的流量更紧密地包含在较低延迟的集群中。在性能和可管理性方面，专家选择收藏夹的速度很慢。

如果仅凭性能来决定技术战的结果，那么Sun Microsystems早就可以征服台式机了，我们都将在BlackBerry上谈论它。

CNCF的使命是促进和促进整个开源生态系统的广泛部署，包括性能监控，服务发现，数据量管理和安全性，所有这些都围绕一个工作负载部署引擎进行。Docker已经开始发布其可扩展性模型，但立即陷入了关于可扩展体系结构是否违反了称为“无状态”的某些应用设计准则的深奥，哲学的泥潭。

同时，虽然Kubernetes只是一个与供应商无关的平台，但在最初的日子里，Google在营销方面投入了全部精力和精力，为消费者和记者量身定制了主题和一致的推销方式，同时编织了Kubernetes的名称已加入其品牌。在整个2017年，评估Kubernetes的企业将其视为Google产品。当向他们解释了合法性和手续时，许多人挥舞了他们，说只要最终结果是称为Google Kubernetes Engine的东西就没有关系。在我参与的多次对话中，IT管理员和其他企业专家从业人员告诉我，如果归结于Google与Docker，Sam Hill是什么?

然而，谷歌无法长期维持业务流程信念的唯一捍卫者。追溯到2015年，红帽做出了重大决定用Kubernetes替换其OpenShift容器部署平台的引擎。到2017年，这一决定已成定局。红帽已经成为Kubernetes的顶级贡献者。在北方，微软为避免企业遭受另一波变革的可能性，聘请了两位开源社区最知名的工程师：Gabe Monroy，他是Deis的联合创始人兼CTO。 ，这是Kubernetes生态系统中用于构建和部署容器化应用程序的关键因素(一个笨拙的Docker希望能够为自己辩护);和Brendan Burns，他是创建Kubernetes原型Borg的Google工程师之一[ PDF]。这次，微软不会在一些研究部门的项目后壁橱中隐藏其最新员工。他们率先在Kubernetes的形象中重建了大量的Azure。

大坝在几处同时破裂。

APACHE MESOS

分布式服务器集群工作负载调度的公认领导者是Apache Mesos。它开创了master / worker体系结构的先驱(尽管Mesos用不同的词来表示“ worker”)，并且是最早扩展到称为Paath的私有PaaS平台的调度程序之一。Mesos的第一个主要部署是在Twitter上，本·辛德曼(Ben Hindman)是工程师。2013年，Hindman离开，创立了Mesos的首要商业供应商Mesosphere。Mesosphere与Microsoft合作，生产了首批基于公共云的PaaS之一，以实现经过协调的混合部署：DC / OS，它看起来将成为Azure的首选工作负载部署平台。Mesos拥有多年部署经验，

但是现任的Mesos无法逃避一个充满挑战的反叛挑战者的影响。2017年8月，VMware利用其姊妹公司Pivotal的资源启动了一个名为Pivotal Container Service的基于云的Kubernetes平台，该平台具有来自Cloud Foundry的自动部署机制Kubo。很快，Azure效仿，有效地回燃了其DC / OS项目。然后在2018年6月，坚定的亚马逊放弃了防御地位，开放了其Kubernetes部署平台。最后，很少有人相信IBM于去年7月完成对Red Hat的收购，是关于IBM需要更好的Linux发行版。OpenShift已经为通往分布式数据中心的路由铺平了道路，IBM发现不再需要再次铺路。

失败是如此彻底，以致Mesosphere无法再使用该名称开展业务，去年8月将其自己重新命名为D2IQ，并誓言建立自己的“ Ksphere”。在十月初，Docker建议其用户尝试并排运行Kubernetes和Swarm。该公司在博客中写道：“新用户发现了解Docker Swarm更加容易。” “但是，Kubernetes已经发展成为增加了许多功能。”

Kubernetes从何而来

到目前为止，有关数据中心架构的许多讨论都围绕着将旧工作负载迁移到新模型这一主题。 我们所知道的应用程序被称为“整体程序”，因为它们像电影《 2001》中的神秘物体一样，是奇异的，几乎是牢固的，并且在剧院里坐了四个小时后就像莫名其妙的一样一开始。它们由只有其创建者知道如何更改的代码组成。

迁移到Kubernetes已被描述为迁移整体的过程。有人说，这只能通过重建微服务网络来实现，这些微服务网络的行为像它们的前身一样，但是会完全取代它们。其他人则表示，可以将API封装在整体服务中，然后以微服务方式通过网络分发该API。这样会更容易，并且不会花费太多精力来复制企业已经拥有的相同功能。

现在，得益于Kubernetes的CRD来解释Arlo Guthrie，第三种可能性甚至没有人指望：Kubernetes本身可以迁移以满足现有工作负载的需求。作为世界上最活跃的开源软件项目，Kubernetes由数以百计的专家工程师维护，他们可以协助企业设计或改编他们需要使软件供应链自动化的控制器和操作员。

创建Kubernetes的人说，几年前，有一段时间他们的创建成为每个人的数据中心的重要组成部分，以至于他们很无聊，没有人会阅读有关它的文章。据我目睹，这一天至少还有几年。