diff --git a/Observability/OpenTelemetry.md b/Observability/OpenTelemetry.md
index 4e6dc0b0..6b1eb3ca 100644
--- a/Observability/OpenTelemetry.md
+++ b/Observability/OpenTelemetry.md
@@ -16,7 +16,7 @@ OpenCensus 最初是 Google 内部监控工具,开源的目地并不是抢 Ope
2019 年,OpenTracing 和 OpenCensus 的维护者决定将两个项目整合在一起,提供各类遥测数据统一采集解决方案 —— OpenTelemetry。
-OpenTelemetry 覆盖了各类遥测数据规范定义、API 定义、规范实现以及数据的获取与传输。目标是解决的是遥测数据统一的第一步:通过 API 和 SDK 来标准化遥测数据采集和传输。之后,遥测数据如何使用、存储、展示和告警,OpenTelemetry 本身并不涉及。这使得 OpenTelemetry 既不会因动了“数据的蛋糕”,引起生态抵制,也极大保存了精力,得以专注实现兼容“所有的语言、所有的系统”的遥测数据采集器(OpenTelemetry Collector)。
+OpenTelemetry 做的事情是,标准化遥测数据的定义、采集。至于采集后如何使用、存储、展示、告警,OpenTelemetry 本身并不涉及。这使得 OpenTelemetry 既不会因动了“数据的蛋糕”,引起生态抵制,也极大保存了精力,得以专注实现兼容“所有的语言、所有的系统”的“遥测数据采集器”(OpenTelemetry Collector)。
如图 9-17 所示,集成了 OpenTelemetry 的可观测系统:
- 应用程序只需要一种 SDK 就可以实现所有类型遥测数据的统一产生;
@@ -30,4 +30,4 @@ OpenTelemetry 覆盖了各类遥测数据规范定义、API 定义、规范实
:::
-自 2019 年发布,OpenTelemetry 便得到了广泛的社区支持。现如今,多数的云服务提供商和容器平台,如 AWS、Google Cloud、Azure、阿里云等均已开始支持和推广 OpenTelemetry。在复杂的微服务架构和云原生环境中,OpenTelemetry 已成为可观测领域遥测数据生成和收集的事实标准。
\ No newline at end of file
+自 2019 年发布,OpenTelemetry 便得到了社区的广泛支持。现如今,多数的云服务提供商和容器平台,如 AWS、Google Cloud、Azure、阿里云等均已开始支持和推广 OpenTelemetry。在复杂的微服务架构和云原生环境中,OpenTelemetry 已成为可观测领域遥测数据生成和收集的事实标准。
\ No newline at end of file
diff --git a/application-centric/Operator.md b/application-centric/Operator.md
index 2e3909b7..d4062eed 100644
--- a/application-centric/Operator.md
+++ b/application-centric/Operator.md
@@ -125,10 +125,9 @@ spec:
storage: 8Gi
```
-Operator 本身在实现上,其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它合理的利用了 Kubernetes API 可以添加自定义 API 类型的能力,然后又巧妙的通过 Kubernetes 原生的“控制器模式”,完成了一个面向分布式应用终态的调谐过程。
+Operator 本身在实现上,其实是在 Kubernetes 声明式 API 基础上的一种“微创新”。它利用了 CRD 构建“高层抽象”,又通过 Kubernetes 原生的“控制器模式”,完成了一个面向分布式应用终态的“调谐”过程。
-
-使用 CRD 构建“高层抽象”,带来的好处远不止使用简单。
+带来的好处远不止使用简单。
就是把运维的经验沉淀为代码,实现运维的代码化、自动化、智能化。以往的高可用、扩展收缩,以及故障恢复等等运维操作,都通过 Operator 进行沉淀下来。
diff --git a/container/kube-scheduler.md b/container/kube-scheduler.md
index 893202b5..abfa881a 100644
--- a/container/kube-scheduler.md
+++ b/container/kube-scheduler.md
@@ -1,8 +1,8 @@
# 7.7.3 调度器与扩展设计
-如果集群中节点的数量只有几十个,为新创建的 Pod 找到最合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时,问题就变得复杂了:
-- 首先,Pod 的创建、更新还有节点资源无时无刻不在变化,如果每次调度都需要数千次远程请求获取信息,势必因耗时过长,增加调度失败的风险。
-- 其次,调度器频繁发起网络请求,极容易成为集群性能的关键瓶颈,影响整个集群的运行效率。
+如果集群中节点的数量只有几十个,为新建的 Pod 找到合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时,情况就复杂了:
+- 首先,Pod 的创建、更新、节点资源无时无刻不在变化,如果每次调度都需要数千次远程请求获取信息,势必因耗时过长,增加调度失败的风险。
+- 其次,调度器频繁发起网络请求,极容易成为性能瓶颈,影响整个集群的运行效率。
:::tip
为了充分利用硬件资源,通常会将各种类型(CPU 密集、IO 密集、批量处理、低延迟作业)的 workloads 运行在同一台机器上,这种方式减少了硬件上的投入,但也使调度问题更加复杂。
@@ -150,12 +150,12 @@ profiles:
经过优选阶段之后,调度器根据预定的打分策略为每个节点分配一个分数,最终选择出分数最高的节点来运行 Pod。如果存在多个节点分数相同,调度器则随机选择其中一个。
-经过预选筛选,优选的打分之后,调度器已选择出调度的最终目标节点。最后一步是通知目标节点中的 Kubelet 创建 Pod 了。
+经过预选阶段筛选,优选阶段的打分之后,调度器选择最终目标节点,最后阶段是通知目标节点内的 Kubelet 创建 Pod 了。
-这一阶段,调度器并不会直接与 Kubelet 通信,而是将 Pod 对象的 nodeName 字段的值,修改为上述选中 Node 的名字即可。Kubelet 会持续监控 Etcd 中 Pod 信息的变化,然后执行一个称为“Admin”的本地操作,确认资源是否可用、端口是否冲突,实际上就是通用过滤策略再执行一遍,再次确认 Pod 是否能在该节点运行。
+这一阶段中,调度器并不会直接与 Kubelet 通信,而是将 Pod 对象的 nodeName 字段的值,修改为上述选中 Node 的名字即可。Kubelet 会持续监控 Etcd 中 Pod 信息的变化,然后执行一个称为“Admin”的本地操作,确认资源是否可用、端口是否冲突,实际上就是通用过滤策略再执行一遍,二次确认 Pod 是否能在该节点运行。
不过,从调度器更新 Etcd 中的 nodeName,到 Kueblet 检测到变化,再到二次确认是否可调度。这一系列的过程,会持续一段不等的时间。如果等到一切工作都完成,才宣告调度结束,那势必影响整体调度的效率。
-调度器采用了乐观绑定(Optimistic Binding)的策略来解决上述问题。首先,调度器同步更新 Scheduler Cache 里的 Pod 的 nodeName 的信息,并发起异步请求 Etcd 更新 Pod 的 nodeName 信息,该步骤在调度生命周期中称 Bind 步骤。如果调度成功了,那 Scheduler Cache 和 Etcd 中的信息势必一致。如果调度失败了(也就是异步更新失败),也没有太大关系,Informer 会持续监控 Pod 的变化,将调度成功却没有创建成功的 Pod 清空 nodeName 字段,并重新同步至调度队列。
+调度器采用了“乐观绑定”(Optimistic Binding)策略来解决上述问题。首先,调度器同步更新 Scheduler Cache 里的 Pod 的 nodeName 的信息,并发起异步请求 Etcd 更新 Pod 的 nodeName 信息,该步骤在调度生命周期中称 Bind 步骤。如果调度成功了,Scheduler Cache 和 Etcd 中的信息势必一致。如果调度失败了(也就是异步更新失败),也没有太大关系,Informer 会持续监控 Pod 的变化,将调度成功却没有创建成功的 Pod 清空 nodeName 字段,并重新同步至调度队列。
至此,整个 Pod 调度生命周期宣告结束。
diff --git a/network/DPDK.md b/network/DPDK.md
index d2f99eb7..04185559 100644
--- a/network/DPDK.md
+++ b/network/DPDK.md
@@ -14,7 +14,7 @@
图 3-6 DPDK 与传统内核网络对比
:::
-图 3-7 展示了 DPVS(基于 DPDK 实现的四层负载均衡器)与 LVS(Linux 内核内置的四层负载均衡器)的性能对比。根据每秒转发数据包数量(Packet Per Second,PPS)指标来看,DPVS 的性能表现比 LVS 高出 300%。
+爱奇艺开源的 DPVS 是 DPDK 技术在负载均衡领域的成功应用。图 3-7 展示了 DPVS 与标准 LVS 的性能对比,从每秒转发数据包数量(Packet Per Second,PPS)指标来看,DPVS 的性能表现比 LVS 高出 300%。
:::center
![](../assets/dpvs-performance.png)
@@ -23,4 +23,4 @@
对于海量用户规模的互联网应用来说,动辄需要部署数千、甚至数万台服务器,如果能将单机性能提升十倍甚至百倍,无论是从硬件投入还是运营成本上来看,都能带来非常可观的成本削减。这样的技术变革带来的潜在效益,无疑非常诱人。
-DPDK 属于硬件厂商主导的“内核旁路”技术。接下来,笔者再介绍由社区开发者主导的另一类“内核旁路”技术。
\ No newline at end of file
+DPDK 是由硬件厂商主导的“内核旁路”技术。在下一节,笔者将介绍由社区开发者主导的另一类“内核旁路”技术。
\ No newline at end of file
diff --git a/network/latency.md b/network/latency.md
index b65c3714..6f3f4db0 100644
--- a/network/latency.md
+++ b/network/latency.md
@@ -12,7 +12,7 @@
CPU 从一级缓存中读取数据| 1 ns
CPU 分支预测错误(Branch mispredict)| 3 ns
CPU 从二级缓存中读取数据 | 4 ns
-线性间互斥锁/解锁 | 17 ns
+线程间,共享资源加锁/解锁 | 17 ns
在 1Gbps 的网络上发送 2KB 数据 | 44 ns
访问一次主存 | 100 ns
使用 Zippy 压缩 1KB 数据 | 2,000 ns ≈ 2 μs
diff --git a/network/linux-vritual-net.md b/network/linux-vritual-net.md
index 55da956e..e97a3b76 100644
--- a/network/linux-vritual-net.md
+++ b/network/linux-vritual-net.md
@@ -2,4 +2,4 @@
Linux 网络虚拟化的核心技术主要是网络命名空间和各种虚拟网络设备,如稍后介绍的 Veth、Linux Bridge、TUN/TAP 等。这些虚拟设备由代码实现,完全模拟物理设备的功能。
-近年来流行的**容器技术基于这些虚拟网络设备,模拟物理设备之间协作方式,将各个独立的网络命名空间连接起来,构建出不受物理环境限制的网络架构**,实现容器之间、容器与宿主机之间,甚至跨数据中心的动态网络拓扑。
+近年来流行颇广的容器技术,正是基于这些虚拟网络设备,模拟物理设备之间协作方式,将各个独立的网络命名空间连接起来,构建出不受物理环境限制的网络架构,实现容器之间、容器与宿主机之间,甚至跨数据中心的动态网络拓扑。