更新内容

Observability/OpenTelemetry.md

@@ -12,9 +12,9 @@ OpenTracing 推出不久之后，Google 和微软联合推出了 OpenCensus 项
 
 OpenCensus 最初是 Google 内部监控工具，开源的目地并不是抢 OpenTracing 的饭碗，而是希望为分布式系统提供一个统一的、跨语言的、开箱即用的可观测性框架，既能够处理链路追踪（trace），又能够处理指标（metrics）。
 
-虽说 OpenTracing 和 OpenCensus 推动了可观测性系统的发展，但它们作为可观测领域下的协议标准，彼此之间的竞争和分裂不可避免地消耗了社区资源。对用户而言，一边是老牌 APM 厂商，另一边是拥有强大影响力的 Google 和微软。选择困难症发作时，一个新的设想开始被不断讨论：“能否有一个统一的标准，能够同时支持指标、追踪和日志等各类遥测数据？”。
+虽说 OpenTracing 和 OpenCensus 推动了可观测性系统的发展，但它们作为可观测领域下的协议标准，彼此之间的竞争和分裂不可避免地消耗了大量社区资源。对于普通开发者而言，一边是老牌 APM 厂商，另一边是拥有强大影响力的 Google 和微软。选择困难症发作时，一个新的设想开始被不断讨论：“能否有一个统一的标准，能够同时支持指标、追踪和日志等各类遥测数据？”。
 
-2019 年，OpenTracing 和 OpenCensus 的维护者决定将两个项目整合在一起，将链路追踪、指标和日志的处理融合在一起，形成一个统一的解决方案 —— OpenTelemetry。
+2019 年，OpenTracing 和 OpenCensus 的维护者决定将两个项目整合在一起，提供各类遥测数据统一采集解决方案 —— OpenTelemetry。
 
 OpenTelemetry 覆盖了各类遥测数据规范定义、API 定义、规范实现以及数据的获取与传输。目标是解决的是遥测数据统一的第一步：通过 API 和 SDK 来标准化遥测数据采集和传输。之后，遥测数据如何使用、存储、展示和告警，OpenTelemetry 本身并不涉及。这使得 OpenTelemetry 既不会因动了“数据的蛋糕”，引起生态抵制，也极大保存了精力，得以专注实现兼容“所有的语言、所有的系统”的遥测数据采集器（OpenTelemetry Collector）。
 

ServiceMesh/ServiceMesh-and-Kubernetes.md

@@ -1,4 +1,4 @@
-# 8.4 服务网格与 Kubernetes
+# 8.7 服务网格与 Kubernetes
 
 
 以 Kubernetes 为基础构建起的云原生世界里，Sidecar 模式无疑是最经典的设计。当需要为应用提供与自身逻辑无关的辅助功能时，在应用 Pod 内注入对应功能的 Sidecar 显然弥补了容器编排系统对服务间通信管控能力不足的缺憾。

ServiceMesh/The-future-of-ServiceMesh.md

@@ -1,4 +1,4 @@
-# 8.5 服务网格的未来
+# 8.8 服务网格的未来
 
 随着服务网格落地实践，Sidecar 模式的缺点也逐渐被暴露：
 

ServiceMesh/conclusion.md

@@ -1,4 +1,4 @@
-# 8.6 小结
+# 8.9 小结
 
 本章第二节，我们完整回顾了服务间通信的演变，相信你完全理解了服务网格出现的背景，以及它到底解决了什么问题。
 

ServiceMesh/control-plane.md

@@ -1,2 +1,2 @@
-# 控制平面技术
+# 8.4 控制平面技术
 

ServiceMesh/data-plane.md

@@ -1,4 +1,4 @@
-# 8.4 数据平面技术
+# 8.3 数据平面技术
 
 
 

ServiceMesh/overview.md

@@ -1,4 +1,4 @@
-# 8.3 服务网格的产品与生态
+# 8.6 服务网格的产品与生态
 
 Buoyant 公司在 2016 年发布了第一代服务网格 Linkerd，同一时期，离开 Twitter 的工程师 Matt Klein 加入了 Lyft，并开启了 Envoy 项目。第一代服务网格稳步推进的过程中，世界的另一角落，Google 和 IBM 两个巨头开始握手合作，它们联合 Lyft 启动了 Istio 项目。
 
@@ -23,11 +23,13 @@ Istio 最大的创新在于它为服务网格带来前所未有的控制力：
 
 ## 8.3.2 Linkerd 2.0 出击
 
