update

container/auto-scaling.md

@@ -3,9 +3,9 @@
 为了平衡服务负载的巨大波动及资源预估与实际使用之间的差距，Kubernetes 提供了三种资源自动伸缩（autoscaling）解决方案：HPA、VPA 以及节点自动伸缩（Cluster Autoscaler）组件。
 ## 7.8.1 Pod 水平自动伸缩
 
-HPA，全称是 Horizontal Pod Autoscaler（Pod 水平自动扩缩），是 Kubernetes 中对工作负载副本数进行自动水平扩缩的机制，也是 Kubernetes 中最广泛使用的自动扩缩功能。
+HPA，全称是 Horizontal Pod Autoscaler（Pod 水平自动扩缩），是 Kubernetes 中对工作负载（如 Deployment）Pod 副本数进行自动水平扩缩的机制，也是 Kubernetes 中最广泛使用的自动扩缩功能。
 
-HPA 的实现思路很简单，即通过监控业务的繁忙程度来做出相应的调整。当业务负载较高时，增加工作负载（如 Deployment）的 Pod 副本数量；当业务负载减少时，Pod 副本数也会相应缩减。所以，实现水平扩缩容的关键问题之一是：“如何准确识别业务的忙闲程度？”
+HPA 的实现思路很简单，即通过监控业务的繁忙程度来做出相应的调整。当业务负载较高时，增加工作负载的 Pod 副本数量；当业务负载减少时，Pod 副本数也会相应缩减。所以，实现扩缩容的关键问题之一是：“如何准确识别业务的忙闲程度？”
 
 Kubernetes 提供了一种标准的 Metrics 接口（Metrics API），能够提供关于节点和 Pod 资源使用情况的信息。如下所示，在 minikube 节点上一个 Metrics 接口响应示例。
 
@@ -43,9 +43,9 @@ kubectl autoscale deployment foo --cpu-percent=70 --min=1 --max=10
 
 ## 7.8.2 Pod 垂直自动伸缩
 
-VPA，全称是 Vertical Pod Autoscaler（Pod 垂直自动伸缩）。VPA 的实现思路与 HPA 基本一致，也是通过监控 Metrics 接口并根据指标评估后做出相应的调整。不同于 HPA 通过调整工作负载的副本数量来实现扩缩，VPA 调整的是工作负载的资源配额（如 Pod 的 CPU 和内存的 request 和 limit）。
+VPA，全称是 Vertical Pod Autoscaler（Pod 垂直自动伸缩）。VPA 的实现思路与 HPA 基本一致，也是通过监控 Metrics 接口并根据指标评估后做出相应的调整。不同的是，VPA 调整的是工作负载的资源配额（如 Pod 的 CPU 和内存的 request 和 limit）。
 
-值得注意的是，VPA 是 Kubernetes 中的一个可选附加组件，需单独安装和配置后，才能为特定的 Deployment 创建 VPA 资源并定义 Pod 的资源调整策略。以下是一个 VPA 配置示例，供读者参考：
+值得注意的是，VPA 是 Kubernetes 中的一个可选附加组件，需单独安装和配置后，才能为特定工作负载（如 Deployment）创建 VPA 资源并定义资源调整策略。以下是一个 VPA 配置示例，供读者参考：
 
 ```yaml
 apiVersion: autoscaling.k8s.io/v1
@@ -85,22 +85,22 @@ Recommendation:
 ...
 ```
 
-由此可见，VPA 适用于负载动态变化较大且资源使用需求不确定的应用场景，尤其是在无法精确预估应用资源需求的情况下。
+可见，VPA 适用于负载动态变化较大且资源使用需求不确定的应用场景，尤其是在无法精确预估应用资源需求的情况下。
 
 ## 7.8.3 基于事件驱动的伸缩
 
-虽然 HPA 基于 Metrics 接口实现了弹性伸缩，但其指标范围有限且粒度较粗。为支持基于外部事件的更细粒度自动扩缩，微软与红帽联合开发了基于事件驱动的 Kubernetes 自动扩缩器 —— KEDA（Kubernetes Event-driven Autoscaling）。
+虽然 HPA 基于 Metrics 接口实现了弹性伸缩，但 Metrics 接口指标范围有限且粒度较粗。为了实现能基于外部事件更细粒度的扩缩容，微软与红帽联合开发了基于事件驱动的 Kubernetes 自动扩缩器 —— KEDA（Kubernetes Event-driven Autoscaling）。
 
 KEDA 的出现并非为了取代 HPA，而是与其形成互补关系。
 
