更新k8s 内容

Observability/logging.md

@@ -140,9 +140,9 @@ ORDER BY id;
   图 9-8 同一份日志在 Elasticsearch、ClickHouse 和 ClickHouse(zstd) 中的容量对比
 :::
 
-ClickHouse 支持分片（Sharding），这是实现水平扩展和分布式并行查询的关键特性。通过增加更多的节点，Clickhouse 能实现处理数百亿到数万亿条记录，以及数 PB 级别的数据。
+ClickHouse 支持分片（Sharding），也就是支持分布式并行计算。通过增加更多的节点，Clickhouse 能实现处理数百亿到数万亿条记录，以及数 PB 级别的数据。
 
-根据 Yandex 的内部跑分结果来看（图 9-9），ClickHouse 比 Vertia（一款商业的 OLAP 分析软件）快约 5 倍、比 Hive 快 279 倍、比 InifniDB 快 31 倍。ClickHouse 表现的惊人的查询性能，当之无愧阐述 ClickHouse 介绍中“实时”（real-time）二字含义。
+根据 Yandex 的内部跑分结果来看（图 9-9），在一亿条记录的规模上，ClickHouse 比 Vertia（一款商业的 OLAP 分析软件）快约 5 倍、比 Hive 快 279 倍、比 InifniDB 快 31 倍。ClickHouse 表现的惊人的查询性能，当之无愧阐述 ClickHouse 介绍中“实时”（real-time）二字含义。
 
 
 :::center

architecture/summary.md

@@ -19,4 +19,4 @@
   图 1-0 本章内容导读
 :::
 
-[^1]: Tobias Lütke，互联网著名的技术创业者。他在 2006 年创建的 Shopify 已成为全球最大的电子商务平台之一。
+[^1]: Tobias Lütke，著名的技术创业者。他在 2006 年创建的 Shopify 已成为全球最大的电子商务平台之一。

container/kube-scheduler.md

@@ -20,13 +20,19 @@ Omega 的论文中提出了一种基于共享状态（图 7-1 中的 Scheduler C
 Kubernetes 默认调度器（kube-scheduler）双循环架构如下所示。
 
 :::center
-  ![](../assets/kube-scheduler.png)<br/>
+  ![](../assets/kube-scheduler.svg)<br/>
   图 7-37 kube-scheduler 双循环架构设计
 :::
 
 - 第一个控制循环称之为 Informer Path，它主要目的是启动一系列 Informer 监听（Watch）Etcd 中 Pod、Node、Service 等与调度相关的 API 对象的变化。譬如一个待调度 Pod 被创建后，调度器就会通过 Pod Informer 的 Handler 将这个待调度 Pod 添加进调度队列。Kubernetes 的调度器还要负责对调度器缓存（即 Scheduler Cache）进行更新，缓存的目的主要是对调度部分进行性能优化，将集群信息 cache 化，以便提升 Predicate 和 Priority 调度算法的执行效率。
 
-- 第二个控制循环是调度器负责 Pod 调度的主循环，被称之为 Scheduling Path。Scheduling Path 主要逻辑是不断地从调度队列里出队一个 Pod。然后调用 Predicates 算法对所有的 Node 进行“过滤”。“过滤”得到的一组可以运行这个 Pod 的 Node 列表。当然，Predicates 算法需要的 Node 信息，也都是 Scheduler Cache 里直接拿到的，这是调度器保证算法执行效率的主要手段之一。接下来，调度器就会再调用 Priorities 算法为上述列表里的 Node 打分，得分最高的 Node 就会作为这次调度的结果。
+第二个控制循环称为 Scheduling Path ，是负责 Pod 调度的主循环。Scheduling Path 主要逻辑是不断地从调度队列里出队一个 Pod。
+
+- 预选（predicates）就是从集群的所有节点中根据调度算法筛选出所有可以运行该 pod 的节点集合
+- 优选（priority）则是按照算法对预选出来的节点进行打分，找到分值最高的节点作为调度节点.
+
+
+然后调用 Predicates 算法对所有的 Node 进行“过滤”。“过滤”得到的一组可以运行这个 Pod 的 Node 列表。当然，Predicates 算法需要的 Node 信息，也都是 Scheduler Cache 里直接拿到的，这是调度器保证算法执行效率的主要手段之一。接下来，调度器就会再调用 Priorities 算法为上述列表里的 Node 打分，得分最高的 Node 就会作为这次调度的结果。
 
 	调度算法执行完成后，调度器就需要将 Pod 对象的 nodeName 字段的值，修改为上述 Node 的名字，这个过程在 Kubernetes 里面被称作 Bind。为了不在关键调度路径里远程访问 API Server，Kubernetes 默认调度器在 Bind 阶段只会更新 Scheduler Cache 里的 Pod 和 Node 的信息。这种基于“乐观”假设的 API 对象更新方式，在 Kubernetes 里被称作 Assume。Assume 之后，调度器才会创建一个 Goroutine 异步地向 API Server 发起更新 Pod 的请求，完成真正 Bind 操作。
 