-Istio 被争相追捧的同时，作为服务网格概念的创造者 William Morgan 自然不甘心出局，公司生死存亡之际，瞄准 Istio 的缺陷（过于复杂）并借鉴 Istio 的设计理念（新增控制平面），开始重新设计它们的服务网格。
+Istio 被争相追捧的同时，作为服务网格概念的创造者 William Morgan 自然不甘心出局。
 
-Buoyant 公司的第二代服务网格使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit，主打轻量化，目标是世界上最轻、最简单、最安全的 Kubernetes 专用服务网格。该项目最初以 Conduit 命名，在 Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为 Linkerd 2[^1]，
+公司生死存亡之际，William Morgan 瞄准 Istio 的缺陷（过于复杂）并借鉴 Istio 的设计理念（新增控制平面），开始重新设计它们的服务网格产品。
 
-Linkerd2 的架构如图 8-12 所示，增加了控制平面，但整体简单：
+Buoyant 公司的第二代服务网格使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit，主打轻量化，目标是世界上最轻、最简单、最安全的 Kubernetes 专用服务网格。该产品最初以 Conduit 命名，Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为 Linkerd 2[^1]，
+
+Linkerd2 的架构如图 8-12 所示，增加了控制平面，但整体相对简单：
 - 控制层面组件只有 destination（类似 Istio 中的 Pilot 组件）、identity（类似 Istio 中的 Citadel）和 proxy injector（代理注入器，自动将 Linkerd 代理作为 Sidecar 容器注入到匹配的 Pod 中，无需手动修改应用程序的部署配置）。
 - 数据平面中 linkerd-init 设置 iptables 规则拦截 Pod 中的 TCP 连接，linkerd-proxy 实现对所有的流量管控（负载均衡、熔断..）。
 

architecture/container.md

@@ -8,23 +8,23 @@
 
 ## 1.chroot 阶段：隔离文件系统
 
-容器技术并不是凭空出现的，而是具有非常久远的历史。
+容器技术并不是凭空出现的，它具有非常久远的历史。
 
-早在 1979 年，贝尔实验室在开发 Unix V7 的过程中，发现当一个系统软件编译和安装完成后，整个测试环境的变量就会发生改变，如果要进行下一次构建、安装和测试，就必须重新搭建和配置测试环境。
+早在 1979 年，贝尔实验室的工程师在开发 Unix V7 期间，发现当一个系统软件编译和安装完成后，整个测试环境的变量就会发生改变，如果要进行下一次构建、安装和测试，就必须重新搭建和配置测试环境。
 
-开发者们开始思考，能否在现有的操作系统环境下，隔离出一个用来重构和测试软件的独立环境？于是，一个叫做 chroot（Change Root）的系统调用功能就此诞生。
+工程师们开始思考：“能否在现有的操作系统环境下，隔离出一个用来重构和测试软件的独立环境？”。于是，一个叫做 chroot（Change Root）的系统调用功能就此诞生。
 
-chroot 被认为是最早的容器化技术之一，它可以重定向进程及其子进程的 root 目录到文件系统上的新位置，也就是说使用它可以分离每个进程的文件访问权限，使得该进程无法接触到外面的文件。
+chroot 被认为是最早的容器技术之一，它可以重定向进程 root 目录到文件系统上某个新位置，也就是说使用它可以分离每个进程的文件访问权限，使得该进程无法接触到外面的文件。
 
-通过 chroot 隔离出来的新环境得到了一个非常形象的命名 Jail（监狱），这便是容器最重要的特性 —— 隔离。
+通过 chroot 隔离出来的新环境得到了一个形象的命名 Jail（监狱），这便是容器最重要的特性 —— 隔离。
 
 ## 2.LXC 阶段：封装系统 
 
 2006 年，Google 推出 Process Container（进程容器），Process Container 目的非常直白，它希望能够像虚拟化技术那样给进程提供操作系统级别的资源限制、优先级控制、资源审计和进程控制能力。
 
 带着这样的设计思路，Process Container 推出不久就进入了 Linux 内核主干，不过由于 container 这一命名在内核中具有许多不同的含义，为了避免代码命名的混乱，后来就将 Process Container 更名为了 Control Groups —— 简称 cgroups。
 
