fix typo

Observability/dumps.md

@@ -14,7 +14,7 @@ A small number of signals which cause abnormal termination of a process
 ...
 ```
 
-上面的大致意思是，当程序异常终止时，Linux 系统会将程序的关键运行状态（如程序计数器、内存映像、堆栈跟踪等）导出到一个“核心文件”（core file）中。工程师使用调试器（如 gdb）打开核心文件，便可查看程序崩溃时的运行状态，从而更容易地定位到问题。
+上面的大致意思是，当程序异常终止时，Linux 系统会将程序的关键运行状态（如程序计数器、内存映像、堆栈跟踪等）导出到一个“核心文件”（core file）中。工程师使用调试器（如 gdb）打开核心文件，便可查看程序崩溃时的运行状态，更容易定位到问题。
 
 :::tip  注意
 复杂应用程序崩溃时甚至能生成几十 GB 大小的核心文件。默认情况下，核心文件的大小会受到 Linux 系统的限制。如果你想要为特定的程序生成一个无限制大小的核心文件，须通过命令 ulimit -c unlimited，告诉操作系统不要限制核心文件的大小。

application-centric/Helm.md

@@ -4,8 +4,7 @@
 
 相信读者朋友们知道 Linux 下的包管理工具和封装格式， 如 Debian 系的 apt-get 命令和 dpkg 格式、RHEL 系的 yum 命令和 rpm 格式。在 Linux 系统中，有了包管理工具，我们只要知道应用的名称，就可以很方便地从应用仓库中下载、安装、升级、回滚等，而且包管理工具掌握着应用的依赖信息和版本变更情况，具备完整的自管理能力，每个应用依赖哪些前置的第三方库，在安装时都会一并处理好。
 
-Helm 借鉴了各大 Linux 发行版的应用管理方式，引入了与 Linux 包管理对应的 Chart 格式和 Repository 仓库概念。对于用户而言，使用 Helm 无需了解 Kubernetes 的 YAML 语法或编写部署文件，只需一行命令，即可在 Kubernetes 集群内下载、安装所需应用。
-
+Helm 借鉴了各大 Linux 发行版的应用管理方式，引入了与 Linux 包管理对应的 Chart 格式和 Repository 仓库概念。对于用户而言，使用 Helm 无需了解 Kubernetes 的 YAML 语法或编写部署文件，只需一行命令，即可在 Kubernetes 集群内安装所需应用。
 
 Chart 是一个包含描述 Kubernetes 相关资源的文件集合，例如 WordPress chart 的目录结构是这样子的：
 

application-centric/Operator.md

@@ -18,12 +18,10 @@ Kubernetes v1.9 版本引入 StatefulSet 的核心功能就是用某种方式记
 容器化应用程序最困难的任务之一，就是设计有状态分布式组件的部署体系结构。
 
 
-
-
 其次，有状态应用的管理远不止，安装、启动、停止那么简单。应用实例的自愈、故障转移、负载均衡、备份、监控等等一系列运维操作也需要配套支持。
 
 
-如果使用 Operator，情况就简单得多。Etcd 的 Operator 提供了 EtcdCluster 自定义资源，在它的帮助下，仅用几十行代码，安装、启动、停止等基础的运维操作。但对于其他高级运维操作，例如升级、扩容、备份、恢复、监控和故障转移，如下面代码所示。
+如果使用 Operator，情况就简单得多。Etcd 的 Operator 提供了 EtcdCluster 自定义资源，在它的帮助下，仅用几十行代码，安装、启动、停止等基础的运维操作。
 
 ```yaml
 apiVersion: operator.etcd.database.coreos.com/v1beta2