-KEDA 的工作原理如图 7-35 所示：用户通过配置 ScaledObject（缩放对象）来定义 Scaler（KEDA 的内部组件）的工作方式，Scaler 持续从外部系统获取状态数据，并将这些数据与配置的扩缩条件进行比较。当条件满足时，Scaler 触发扩缩操作，调用 Kubernetes 的 HPA 调整对应工作负载的 Pod 副本数。
+KEDA 的工作原理如图 7-35 所示：用户通过配置 ScaledObject（缩放对象）来定义 Scaler（KEDA 的内部组件）的工作方式，Scaler 持续从外部系统获取状态数据，并将这些数据与配置的扩缩条件进行比较。当条件满足时，Scaler 触发扩缩操作，调用 Kubernetes 的 HPA 组件调整工作负载 Pod 副本数。
 
 :::center
   ![](../assets/keda-arch.png)<br/>
   图 7-35 KADA 架构图
 :::
 
-KEDA 内置了几十种常见的 Scaler，用于处理特定的事件源或指标源。以下列出一些常见的 Scaler 供参考：
+KEDA 内置了几十种常见的 Scaler，用于处理特定的事件源或指标源。笔者列举一些常见的 Scaler 供参考：
 - 消息队列 Scaler：如 Kafka、RabbitMQ、Azure Queue、AWS SQS 等消息队列的消息数量。
 - 数据库 Scaler：如 SQL 数据库的连接数、查询延迟等。
 - HTTP 请求 Scaler：基于 Web API 的请求数量或响应时间。

network/DPDK.md

@@ -22,4 +22,4 @@
  图 3-7 DPVS 与 LVS 的 PPS 性能指标对比 [图片来源](https://github.com/iqiyi/dpvs)
 :::
 
-
+DPDK 实际上由硬件厂商主导的“内核旁路”技术。接下来，笔者再介绍由社区开发者主导的另一类“内核旁路”技术。

network/vxlan.md

@@ -2,14 +2,20 @@
 
 容器分布在不同的物理主机之上，每一台物理主机都有物理网络互相联通，然而基于物理网络的拓扑结构是相对固定的，很难跟得上云原生时代分布式系统频繁变动的频率。例如容器的动态扩缩容、集群跨数据中心迁移等等，都要求网络拓扑随时做出调整。正因为如此，软件定义网络（Software Defined Networking，SDN）的需求变得前所未有的迫切。
 
-SDN 的核心思想是在现有的物理网络之上再新增一层虚拟网络，将控制平面（操作系统和各类软件）和数据平面（交换机和各类通信协议等）解耦，使网络设备的控制平面可直接代码编程控制，将网络服务从底层硬件设备中抽象出来。SDN 里位于下层称 Underlay 网络，它是由多个类型设备互联而成的物理网络，负责网络之间的数据包传输，位于上层的网络称 Overlay 网络，它是采用多种网络虚拟化技术在 Underlay 网络之上创建虚拟网络。
+SDN 的核心思想是在现有的物理网络之上再新增一层虚拟网络，将控制平面（操作系统和各类软件）和数据平面（交换机和各类通信协议等）解耦，使网络设备的控制平面可直接代码编程控制，将网络服务从底层硬件设备中抽象出来。
+
+SDN 网络模型如图 3-16 所示：
+- 位于下层的网络称 Underlay 网络，它是由多个类型设备互联而成的物理网络，负责网络之间的数据包传输；
+- 位于上层的网络称 Overlay 网络，它是采用多种网络虚拟化技术在 Underlay 网络之上创建虚拟网络。
 
 :::center
   ![](../assets/overlay-network.png)<br/>
   图 3-16 SDN 网络中 Overlay 与 Underlay 网络模型
 :::
 
-SDN 的发展要早于云原生十余年，发展过程中出现多种 Overlay 网络的具体实现，如 Geneve（Generic Network Virtualization Encapsulation）、VXLAN（Virtual Extensible LAN）、STT（Stateless Transport Tunneling）等等。这些技术本质上是一种隧道技术，也就是将数据包封装在另一个数据包中，在现有物理网络之上创建一个虚拟网络。虚拟网络中的容器不需要关心底层物理网络的路由规则等细节，物理网络也不需要针对容器 IP 进行专门路由配置。因此以 VXLAN 为代表的 Overlay 网络作为一种无需调底层网络实现的容器组网技术，快速在容器领域铺开了。
+SDN 的发展要早于云原生十余年，发展过程中出现多种 Overlay 网络的具体实现，如 Geneve（Generic Network Virtualization Encapsulation）、VXLAN（Virtual Extensible LAN）、STT（Stateless Transport Tunneling）等等。这些技术本质上是一种隧道技术，也就是：“将数据包封装在另一个数据包中，在现有物理网络之上创建一个虚拟网络”。
+
+虚拟网络中的容器不需要关心底层物理网络的路由规则等细节，物理网络也不需要针对容器 IP 进行专门路由等配置。因此，以 VXLAN 为代表的 Overlay 网络作为一种无需调底层网络实现的容器组网技术，快速在容器领域铺开了。
 
 学习 VXLAN 之前，我们有必要充分了解一些基础的物理通信原理。接下来，笔者将先介绍 VXLAN 的前身 VLAN（Virtual Local Area Network，虚拟局域网）。