distributed-transaction/summary.md

@@ -9,7 +9,7 @@
 :::
 
 
-提及事务（transaction），最早指本地事务，也就是在本地对某个数据库的多个读、写操作捆绑在一起形成一个逻辑操作单元。这些操作作为一个整体要么全部成功，要么全部失败，从而保证数据在极端情况下的一致性。不过分布式系统盛行之后，事务处理的范畴不再局限于数据库内，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性处理等等，都需要用到事务的机制进行处理。
+提及事务（transaction），最早指本地事务，也就是在本地对某个数据库的多个读、写操作捆绑在一起形成一个操作单元。该操作单元作为一个整体要么全部成功，要么全部失败，从而保证数据在极端情况下的一致性。不过，分布式系统盛行之后，事务处理的范畴不再局限于数据库内，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性处理等等，都需要用到事务的机制进行处理。
 
 如果对一致性要求只局限于本地操作单个数据源时，那么如何实现事务仅仅是个编码问题。但若操作涉及了跨多个网络节点，保证分布式系统下数据的一致性便成了架构设计问题。2000 年以前，人们曾经希望基于两阶段提交（2PC）的事务机制，也能在现代分布式系统中良好运行，但这个愿望被 CAP 定理粉碎。本章，我们深入理解分布式环境下数据一致性和可用性的矛盾，彻底掌握各个分布式事务模型。
 

network/DPDK.md

@@ -2,9 +2,9 @@
 
 2010 年，由 Intel 领导的 DPDK（Data Plane Development Kit，数据平面开发套件）实现了一套基于“内核旁路”思想的高性能网络应用开发解决方案，并逐渐成为了独树一帜的成熟技术体系。
 
-起初，DPDK 实际上是 Intel 为了卖自家的硬件，针对 Intel 处理器和网卡开发的一款高性能的网络驱动组件。DPDK 开源之后，越来越多的厂商参与进来贡献代码，这使得 DPDK 支持更多的处理器和网卡，如处理器不仅支持 Intel，还支持 AMD、ARM 等厂商的处理器，网卡支持的范围也包括 Intel 网卡、Mellanox 网卡、ARM 集成网卡等。
+起初，DPDK 实际上是 Intel 为了卖自家的硬件，针对 Intel 处理器和网卡开发的一款高性能的网络驱动组件。DPDK 开源之后，越来越多的厂商参与进来贡献代码，这使得 DPDK 支持更多的处理器和网卡。例如，处理器不仅支持 Intel，还支持 AMD、ARM 等厂商的处理器；网卡支持的范围也包括 Intel 网卡、Mellanox 网卡、ARM 集成网卡等。
 
-图 3-6 对比展示了 DPDK 与传统内核网络。在 Linux 系统中，位于用户空间的 DPDK Lib 和 APP 被视为一个普通的用户进程，其编译、连接和加载方式和普通程序没什么区别。但两者网络数据包在 Linux 系统中的传输路径完全不同：
+图 3-6 展示了 DPDK 与传统内核网络的区别。在 Linux 系统中，位于用户空间的 DPDK Lib 和 APP 被视为一个普通的用户进程，其编译、连接和加载方式和普通程序没什么区别。但两者网络数据包在 Linux 系统中的传输路径完全不同：
 
 - 左侧展示的是传统内核方式：网络数据包自网络接口卡（NIC）出发，经过驱动程序，内核协议栈，最后通过 Socket 接口传递至业务逻辑。
 - 右侧则展示的是 DPDK 方式：在该方案中，网络数据包利用用户空间 I/O（UIO）技术，直接绕过内核协议栈，从网卡转移到 DPDK 基础库，然后传递至业务逻辑。也就是说 DPDK 绕过了 Linux 内核协议栈对数据包的处理过程，在用户空间直接对数据包进行收发与处理。

network/RDMA.md

@@ -5,8 +5,8 @@
 近年来，随着人工智能、分布式训练和分布式数据存储快速增长，对数据中心的网络延迟和吞吐量也要求越来越高。曾用于高性能计算领域的 RDMA 技术逐渐成为满足这些需求的首选解决方案。
 
 RDMA（Remote Direct Memeory Access，远程直接内存访问）是一种绕过远程主机操作系统直接访问其内存的技术，其设计源自于 DMA 技术：