-2008 年 Linux 内核版本 2.6.24 刚开始提供 cgroups，社区开发者就将 cgroups 资源管理能力和 Linux namespace 资源隔离能力组合在一起，形成了完整的容器技术 LXC（Linux Container，Linux 容器）。
+2008 年，Linux 内核版本 2.6.24 刚开始提供 cgroups，社区开发者就将 cgroups 资源管理能力和 Linux namespace 资源隔离能力组合在一起，形成了完整的容器技术 LXC（Linux Container，Linux 容器）。
 
 LXC 是如今被广泛应用的容器技术的实现基础，通过 LXC 可以在同一主机上运行多个相互隔离的 Linux 容器，**每个容器都有自己的完整的文件系统、网络、进程和资源隔离环境，容器内的进程如同拥有一个完整、独享的操作系统**。
 
@@ -97,11 +97,11 @@ Docker 把与内部负责管理容器执行、分发、监控、网络、构建
  图 1-15 拆分后的 Docker 架构
 :::
 
-从拆分后的 Docker 架构图来看 ，容器运行时根据功能的不同分成了两类：
-- 只关注如 namespace、cgroups、镜像拆包等基础的容器运行时实现被称为**低层运行时（low-level container runtime）**， 目前应用最广泛的低层运行时是 runc；
-- 支持更多高级功能，例如镜像管理、容器应用的管理等，被称为**高层运行时（high-level container runtime）**，目前应用最广泛高层运行时是 containerd。
+根据拆分后的 Docker 架构图看 ，根据功能的不同，容器运行时被分成两类：
+- 只关注如 namespace、cgroups、镜像拆包等基础的容器运行时实现被称为**低层运行时（low-level container runtime）**。目前应用最广泛的低层运行时是 runc；
+- 支持更多高级功能，如镜像管理、容器应用的管理等，被称为**高层运行时（high-level container runtime）**。目前应用最广泛高层运行时是 containerd。
 
-这两类运行时按照各自的分工，在 OCI 标准规范下，共同协作完成容器整个生命周期的管理工作。
+在 OCI 标准规范下，两类运行时履行各自的职责，协作完成整个容器生命周期的管理工作。
 
 ## 5.容器编排阶段：封装集群
 
@@ -128,7 +128,7 @@ OCI 和 CNCF 这两个围绕容器的基金会对云原生生态的发展发挥
  图 1-16 OCI 以及 CNCF 容器相关规范的关系
 :::
 
-这些行业事实标准的确立，为软件相关的各行业注入了无限活力，基于接口标准的具体实现不断涌现，呈现出一片百花齐放的景象。
+这些行业事实标准的确立，为软件相关的各行业注入了无限活力，基于标准接口的具体实现不断涌现，呈现出一片百花齐放的景象。
 
 如图 1-17 所示，迄今为止在其 CNCF 公布的云原生全景图中，显示了近 30 个领域、数百个项目的繁荣发展，从数据存储、消息传递，到持续集成、服务编排乃至网络管理无所不包、无所不含。
 

balance/summary.md

@@ -11,7 +11,7 @@
 
 以集群形式对外提供服务时，无论用户请求由哪台服务器处理，都应获得一致的结果。另一方面，集群需对用户保持足够的度透明。也就是说，客户端与集群交互时仿佛面对一台高性能、高可用的单一服务器。集群中的服务器可以动态加入或退出而不影响服务，用户不会察觉这些变化，也无需修改任何配置。
 
-为集群提供统一入口并实现上述职责的组件称为负载均衡。根据软硬件层面的不同，负载均衡可分为：利用专用网络设备（如 F5、Cisco、A10 等）实现的硬件负载均衡；基于通用服务器的应用程序（如 Nginx、HAProxy、Traefik 等）实现的软件负载均衡。根据负载均衡的部署拓扑来讲，又有中间代理型、边缘代理、客户端内嵌等等形式。
+为集群提供统一入口并实现上述职责的组件称为负载均衡（或称代理）。根据软硬件层面的不同，负载均衡可分为：利用专用网络设备（如 F5、Cisco、A10 等）实现的硬件负载均衡；基于通用服务器的应用程序（如 Nginx、HAProxy、Traefik 等）实现的软件负载均衡。根据负载均衡的部署拓扑来讲，又有中间代理型、边缘代理、客户端内嵌等等形式。
 
 无论负载均衡以何种形式存在，或在集群中的何处部署，它们的核心职责无外乎 “选择处理用户请求的目标”（即负载均衡算法）和“将用户请求转发至目标”（即负载均衡的工作模式）。本章我们围绕这两个核心职责，分析各类负载均衡的原理、工作模式，掌握各类负载均衡应用技术。
 :::center

