【3】K8S的诞生背景&发展历程

Valiant程大约 30 分钟

为什么会有K8S

在上一篇文章中我们讲解了容器的诞生历程，其根本性解决了程序一直以来存在的部署问题，这一问题的解决，从根本上提高了IT技术工程的整体效率，从而让容器的使用开始得到逐步的普及。从个人使用到企业大规模化使用，落地容器技术和追求容器化率开始成为大多数追求技术先进性企业的目标。

不过随着容器技术被大规模地运用于生产实践，一些问题也逐步暴露了出来：

单机上的容器可以使用docker很轻松地进行管理，但有一定规模的企业往往会有很多个应用、很多台机器，一旦应用、机器的数量急剧增长，承载应用运行的容器的管理就开始变得复杂和麻烦了。试想，如果没有任何手段，那么就只能编写运维脚本，然后批量下发到每台机器上做管理了，这种管理模式有很多弊端：

操作管理效率低：任何操作都要编写脚本实现，操作人必须关注每一步的操作和实施细节，整体的实施操作的效率很低，且具备人工误操作的风险，并且大多数时候这对工程师来说是一种高重复性且枯燥的事务性操作，存在自动化的可能
缺失全局记录：在大量机器上做了容器化部署后，默认是没有记录机制的，部署完成后无法感知应用程序在大量机器上的分布和运行情况，必须自己建设管控系统记录这些信息
精细化控制操作成本高：比如实现一组应用程序的受控分批化逐步升降级、根据资源使用情况针对应用程序所申请的各类计算资源进行扩缩容调整、一台机器宕机后对上面运行的应用程序进行转移恢复等等，规划、执行这些操作行为都有很高的成本
难以进行高效的资源管理、使用及分配：应用程序需要的各类资源（计算、内存、存储、网络、异构算力等）如何管理和供给？哪类或哪个应用适合放在当前集群内的哪个机器上？如何放置才能将资源碎片度降到最低、机器集群整体的资源利用率得到最高效的使用？这一点和成本紧密相关，也是对企业最有吸引力的一个方面
服务难以高效管理和治理：在微服务化的背景下，应用服务间该如何在大规模机器集群上高效地互相感知、互联及协作？每个服务的配置如何进行高效跟踪、修改和管理？服务该如何恰当地暴露给用户进行访问？

要一一解决这些问题，就需要从头针对容器化应用在大规模机器集群的部署实践中遇到的上述各类问题，设计一个功能健全的管控系统来解决，而其实K8S也就是这样的东西，可以说这又是一个遇到问题解决问题的过程，但K8S并非是解决这些问题唯一出现的项目，但却是在一堆解决方案中解决最成功的一个。

不过，我们更多地将K8S称为容器编排（Orchestration）系统，而非管控（Control）系统：这两个定义的差异关键就在于编排是一种更上层、更宏观及关注结果的视角（即最终应当是一种怎样的状态），而管控则时更底层、微观一些，关注操作过程的视角（即如何进行控制来达成需要的状态）。这一差异是K8S理念中最核心的一点，也是其相对于其他类似系统最根本性和革命性的差异。

K8S如何解决这些问题

那么K8S具体是如何解决上述问题的，上文提到的前三个弊端问题的解决，都和K8S应对这些问题和场景时所秉持的一个大原则：面向终态 有关

面向终态

如何理解“面向终态”？相信即使没有程序员背景知识的人也都用过马桶水箱、冰箱、热水器、空调、自动驾驶汽车这些东西吧，这些东西都可以视为“面向终态的控制系统”：

马桶水箱的终态是水箱内的水达到指定水位，否则会一直尝试送水进来
冰箱、热水器和空调的终态是其关注对象的温度达到指定值，否则会一直尝试工作来改变对象温度
自动驾驶汽车启用定速巡航功能的终态是达到其设定的行驶速度，否则会调节发动机转速达到指定速度

我们不难看出，面向终态的关键就在于让控制逻辑感知到某种状态（现状），然后根据感知到的状态进行针对性操作，最终达成某个目标状态（终态），而目标状态也不是一成不变的，所以整个系统往往处于一种动态平衡的状态。

为什么这个思想成为了K8S的核心思想呢？我们首先要分析清楚K8S要解决的问题究竟是一个什么样的问题：

大规模程序、应用在大规模机器集群内的高效部署管理

