fix typo

application-centric/Controller.md

@@ -15,9 +15,8 @@ Kubernetes 与其他技术项目最大的不同是“声明式应用管理”。
   图 7-1Kubernetes 的控制器模式
 :::
 
-Kubernetes 中有多种类型的控制器，例如 Deployment Controller、ReplicaSet Controller 和 StatefulSet Controller 等等，每个控制器有着不同工作原理和适用场景，但它们的基本原理都是相同的。
+有了控制器模式，那么整个底层的基础设施能力，无论是扩缩容、负载均衡、服务发现还是状态一致性，只要描述好状态，通过声明式 API 的方式去暴露给用户。那么，背后的控制器，执行“调谐”来逼近预期状态与实际状态一致。这正是 Kubernetes 声明式应用管理最直观的体现。
 
-通过声明式描述文件，以驱动控制器执行“调谐”来逼近预期状态与实际状态一致，正是声明式应用管理最直观的体现。
 
 ## 10.1.2 基础设施即数据思想
 
@@ -52,6 +51,8 @@ spec:
         echo "Hello, Tekton!"
 ```
 
-借助 CRD（自定义资源定义），工程师便可突破 Kubernetes 内置资源的限制，根据需求创建自定义资源类型，例如数据库、CI/CD 流程、消息队列或数字证书等。配合自定义的控制器，便能将特定的业务逻辑、特定的基础设施能力无缝集成到 Kubernetes 中。同时，所有的基础能力以声明式 API 向外暴露，基础设施本身的复杂度以指数级攀升的同时，至少保证使用者的交互界面复杂度仍然以线性程度上升。
+借助 CRD（自定义资源定义），工程师便可突破 Kubernetes 内置资源的限制，根据需求创建自定义资源类型，例如数据库、CI/CD 流程、消息队列或数字证书等。配合自定义的控制器，便能将特定的业务逻辑、特定的基础设施能力无缝集成到 Kubernetes 中。
+
+最终，所有让人兴奋的技术演进，无论是插件、接口、容器设计模式，还是 Mesh 形式，它们都以“声明式基础设施”为基础下沉至 Kubernetes 中，并通过声明式 API 暴露出来。“下沉”虽然让 Kubernetes 变得越来越复杂，但声明式 API 的好处就在于，它能够在基础设施的复杂度呈指数级增长的同时，保证使用者的交互界面复杂度仅以线性增长。
 
 

application-centric/PaaS.md

@@ -1,30 +1,17 @@
 # 10.1 “以应用为中心”的设计
 
-很多用户开始学习 Kubernetes，太多的用户也在抱怨 Kubernetes “太复杂了”！
+回顾过去十几年的技术架构演进，精彩纷呈！
 
-## 10.1.1 下沉基础设施能力
+从单体应用到分布式架构，性能大幅提升，但也引入了更多的不确定性。例如，节点故障、磁盘损坏、网络延迟、消息消费等问题变得不可预测。为了解决这些不确定性，业界提出了多种分布式理论和协议，如 CAP 定理、BASE 理论以及共识算法（Paxos、Raft 等），以保障系统的稳定运行。
 
-<!--
-更确切的说，原先通过应用中间件提供和封装的各种基础设施能力，现在全都被 Kubernetes 项目从应用层“拽”到了基础设施层也就是 Kubernetes 本身当中。值得注意的是，Kubernetes 本身其实也不是这些能力的直接提供者，Kubernetes 项目扮演的角色，是通过声明式 API 和控制器模式把更底层的基础设施能力对用户“暴露”出去。
+进入微服务时代，这些理论进一步推动了基础设施能力的发展，服务发现、负载均衡、故障转移、动态扩容、数据分片、调用链路监控等能力，通过 SDK 形式被封装成中间件。中间件的出现其实体现了一种朴素的“关注点分离”的思想，使得你可以在不需要深入了解具体基础设施能力细节的前提下，以最小的代价学习和使用这些基础设施能力！
 
-这也是为什么 CNCF 能够基于 Kubernetes 这样一个种子迅速构建起来一个数百个开源项目组成的庞大生态的根本原因：Kubernetes 从来就不是一个简单的平台或者资源管理项目，它是一个分量十足的“接入层”，是云原生时代真正意义上的“操作系统”。
-!-->
-
-
-## 10.2.2 Kubernetes 太复杂了
-
-“复杂”，是任何一个基础设施项目天生的特质而不是缺点。基础设施本身的复杂度，并不意味着基础设施的所有使用者都应该承担所有这些复杂度本身。为了解决这个问题，很多公司落地 Kubernetes 的时候采用了 “PaaS” 化的思路，即在 Kubernetes 之上，开发一个类 PaaS 平台。
-
-但这个设计，跟 Kubernetes “以应用为中心”的设计不一致，Kubernetes 一旦退化成“类IaaS 基础设施”，它的声明式 API、容器设计模式、控制器模式根本无法发挥原本的实力，也很难与广泛的生态对接。在 PaaS 系统上的体现就是不具备扩展性，假设我们要满足以下诉求：
-
-- 能不能帮我运行一个定时任务
-- 能不能帮我运运行一个 MySQL Operator
-- 能不能根据自定义 metrics 定义水平扩容策略
-- 能不能基于 Istio 来帮我做渐进式灰度发布
-- 能不能...
-
-这里的关键点在于，上述能力在 Kubernetes 生态中都是非常常见的的能力，有的甚至是 Kubernetes 内置就可以支持。但是到了 PaaS 这里，要支持上述任何一个能力，必须进行一轮开发。而且由于先前的一些假设和设计，甚至很可能需要大规模的重构。
+不过，基础设施能力的演进，也伴随着云计算和开源社区发展迅速崛起，这个变化，正是从云原生技术改变中间件格局开始。更确切地说，原先通过中间件提供和封装的各种基础设施能力，现在全部被 kubernetes 从应用层拽到基础设施层，也就是 kubernetes 中。
 
+值得注意的是，kubernetes 本身并不直接提供这些能力。Kubernetes 职责定位是，通过声明式 API 和控制器模式对用户暴露更底层基础设施的能力。从这个角度来看，Kubernetes 设计的重点在于“如何标准化地接入底层资源，无论是容器、虚拟机、负载均衡等，并通过声明式 API 将这些能力暴露给用户”。所以说，Kubernetes 从来就不是一个简单的容器平台或者资源管理项目，它是一个分量十足的“接入层”，是云原生时代真正意义上的“操作系统”！
 
+从这一点讲，Kubernetes 的核心价值不在于容器编排或资源调度，而在于声明式 API。声明式 API 的最大优势是将“简单的交给用户，将复杂的留给系统”。通过声明式 API，Kubernetes 用户只需关心应用的最终状态，而无需关注底层基础设施的配置和实现细节。
 
+这种设计理念，以一言蔽之，就是以应用中心。
 
+正是因为以应用为中心，整个云原生技术体系才强调基础设施更好地服务于应用，以更高效的方式为应用提供基础设施能力。而相应的，Kubernetes 也好、Docker 也好、Istio 也好，这些在云原生生态中起到了关键作用的开源项目，就是让这种思想落地的技术手段。

application-centric/app-model.md

@@ -4,6 +4,6 @@
 
 举个例子，如果你要在 Kubernetes 中部署一套微服务系统，那你需要为每个子服务配置 Service（提供服务发现和负载均衡）、Deployment（管理无状态服务）、HPA（自动扩缩容）、StatefulSet（管理有状态服务）、PersistentVolume（持久化存储）、NetworkPolicy（网络访问控制规则）等等。上述工作“繁琐”还在其次，关键难点是写出合适 YAML 元数据描述，这要求操作人员既要懂研发（理解服务运行、镜像版本、依赖关系等需求），又要懂运维（理解扩缩容、负载均衡、安全、监控等策略），一般的开发人员根本无从下手。
 
-上述的复杂并非由 Kubernetes 造成，而是分布式应用的固有特征。但是分布式应用的诸多痛点不意味着应该使用者承受。这就好比，Linux 内核是世界上最复杂的软件之一，但我们使用它时却没有太多心智负担。这是因为它通过高度抽象屏蔽了底层硬件的复杂性。既然 Kubernetes 被称为“云原生时代的操作系统”，现在，也该考虑学习 Linux 内核抽象方式，构建应用层的软件交付模型和抽象，将底层基础设施的能力以更友好的方式传递给最终用户。
+上述的复杂并非由 Kubernetes 造成，而是分布式应用的固有特征。但是分布式应用的诸多痛点不意味着应该使用者承受。这就好比，Linux 内核是世界上最复杂的软件之一，但我们使用它时却没有太多心智负担。这是因为它通过高度抽象屏蔽了底层硬件的复杂性。既然 Kubernetes 被称为“云原生时代的操作系统”，现在，也该考虑学习 Linux 内核抽象方式，寻找一种应用层的软件交付模型和抽象，将底层基础设施的能力以更友好的方式传递给最终用户。
 
 接下来，笔者将介绍几种业界主流的应用封装与交付思路，供你参考。

container/borg-omega-k8s.md

@@ -89,9 +89,7 @@ Google 开发的第三套容器管理系统是 Kubernetes，其背景如下：
 
 ## 7.1.4 以应用为中心的转变
 
-从最初的 Borg 到 Kubernetes，容器化技术的最大的益处早就超越了单纯提高资源使用率的范畴。更大的变化在于，**系统开发和运营的理念从以机器为中心迁移到了以应用程序为中心**。
-
-容器化使运营数据中心的观念从原来的面向机器转向了应用程序：
+容器化技术从最初的 Borg 到 Kubernetes，其收益早已超越了单纯提高资源利用率的范畴。更大的变化在于，系统开发和运维理念从“以机器为中心”转向“以应用为中心”。
 
 - 容器封装了应用程序运行的环境，屏蔽了操作系统和机器的细节，使业务开发者和基础设施管理者不再关注底层细节；
 - 每个设计良好的容器或容器镜像通常对应一个应用，管理容器即是管理应用，而非管理机器。