container/Resource-scheduling.md

@@ -1,11 +1,11 @@
 # 7.7 资源模型及编排调度
 
-本节所述的“资源模型”指的是狭义上的物理资源（如 CPU、内存、存储）。物理资源与 Kubernetes 的基本单元 Pod 存在直接的供需关系，并影响调度逻辑的设计。
+本节所述的“资源模型”指的是狭义上的物理资源（如 CPU、内存、存储）。物理资源与 Kubernetes 的基本单元 Pod 存在直接的供需关系，并影响容器编排调度逻辑的设计。
 
-从编排和调度 Pod 的角度来看，调度（scheduling）的职责是实现资源提供者（Node）与资源使用者（Pod）之间的最佳匹配。要达成这一目标，管理和分配集群资源时至少需要明确以下几个问题：
+从编排调度 Pod 的层面看，调度（scheduling）的职责是实现资源提供者（Node）与资源使用者（Pod）之间的最佳匹配。要达成这一目标，管理和分配集群资源时至少需要清楚以下几个问题：
 
 - 集群中有哪些种类的资源，如何表示这些资源，即资源模型该如何设计？
 - 如何描述容器的资源请求？如何描述一个 Node 当前的资源分配状态，例如已分配资源和未分配资源的数量？
 - 如果节点资源不足，节点中的容器该如何处理？
 
-接下来，笔者将根据上述问题，介绍 Kubernetes 的资源模型、QoS（Quality of Service，服务质量）以及 Pod 调度器的设计。
+接下来，笔者将根据上述问题展开，介绍 Kubernetes 资源模型、QoS（Quality of Service，服务质量）以及调度器（kube-scheduler）的设计。

container/kube-scheduler.md

@@ -1,8 +1,8 @@
 # 7.7.3 调度器与扩展设计
 
-如果集群只有几十个节点，为新创建的 Pod 找到最合适的节点并不困难，但当节点规模达到几千台甚至更多时，问题就复杂了。
-
-首先，Pod 的创建/更新和节点资源无时无刻不在发生变化，如果每次调度都需要数千次远程请求获取相关信息，势必因耗时过长，导致调度失败率过高。其次，调度器频繁的网络请求会使其成为集群的性能瓶颈。
+如果集群只有几十个节点，为新创建的 Pod 找到最合适的节点并不困难，但当节点规模达到几千台甚至更多时，问题就变得复杂了：
+- 首先，Pod 的创建/更新和节点资源无时无刻不在发生变化，如果每次调度都需要数千次远程请求获取相关信息，势必因耗时过长，导致调度失败率过高。
+- 另一方面，调度器频繁的网络请求极容易使其成为集群的性能瓶颈。
 
 :::tip <a/>
 为了充分利用硬件资源，通常会将各种类型(CPU 密集、IO 密集、批量处理、低延迟作业)的 workloads 运行在同一台机器上，这种方式减少了硬件上的投入，但也使调度问题更加复杂。
@@ -24,7 +24,7 @@ Kubernetes 默认调度器（kube-scheduler）双循环调度机制如图 7-36 
 
 根据图 7-37 可以看出，Kubernetes 调度的核心在于两个互相独立的控制循环。
 
-第一个控制循环称为 Informer 循环。该循环的主要逻辑是启动一系列 Informer 监听（Watch）API 资源（主要是 Pod 和 Node）状态的变化。当 API 资源变化时，触发 Informer 回调函数进一步处理。例如，一个待调度 Pod 被创建后，触发 Pod Informer 回调函数，该回调函数将 Pod 入队到调度队列中（PriorityQueue），待下一阶段处理。
+第一个控制循环称为 Informer 循环。该循环的主要逻辑是启动一系列 Informer 监听（Watch）API 资源（主要是 Pod 和 Node）状态的变化。当 API 资源变化时，触发 Informer 回调函数进一步处理。如一个待调度 Pod 被创建后，触发 Pod Informer 回调函数，该回调函数将 Pod 入队到调度队列中（PriorityQueue），待下一阶段处理。
 
 当 API 资源变化时，Informer 的回调函数还承担对调度器缓存（即 Scheduler Cache）更新的职责，该操作的目的是尽可能将 Pod、Node 的信息缓存化，以便提升后续阶段调度算法的执行效率。