我们对这个问题进一步分解细化一下，部署管理无非就是对程序、应用和机器进行各种操作，来达成各种目的，比如：

对应用程序进行从无到有的部署：一批应用程序应当运行在集群内的某些机器上，以满足业务需求
将应用程序从A版本升级到B版本：应用程序的版本应当为B，以满足新的功能需求
将应用程序的CPU资源从1颗增加至2颗：应用程序应当享有2颗CPU的计算资源，以缓解其性能压力
在应用程序所处的机器宕机后对其进行转移：应用程序应当始终保持运行，以保证服务始终可用
为机器集群扩充机器：当IT业务经历使用高峰时，应用程序的计算资源应当保持充足，以保证用户良好的使用体验

诸如此类的问题，其实都可以划分为操作、目标状态和最终目的三部分：

操作的直接目的是达成目标状态（应当达成的状态）
达成目标状态可以满足最终目的

所以，这里目标状态实际上就是操作和最终目的之间的关键纽带，K8S“面向终态”的设计思想就是关注这里的目标状态，将达成目标状态的操作进行自动化、公共化和抽象化，从而更高效地达成最终目的。

自动化、标准化操作流程

之所以能够实现自动化、标准化的基础之一，也在于对程序在大规模机器集群内的部署管理这个问题来说，大部分的操作都是重复冗余、有高度自动化可能性空间的，所以K8S“面向终态”，实际上就把这些高度重复冗余的操作都标准化、自动化了。

最典型的比如重启、升级、增加计算资源这些操作，基本的操作流程都是固定不变的，并且和容器内运行的到底是什么样的程序无关，会变的仅仅只是一些外部参数（如应用名、版本号、增加的计算资源数目等），因此这些流程很容易就能被标准化自动化，这本质上和在编程中封装公共函数是同一件事情。

而最终这样的自动化、标准化也消除了管理运维人员原本必须进行的重复繁重枯燥的手动人工操作，也消除了因为人工误操作带来的故障风险，从而提升了管理效率和稳定性水平，成功释放了技术红利。

天然重试

面向终态的思想还带来了一个天然的结果，那就是“重试”。

当我们进行任何操作，如果不符合预期，可能是各种各样的偶然因素影响，我们往往会做重试来再尝试若干次以避免偶然因素带来的影响。

在面向终态的思想中，因为时刻在比较现状与目标状态的差异，一旦没有满足要求，就会立即进行操作来尝试达成目标，如果这次操作失败了，就会再次重试来再次尝试达成目标状态。也因此，“重试”操作成了面向终态设计思想和实现中所达成的一个天然性的结果，这也降低了由人工进行操作重试所带来的成本。

重试这件事本身也很复杂，该重试几次？重试的频率是多少？什么情况下不该进行重试？等等之类的问题，我们会在后面探究更细节性的K8S设计思想的时候进一步阐述。

一个很有意思的例子是，很多的企业采用K8S后，发现遇到的实际生产问题变少了，原因不是他们用了K8S后代码中的bug减少了，而是因为原来的bug导致的服务崩溃都由K8S帮他们迅速重启拉起恢复掉了，这样的重启执行速度之快与及时，甚至让开发人员意识不到是自己的程序出了问题

状态的全局记录

因为面向终态要时刻比较当下和目标状态的差异，因此对当下和目标状态信息的记录就变成了一个必要的条件，否则便无法实现“面向终态”思想所要求的效果，所以这种记录能力也是K8S提供的基本功能。

所以，在管理程序和机器的同时，我们也就有了记录机制。每一个部署的程序，管理范围内的机器，以及彼此之间的各类关系，都有了明确的记录（所有机器就像是都有了证件，证件上的所有相关数据信息都在管理机构的数据库内统一保存，并且能够实现实时更新感知），这极大地提升了管理的效率，因为我们可以近乎实时地感知到当前大量程序和机器的状态，判断其是否存在问题，并做针对性的调整。

降低门槛

另外一个效果是，由于所有的具体操作行为被自动化和标准化掉了，也因此实际上运维人员不需要进行达成目标状态的每一步细节操作，这极大的降低了管理程序和机器集群的门槛。

在这样的思想下，解决问题的人的关注点完全改变了，从关注过程变成了关注结果，而描述清楚需求、结果往往比描述清楚过程简单地多，因此问题的解决变得更加容易和高效了。更具体地来讲，这里的受益人员实际上是运维人员以及一切做运维操作的人。