-- 在 DMA 技术中，允许内部设备（如硬盘、网卡等）直接访问内存，中间不需要经过 CPU 的参与；
-- 而 RDMA 则是指主机之间的远程数据交换，也能像 DMA 那样，绕过传统的 TCP/IP 网络协议栈以及远程主机操作系统，就像读取本地内存一样。
+- 在 DMA 技术中，允许主机内部设备（如硬盘、网卡等）直接访问内存，中间不需要经过 CPU 的参与；
+- RDMA 则是指主机之间的远程数据交换，也能像 DMA 那样，绕过远程主机操作系统以及 TCP/IP 协议栈，就像读取本地内存一样。
 
 RDMA 的工作原理如图 3-10 所示，RDMA 绕过了传统以太网和主机内 TCP/IP 协议栈，应用直接通过网卡硬件就能与远程主机交互。由于不经过操作系统，大幅提升网络吞吐量的同时，还节省了大量 CPU 资源以及降低了网络通信延迟。
 
@@ -18,7 +18,7 @@ RDMA 的工作原理如图 3-10 所示，RDMA 绕过了传统以太网和主机
 RDMA 网络主要由三种协议实现：Infiniband、RoCE 和 iWARP，它们的含义与区别如下：
 
 - Infiniband（无限带宽）是一种专门为 RDMA 设计的网络协议，由 IBTA（InfiniBand Trade Association，
-InfiniBand 贸易协会）在 2000 年提出。构建 Infiniband 网络需要配备全套专用设备，包括专用网卡、交换机和线缆，从硬件层面确保网络的无损传输，能够实现小于 3 微秒的时延和 400Gb/s 以上的网络吞吐量。值得一提的是，风靡全球的人工智能应用 ChatGPT 背后的分布式机器学习系统就是基于 Infiniband 网络构建的。但极致性能的背后是 Infiniband 网络需要特定厂商提供的专用产品，采用的是私有协议，不兼容现有的 IP 以太网。同时，封闭的架构也带来设备昂贵，技术方案被锁定的一系列缺陷。
+InfiniBand 贸易协会）在 2000 年提出。构建 Infiniband 网络需要配备全套专用设备，包括专用网卡、交换机和线缆，从硬件层面确保网络的无损传输，能够实现小于 3 μs 时延和 400Gb/s 以上的网络吞吐量。值得一提的是，风靡全球的人工智能应用 ChatGPT 背后的分布式机器学习系统就是基于 Infiniband 网络构建的。但极致性能的背后是 Infiniband 网络需要特定厂商提供的专用产品，采用的是私有协议，不兼容现有的 IP 以太网。同时，封闭的架构也带来设备昂贵，技术方案被锁定的一系列缺陷。
 - iWRAP（Internet Wide Area RDMA Protocol，互联网广域 RDMA 协议）是一种封装在 TCP/IP 协议内的 RDMA 网络协议，需要支持 IWARP 的特殊网卡。RDMA 技术为了高性能而生，而 TCP/IP 为了可靠性而生，TCP/IP 协议三次握手、拥塞控制等机制让 IWARP 失去了绝大部分 RDMA 技术的优势。所以，iWRAP 已经逐渐被业界抛弃。
 - 为了降低 RDMA 使用成本，以及使 RDMA 技术走向通用数据中心领域，2010 年，IBTA 发布了 RoCE（RDMA over Converged Ethernet，融合以太网的远程直接内存访问）技术，将 Infiniband 的四层传输协议 RDMA“移植”到以太网。这样，只要有支持 RoCE 的特殊网卡 + 普通的以太网交换机就能享受 RDMA 高性能。RoCE 的发展过程中出现了两个协议版本 RoCEv1 和 RoCEv2：RoCEv1 是一种链路层协议，仅支持在二层在一个广播域内互通；而 RoCEv2 是一种网络层协议，允许不同广播域下的主机通过三层 IP 网络互通。可以看出，RoCEv2 解除了 RoCEv2 无法跨子网的限制，同时结合本身固有的低成本以及兼容性优势，开始被广泛应用于分布式存储以及分布式并行计算等通用数据中心场景。根据云计算平台 Azure 公开的信息，2023 年 Azure 整个数据中心 70% 的流量已经是 RDMA 流量了[^1]。
 :::center

network/summary.md

@@ -17,4 +17,4 @@
   图 3-0 本章内容导读
 :::
 
-[^1]: Linus Torvalds，最著名的程序员之一。Linus Torvalds 是 Linux 内核的最早作者。他还开发了代码版本管理工具 Git，因此也被戏称为程序员的祖师爷。
+[^1]: Linus Torvalds，最著名的程序员之一。Linus Torvalds 是 Linux 内核的最早作者，被称为“Linux 之父”。他还开发了代码版本管理工具 Git，因此也被戏称为程序员的祖师爷。