@@ -44,7 +42,7 @@ spec:
             storage: 8Gi
 ```
 
-要扩容的话也很简单，只要更新数量（比如从 3 改到 5），再 apply 一下，它同样会监听这个自定义资源的变动，去做对应的更新。更高级的 Operator 还可以响应负载自动伸缩、备份和恢复、与 Prometheus 度量系统集成，甚至可以进行故障检测和自动调优。
+要扩容的话也很简单，只要更新节点数量（比如 size 从 3 改到 5），再 apply 一下，它同样会监听这个自定义资源的变动，去做对应的更新。更高级的 Operator 还可以自动升级、扩容、备份、恢复，甚至于 Prometheus 系统集成，处理故障检测以及故障转移。
 
 Operator 的实现上，其实是利用 CRD 构建了“高层抽象”，通过 Kubernetes 原生的“控制器模式”将有状态应用的运维操作代码化。这种设计带来的好处远不止操作简单，而是充分遵循 Kubernetes 基于资源和控制器的设计原则，又无需受限于内置资源的表达能力。只要开发者愿意编写代码，特定领域的经验都可以转换为代码，通过 Operator 继承。
 

network/XDP.md

@@ -4,13 +4,13 @@
 
 2016 年，Linux Netdev 会议，Linux 内核开发者 David S. Miller[^1] 喊出了“DPDK is not Linux”的口号。同年，随着 eBPF 技术成熟，Linux 内核终于迎来了属于自己的“高速公路” —— XDP（eXpress Data Path，快速数据路径）。XDP 因其媲美 DPDK 的性能、背靠 Linux 内核，无需第三方代码库和许可、无需专用 CPU 等多种优势，一经推出便备受关注。
 
-DPDK 技术完全绕过内核，直接将数据包透传至用户空间处理。XDP 正好相反，它根据用户定义的程序在内核空间处理数据包。那么，如何在内核中执行用户定义的程序呢？这需要用到 BPF（Berkeley Packet Filter，伯克利包过滤器）技术 —— 一种允许在内核空间运行经过安全验证的代码的机制。
+DPDK 技术完全绕过内核，直接将数据包透传至用户空间处理。XDP 正好相反，它在内核空间根据用户的逻辑处理数据包。
 
-自 Linux 内核 2.5 版本起，Linux 系统就开始支持 BPF 技术了。但早期的 BPF 主要用于网络数据包的捕获和过滤。到了 Linux 内核 3.18 版本，开发者推出了一套全新的 BPF 架构，也就是我们今天所说的 eBPF（Extended Berkeley Packet Filter）。与早期的 BPF 相比，eBPF 的功能不再局限于网络分析，它几乎能访问所有 Linux 内核关联的资源，逐渐发展成一个多功能的通用执行引擎。
+在内核执行用户逻辑的关键在于 BPF（Berkeley Packet Filter，伯克利包过滤器）技术 —— 一种允许在内核空间运行经过安全验证的代码的机制。Linux 内核 2.5 版本起，Linux 系统就开始支持 BPF 技术了，但早期的 BPF 主要用于网络数据包的捕获和过滤。到了 Linux 内核 3.18 版本，开发者推出了一套全新的 BPF 架构，也就是我们今天所说的 eBPF（Extended Berkeley Packet Filter）。与早期的 BPF 相比，eBPF 的功能不再局限于网络分析，它几乎能访问所有 Linux 内核关联的资源，逐渐发展成一个多功能的通用执行引擎。
 
-行文至此，相信读者不难发现 eBPF 访问 Linux 内核关联资源的手段，其实和 Netfilter 开放钩子的方式如出一辙。区别在于，Netfilter 的钩子数量有限，面向的是 Linux 其他内核模块。而 eBPF 程序面向普通开发者，Linux 系统中开放了“数不清”的钩子挂载 eBPF 程序。
+行文至此，相信读者不难发现 eBPF 访问 Linux 内核关联资源的手段，其实和 Netfilter 开放钩子的方式如出一辙。两者区别在于，Netfilter 的钩子数量有限，面向的是 Linux 其他内核模块；而 eBPF 程序面向普通开发者，Linux 系统中开放了“数不清”的钩子挂载 eBPF 程序。
 
-列举部分钩子的名称及含义供你参考：
+笔者列举部分钩子的名称及含义供读者参考：
 
 - TC（Traffic Control）钩子：位于内核的网络流量控制层，用于处理流经 Linux 内核的网络数据包。它可以在数据包进入或离开网络栈的各个阶段触发。
 - XDP 钩子：位于网络栈最底层的钩子，直接在网卡驱动程序中触发，用于处理收到的网络数据包，主要用于实现超高速的数据包处理操作，例如 DDoS 防护、负载均衡、数据包过滤等。