但往往随着需求越来越复杂，这套机制也会出现新的问题，那就是描述结果的语义也开始变得复杂，就像是用SQL取数据一样，同样是关注结果而非过程的思想，在最简单的场景下往往select+where就够用了，而一旦取数据要求的结果本身很复杂，就会导致写SQL本身这件事也开始变得复杂。

所以，我们现在来看，在上文所提到的三个问题是否都得到了解决：

操作管理效率低：几乎所有高频、重复的操作都被自动化、标准化了，管理人员无需付出较多精力去操心如何进行操作执行的细节
缺失全局记录：因为要时刻获知当前管理的各类目标资源对象的状态，所以会有实时性的全局记录
精细化控制操作成本高：基于自动化、标准化的基本操作，由于K8S的开源和开放扩展性，开发人员可以开发更多定制的精细化控制操作，并提供给广大K8S用户进行使用，而用户同样无需关心实现细节，即可在任意K8S环境重复使用

调度

我们说完了上文提及的前三个问题是如何被面向终态的思想所解决的，下面我们来看第四个问题：资源管理、使用和分配的问题，K8S的出现，使得进行这类事情变得更加高效。

调度面对的核心问题

调度是计算机科学里面对的一类非常具备普遍性的问题，我们在很多地方都能看到调度问题：

操作系统的进程、线程调度
CDN的网络流量调度
物流中的多地多仓库货物调度
编程语言的垃圾回收本质上也是调度问题

调度本质上是一个决定资源如何分配才能达成某些条件下的最优效果的过程，这个某些条件下的最优效果往往是人为定义的：可能是最直接的全局综合最优，也有可能是特定范围内的局部最优，这个最优效果往往会随实际需求的变化而进行适应性的定义调整。

在K8S的所面对的调度场景中，就是探究如何将多个具备不同特点和规格的应用程序安置到一个由多个相同或不相同的机器组成的集群内，才能达成最大程度的资源利用率（这是最常见的最优效果要求，随着场景的变化往往会不同）。

一般来说，资源利用率往往和服务质量（如响应实时性）是不可兼得的，在操作系统上就会遇到这样的问题，所以便有实时操作系统和普通操作系统之分，前者更加在乎响应实时性，所以整体资源的利用率就变成了次要关注目标。同样的，在集群调度中也会遇到类似的场景，如果大部分调度对象对执行完成时间有较为严格的要求，调度的侧重点就会变成调度对象任务执行的平均时间开销而非是资源利用率。

K8S的调度

由于调度本身是一个非常复杂和多样化的事情，在不同场景和需求下所要求的目标并不相同，所以K8S提供了一个调度框架，来辅助使用者实现不同的调度需求目标，我们这里以最常见的、也是默认的调度策略为例来介绍下K8S调度框架的整体思想。

对刚刚了解K8S的人来说，只需要关注理解调度框架中过滤（Filter）和打分（Socre）两个过程就够了，这两个步骤也是K8S调度中最重要的两个，这里可以直接引用K8S官方文档的解释：

kube-scheduler 给一个 Pod 做调度选择时包含两个步骤：
过滤
打分
过滤阶段会将所有满足 Pod 调度需求的节点选出来。例如，PodFitsResources 过滤函数会检查候选节点的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下，这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。
在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。
最后，kube-scheduler 会将 Pod 调度到得分最高的节点上。如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。

进一步简单地考虑，其实过滤和打分做的是同一件事情，过滤可以理解为把过滤掉的候选项放到打分结果最后一位之后，所以我们着重看看K8S调度默认是如何打分的，默认的打分结果是由以下几种策略加权求和计算出来的（根据K8S v1.30代码整理）：

TaintToleration（3）：污点容忍情况
NodeAffinity（2）：节点亲和性情况
NodeResourcesFit（1）：可用资源情况
PodTopologySpread（2）：pod拓扑分布情况
InterPodAffinity（2）：pod间亲和性情况
NodeResourcesBalancedAllocation（1）：节点资源分配均衡情况
ImageLocality（1）：节点存在镜像情况

污点容忍、节点亲和性、pod拓扑分布、pod间亲和性这三类都是用户主动指定的位置偏好（即：我想让这些应用运行在哪些地方），所以相对来说赋予了较高权重，这里可以看出默认策略是更照顾用户的主观性要求的。

可用资源、节点资源分配、节点存在镜像情况则是客观资源条件（即：把应用放在哪里可以起到最好的资源利用率），这里的权重是比主观性要求要低的。

上述是K8S默认使用的调度策略，如果有需要，K8S所选用的调度策略、权重甚至是策略执行和计算的过程都是可以完全自定义实现的，并且所谓的“资源”的概念也可以自行定义和实现针对其的调度模式。譬如上述涉及到的仅为最常见的以CPU和内存为基本计算资源的调度场景，除此之外，磁盘、网卡、GPU芯片、IO设备各类硬件乃至虚拟的软件资源都能成为可能的调度资源对象。

理论上讲，K8S的调度机制和框架，最终赋予了用户达成任意调度策略和目标的可行性。

也因此，通过这样的调度机制和思想，K8S实现了各类资源的利用在各类定义衡量标准下的尽可能高的优化效果，提升了企业和个人对资源的使用率和取得的特定质量效果，同时灵活地满足了各类可能的调度诉求，顺带解决了人工部署时存在的“选择困难症”现象，这样提升的效果无疑是非常显著的。

中立的服务管理和治理模式

接下来我们来谈谈K8S如何解决第五个问题：应用服务的管理和治理

微服务和容器化

这也是一个非常大的话题，我们可以知道，在容器和K8S出现的前后，微服务也在那段时间开始变成了一个非常流行的技术术语，这两者几乎在同一时间段受到追捧，从某种程度上来看，是一种必然。因为从两者的理念和模式上来看，存在非常多的交集和共通点，所以这两个技术的流行普及实际上是一个相辅相成的过程。

微服务的核心理念是什么呢，是把旁大的单体式应用服务根据功能或领域拆分成若干个独立的灵活小巧的微型服务，所以称为微服务。而单体服务往往切分完遇到的第一个问题就是切分后的服务数量上涨，多个微服务的部署、管理、治理都变得复杂和棘手，而容器和K8S技术恰恰能够较好地帮助解决这些问题，因此两者的使用相得益彰。

相信做业务开发的同学对微服务的理念非常熟悉，而这一领域比较经典的就是Java Spring Cloud那一套东西，它给出了微服务架构中的关键功能范式组成：

配置中心：对各个服务的多个实例所使用的配置进行统一化管理
注册中心/服务发现：注册中心对所有服务进行统一登记管理，进而帮助多个服务间进行互相发现和访问
负载均衡：用于访问服务时在单个服务的多个实例间均衡流量
网关：作为服务访问的统一入口使用，集成了和服务具体逻辑无关的通用性功能：如路由、过滤、鉴权等
远程调用：用于服务间互相调用对方提供的接口和方法
限流熔断：用于限制访问服务量过大时进而对服务稳定产生威胁

Spring Cloud的这样的设计，是一个针对微服务架构很好的范式，不过很遗憾的是Spring Cloud仅限于Java系的语言中，在非Java、多语言混合技术栈中，就很难适用了。

不过，这些典型功能是从微服务架构中抽象出的不可或缺的基本需求，也对后续我们理解K8S为何对微服务架构非常友好有所帮助，实际上K8S就是达成了多语言混合、或者说语言中立技术栈微服务架构所需的要求。

K8S中的微服务

我们可以从上一部分抽象出的微服务架构的关键功能范式的基础上，来一一对应地说明，K8S是如何达成同样的效果的：

配置中心：K8S提供了两类存在于集群中的抽象资源Configmap、Secret来实现配置的管理，前者用于保存非敏感数据、后者用于保存敏感数据，所有需要使用配置的应用都可以通过“挂载”一个或若干个Configmap或Secret来实现配置的附加，同时多个应用可以挂载同一个Config或Secret，其修改和变化也会同步同步到所有挂载这些对象的应用服务实例上，实现配置的统一管理和变更
注册中心/服务发现：在K8S集群中，一组应用服务程序（微服务）的实例可以被直接抽象成一个K8S集群中的资源——服务（Service）而对待，这个名字非常直观，不同应用服务间通过Service这个集群资源即可实现互访，无需感知究竟要访问哪一个实际的服务地址。并且服务作为集群资源，会被K8S所保存到其全局记录中，也可以通过K8S API轻易地获知集群中存在哪些对外暴露可访问的Service进行服务发现
负载均衡：K8S使用一个叫做Kube-proxy的组件，借用Linux内核提供的灵活的网络转发机制（iptables/ipvs），同样实现了应用程序在客户端的负载均衡，保证了应用程序在访问抽象的Service资源所对应的实际端点时，能够按照特定的负载均衡策略在多个端点间进行合理的请求分布，简化了对一个应用程序实体、多个实例的访问方式
网关：K8S通过抽象资源Ingress、Gateway来声明式地提供网关实例，在K8S中，没有强制地绑定了一个网关的具体实现，而是定义了一个网关组件需要支持的基本语义规范（也可以理解为协议、接口）来提供给用户使用，这里给予了用户灵活选择的空间，用户可以选择更加适合自己场景的网关进行使用，并通过K8S提供的统一的声明式抽象语义规范来使用；除了在网关上我们能看到这种定义语义规范/协议/接口，而不是定义具体实现的模式，我们还能在K8S的很多地方看到这样的模式，譬如CNI、CSI、CCM等等，这也是K8S本身的一大特点
远程调用：由于远程调用是一个和语言密切相关的操作，K8S出于本身的语言中立性，不提供一个具体的远程调用方法框架，因为诸如像GRPC、Thrift、GraphQL等项目已经提供了成熟的语言中立的远程调用能力，所以这里K8S同样不强制性地绑定实现，而是把选择权交由用户
限流熔断：这类功能可以看作是网关层和远程调用范畴内的功能，一般往往也是在这两个层面内进行实现，因此K8S并不考虑这部分内容

总体上，对应Spring Cloud提供的微服务架构基本能力来看，其中基于语言无关立场能够实现的，K8S均提供了定义和实现，而不能实现的，K8S也能很好地进行嵌入和适配。而K8S面向支持微服务架构，提供的最关键的优势，就是其语言中立性立场带来的普适性、面向接口和协议而非实现的高度兼容和扩展性。

不过相比于Spring Cloud这样的方案，K8S这样的模式也造成了很多时候不能够开箱即用、方便快速地使用，不过从其本身的定位来说，这样的代价也是可以接受的。因此，最终通过这样的模式，K8S解决了第五个多个服务难以管理和治理的问题。

为什么是K8S

我们在前面的部分也提及到了，K8S并不是解决大规模容器化应用和机器集群管理问题的唯一的项目，但它确实是解决地最好的一个，也因此成了现在容器编排管理领域事实上的标准。那么，为什么是K8S呢，与他同期同类的项目为什么没能竞争过它呢？

开放性

我们上一篇文章讲了Docker，事实上对Docker比较熟悉的人应该知道，Docker除了管理单机上容器的成名项目Docker，还有自己的容器编排项目：Dokcer Swarm。

并且，在容器生态刚刚兴起繁荣的当时，Docker可谓是如日中天，与它无缝集成的Swarm自然也有非常巨大的优势去抢占容器编排领域的主位，但它还是被K8S击败了，并且输得很厉害，乃至于K8S最终把Docker也抛弃并划清界限了，造成这种结果的核心原因，就是开放性。

Docker Swarm从诞生时，就成为了Docker雄心勃勃、想进一步垄断容器生态市场的一个有力工具，因此当时参与该领域竞争的其他公司自然会对Docker Swarm抱有较大的竞争意识。

由于Docker Swarm本身的非中立性（绑定了Docker公司），因此推出K8S的Google在之后的竞争中选择了成立一个中立的开源组织CNCF，把K8S完全捐赠了出去，撇清了K8S和Google之间的管理（也就是告诉大家：不用担心，这个项目不是我的，我不会通过控制项目的发展来牟利）。

也因此，彻底中立开放的K8S项目成了广大开发者和企业所青睐的对象，因为中立的立场意味着K8S的使用永远不会需要授权、付费，并且其发展永远不会被一家公司所把持。另外，开源、开放的运作模式，意味着任何个人、公司、团体，都有参与发展K8S项目的权利，都有无偿享受项目的权利。

除此之外，K8S的开放性还体现在对各个具备同类功能项目的包容和中立性，由于是通用的容器编排系统，因此会集成很多能力，包括存储、网络、计算的各个方面。在这个时候，K8S选择制定开放的协议和接口标准，而不是强制绑定和规定一个实现，比如：

CRI抽象了所有底层容器运行时（如Docker）的功能标准接口，满足了该接口标准的任何项目，都能被集成到K8S中使用
CSI抽象了所有K8S容器使用存储能力的统一功能标准接口
CNI抽象了所有K8S容器使用网络能力的统一功能标准接口
CloudControllerManager抽象了所有K8S集群使用云平台相关能力的统一标准接口
DevicePlugin抽象了所有K8S集群使用异构设备的统一功能标准接口

上述这种规定接口协议标准，而不是绑定实现的模式，除了进一步加深K8S的开放性，本身也为K8S提供了多样化且富有差异化的底层功能支撑，在开源的大背景下，满足了不同用户在各类场景下的不同需求，进一步丰富了社区生态。

正确的专精技术方向选择

在同期比较知名的容器编排系统还有另一个叫做Mesos的项目，在当时也有较为广泛的使用，但为什么Mesos没能在和K8S的竞争中胜出呢，重点还是在专精技术方向的选择上。

事实上，Mesos出现的比K8S早得多，其建立的最初目的是服务Hadoop、Spark这类大数据计算机器集群的管理，在这时以Docker为代表的容器技术还没有成熟和流行。因此，Mesos项目的能力重点早期都侧重到了传统机器集群的管理上，以致于后续没能很好地拥抱上容器化技术。

虽然后来Mesos也在项目中积极支持容器相关能力，但由于其历史包袱过重，无法在容器领域内竞争过专精容器集群管理的K8S，因此逐渐在和K8S的竞争中被淘汰，这又是一个生不逢时、错失机遇的故事。原先很多Mesos专精服务的大数据计算项目社区，后来也反过来主动涌现了很多结合K8S范式的项目来完成这些大数据计算服务在K8S上的适配，这让Mesos一开始想做主动完成的事情，对K8S变成了一个被动、自然的事。

只有容器化集群在当前才能最好地解决应用服务在IT基础设施一直以来的运维问题和痛点，也只有它，才能带来当下应用服务在IT基础设施上最高效的管理能力。一个技术项目，对于核心关键问题到的正确把握，在恰当的时间和历史背景下，带来正确的专精技术方向的选择，带来最终更广泛意义上的成功。

云计算厂商的推波助澜

另一个不可忽视的事实是，在容器相关生态技术迅猛发展的这段时间，云计算这个产业也处于高速增长、发展革新的阶段。AWS、Azure、Google等公司，承包了越来越多的IDC机房，托管了越来越多企业和个人的应用服务，自身对于IT基础设施的管理效率以及利用率的要求也在不断增长。

在这样的大背景下，容器生态技术无疑很好地解决了这些云厂商的痛点，从传统的售卖虚拟机到售卖托管容器集群，容器技术的使用使得管理效率和资源利用率都得到了提高，让厂商和客户都享受到了技术所带来的红利。

同时，K8S作为首个开放中立的开源容器编排项目，自然得到了几乎所有主流云厂商的青睐，这样的现象也让诸多云厂商自身投入了很多高质量的研发人员到了K8S项目之中进行开源共享，反过来促进了了K8S本身的发展。

除此之外，由于K8S本身的开放性，其本身可以通过开放的协议标准来和云厂商提供的很多其他云产品产生集成效应，对于促进云厂商本身的营收增长也有非常明显的推动作用。也因此，后来有了“云原生”这个概念，潜在含义就是K8S牢牢将应用服务和云计算牢牢绑定，K8S提供的能力和云产品本身的价值紧密结合，产生1+1>2的效应来提供价值。

因此，随着云厂商的推波助澜，K8S变得越来越为人所知，也成为了当时那段时间中最为新潮的技术项目和方向，“云原生”作为从容器和K8S生态中衍生出的概念，也变得如日中天，并演化除了后续的云原生生态。

总结

从整个K8S的诞生、发展到现在的成熟，我们可以看出一个很明显的本质，那就是：应用程序应当且仅需关注自身。

不论是容器还是K8S、抑或是云平台提供的各类云产品、基础平台提供的各类能力，其核心做的事情都是将和应用程序本身无关的问题进行解耦，进而得到更为专业化的解决，让应用程序的开发者和拥有者专注于应用程序本身和其所带来的价值上。所谓的云原生、平台工程，其实都是在做这样的事情，这也符合了生产力发展、社会整体效率不断提高的大趋势。