Merge pull request spidernet-io#1921 from windsonsea/solution

[docs] update solution.md and add it to nav

docs/concepts/solution-zh_CN.md

@@ -1,99 +1,99 @@
-# underlay 网络 和 overlay 网络方案
+# Underlay 网络和 Overlay 网络方案
 
-云原生网络中出现了两种技术类别，" overlay 网络方案" 和 " underlay网络方案"，
+云原生网络中出现了两种技术类别："Overlay 网络方案" 和 "Underlay 网络方案"。
 云原生网络对于它们没有严格的定义，我们可以从很多 CNI 项目的实现原理中，简单抽象出这两种技术流派的特点，它们可以满足不同场景下的需求。
 
-Spiderpool 是为 underlay 网络特点而设计，以下对两种方案进行比较，能够更好说明 Spiderpool 的特点和使用场景。
+Spiderpool 是为 Underlay 网络特点而设计，以下对两种方案进行比较，能够更好说明 Spiderpool 的特点和使用场景。
 
-## overlay 网络方案 IPAM
+## Overlay 网络方案 IPAM
 
-本方案实现了 Pod 网络同宿主机网络的解耦，例如 [Calico](https://github.com/projectcalico/calico) , [Cilium](https://github.com/cilium/cilium) 等 CNI 插件，
-这些插件多数使用了 vxlan 等隧道技术，搭建起一个 overlay 网络平面，再借用 NAT 技术实现南北向的通信。
+本方案实现了 Pod 网络同宿主机网络的解耦，例如 [Calico](https://github.com/projectcalico/calico)、[Cilium](https://github.com/cilium/cilium) 等 CNI 插件，
+这些插件多数使用了 vxlan 等隧道技术，搭建起一个 Overlay 网络平面，再借用 NAT 技术实现南北向的通信。
 
 这类技术流派的 IPAM 分配特点是：
 
 1. Pod 子网中的 IP 地址按照节点进行了分割
 
-   以一个更小子网掩码长度为单位，把 Pod subnet 分割出更小的 IP block 集合，依据 IP 使用的用量情况，每个 node 都会获取到一个或者多个 IP block。
+    以一个更小子网掩码长度为单位，把 Pod subnet 分割出更小的 IP block 集合，依据 IP 使用的用量情况，每个 node 都会获取到一个或者多个 IP block。
 
-   这意味着两个特点：第一，每个 node 上的 IPAM 插件只需要在本地的 IP block 中分配和释放 IP 地址时，与其它 node 上的 IPAM 无 IP 分配冲突，IPAM 分配效率更高。
-   第二，某个具体的 IP 地址跟随 IP block 集合，会相对固定的一直在某个 node 上被分配，没法随同 Pod 一起被调度漂移。
+    这意味着两个特点：第一，每个 node 上的 IPAM 插件只需要在本地的 IP block 中分配和释放 IP 地址时，与其它 node 上的 IPAM 无 IP 分配冲突，IPAM 分配效率更高。
+    第二，某个具体的 IP 地址跟随 IP block 集合，会相对固定的一直在某个 node 上被分配，没法随同 Pod 一起被调度漂移。
 
 2. IP 地址资源充沛
 
-   只要 Pod 子网不与相关网络重叠，再能够合理利用 NAT 技术，kubernetes 单个集群可以拥有充沛的 IP 地址资源。
-   因此，应用不会因为 IP 不够而启动失败，IPAM 组件面临的异常 IP 回收压力较小。
+    只要 Pod 子网不与相关网络重叠，再能够合理利用 NAT 技术，Kubernetes 单个集群可以拥有充沛的 IP 地址资源。
+    因此，应用不会因为 IP 不够而启动失败，IPAM 组件面临的异常 IP 回收压力较小。
 
-3. 没有应用" IP 地址固定"需求
+3. 没有应用 "IP 地址固定"需求
 
-   对于应用 IP 地址固定需求，有无状态应用和有状态应用的区别：对于 deployment 这类无状态应用，因为 Pod name 会随着 Pod 重启而变化，
-   应用本身的业务逻辑也是无状态的，因此对于" IP 地址固定" 的需求，只能让所有 Pod 副本固定在一个 IP 地址的集合内；对于 statefulset 这
-   类有状态应用，因为 Pod name 等信息都是固定的，应用本身的业务逻辑也是有状态的，因此对于" IP 地址固定"需求，要实现单个 Pod 和具体 IP 地址的强绑定。
+    对于应用 IP 地址固定需求，有无状态应用和有状态应用的区别：对于 Deployment 这类无状态应用，因为 Pod 名称会随着 Pod 重启而变化，
+    应用本身的业务逻辑也是无状态的，因此对于 "IP 地址固定" 的需求，只能让所有 Pod 副本固定在一个 IP 地址的集合内；对于 StatefulSet
+    这类有状态应用，因为 Pod name 等信息都是固定的，应用本身的业务逻辑也是有状态的，因此对于 "IP 地址固定"需求，要实现单个 Pod 和具体 IP 地址的强绑定。
 
-   在" overlay 网络方案"方案下，多是借助了 NAT 技术向集群外部暴露服务的入口和源地址，借助 DNS、clusterIP 等技术来实现集群东西向通信。
-   其次，IPAM 的 IP block 方式把 IP 相对固定到某个节点上，而不能保证应用副本的跟随调度。
-   因此，应用的" IP 地址固定"能力无用武之地，当前社区的主流 CNI 多数不支持" IP 地址固定"，或者支持方法较为简陋。
+    在 "Overlay 网络方案"方案下，多是借助了 NAT 技术向集群外部暴露服务的入口和源地址，借助 DNS、clusterIP 等技术来实现集群东西向通信。
+    其次，IPAM 的 IP block 方式把 IP 相对固定到某个节点上，而不能保证应用副本的跟随调度。
+    因此，应用的 "IP 地址固定"能力无用武之地，当前社区的主流 CNI 多数不支持 "IP 地址固定"，或者支持方法较为简陋。
 
 这个方案的优点是，无论集群部署在什么样的底层网络环境上，CNI 插件的兼容性都非常好，且都能够为 Pod 提供子网独立、IP 地址资源充沛的网络。
 
-## underlay 网络方案 IPAM
+## Underlay 网络方案 IPAM
 
-本方案实现了 Pod 共享宿主机的底层网络，即 Pod 直接获取宿主机网络中的 IP 地址，这样，应用可直接使用自己的 IP 地址进行东西向和南北向通信。
+本方案实现了 Pod 共享宿主机的底层网络，即 Pod 直接获取宿主机网络中的 IP 地址。这样，应用可直接使用自己的 IP 地址进行东西向和南北向通信。
 
-underlay 网络方案的实施，有两种典型的场景，一种是集群部署实施在"传统网络"上，一种是集群部署在 IAAS 环境上，例如公有云。以下总结了"传统网络场景"的 IPAM 特点：
+Underlay 网络方案的实施，有两种典型的场景：一种是集群部署实施在"传统网络"上；一种是集群部署在 IAAS 环境上，例如公有云。以下总结了"传统网络场景"的 IPAM 特点：
 
 1. 单个 IP 地址应该能够在任一节点上被分配
 
-   这个需求有多方面的原因：随着数据中心的网络设备增加、多集群技术的发展，IPv4 地址资源稀缺，要求 IPAM 提高 IP 资源的使用效率；
-   对于有" IP 地址固定"需求的应用，其 Pod 副本可能会调度到集群的任意一个节点上，并且，在故障场景下还会发生节点间的漂移，要求 IP 地址一起漂移。
+    这个需求有多方面的原因：随着数据中心的网络设备增加、多集群技术的发展，IPv4 地址资源稀缺，要求 IPAM 提高 IP 资源的使用效率；
+    对于有 "IP 地址固定"需求的应用，其 Pod 副本可能会调度到集群的任意一个节点上，并且，在故障场景下还会发生节点间的漂移，要求 IP 地址一起漂移。
 
-   因此，在集群中的任意一个节点上，一个 IP 地址应该具备能够被分配给 Pod 使用的可能。
+    因此，在集群中的任意一个节点上，一个 IP 地址应该具备能够被分配给 Pod 使用的可能。
 
 2. 同一应用的不同副本，能实现跨子网获取 IP 地址
 
-   例如，一个集群中，宿主机1的区域只能使用子网 172.20.1.0/24，而宿主机2的区域只能使用子网 172.20.2.0/24， 在此背景下，
-   当一个应用跨子网部署副本时，要求 IPAM 能够在不同的节点上，为同一个应用下的不同 Pod 分配出子网匹配的 IP 地址。
+    例如，一个集群中，宿主机1的区域只能使用子网 172.20.1.0/24，而宿主机2的区域只能使用子网 172.20.2.0/24，在此背景下，
+    当一个应用跨子网部署副本时，要求 IPAM 能够在不同的节点上，为同一个应用下的不同 Pod 分配出子网匹配的 IP 地址。
 
 3. 应用 IP 地址固定
 
-   很多传统应用在云化改造前，是部署在裸金属环境上的，服务之间的网络未引入 NAT 地址转换，微服务架构中需要感知对方的源 IP 或目的 IP ，
-   并且，网络管理员也习惯了使用防火墙等手段来精细管控网络安全。
+    很多传统应用在云化改造前，是部署在裸金属环境上的，服务之间的网络未引入 NAT 地址转换，微服务架构中需要感知对方的源 IP 或目的 IP，
+    并且，网络管理员也习惯了使用防火墙等手段来精细管控网络安全。
 
-   因此，应用上云后，无状态应用希望能够实现 IP 范围的固定，有状态应用希望能够实现 IP 地址的唯一对应，这样，能够减少对微服务架构的改造工作。
+    因此，应用上云后，无状态应用希望能够实现 IP 范围的固定，有状态应用希望能够实现 IP 地址的唯一对应，这样，能够减少对微服务架构的改造工作。
 
 4. 一个 Pod 的多网卡获取不同子网的 IP 地址
 
-   既然是对接 underlay 网络，Pod 就会有多网卡需求，以使其通达不同的 underlay 子网，这要求 IPAM 能够给应用的不同网卡分配不同子网下的 IP 地址。
+    既然是对接 Underlay 网络，Pod 就会有多网卡需求，以使其通达不同的 Underlay 子网，这要求 IPAM 能够给应用的不同网卡分配不同子网下的 IP 地址。
 
 5. IP 地址冲突
 
-   在 underlay 网络中，更加容易出现 IP 冲突，例如，Pod 与集群外部的主机 IP 发生了冲突，与其它对接了相同子网的集群冲突，
-   而 IPAM 组件很难感知外部这些冲突的 IP 地址，多需要借助 CNI 插件进行实时的 IP 冲突检测。
+    在 Underlay 网络中，更加容易出现 IP 冲突，例如，Pod 与集群外部的主机 IP 发生了冲突，与其它对接了相同子网的集群冲突，
+    而 IPAM 组件很难感知外部这些冲突的 IP 地址，多需要借助 CNI 插件进行实时的 IP 冲突检测。
 
 6. 已用 IP 地址的释放回收
 
-   因为 underlay 网络 IP 地址资源的稀缺性，且应用有 IP 地址固定需求，所以，"应当"被释放的 IP 地址若未被 IPAM 组件回收，新启动的 Pod 可能会因为缺少 IP 地址而失败。
-   这就要求 IPAM 组件拥有更加精准、高效、及时的 IP 回收机制。
+    因为 Underlay 网络 IP 地址资源的稀缺性，且应用有 IP 地址固定需求，所以，"应当"被释放的 IP 地址若未被 IPAM 组件回收，新启动的 Pod 可能会因为缺少 IP 地址而失败。
+    这就要求 IPAM 组件拥有更加精准、高效、及时的 IP 回收机制。
 
 这个方案的优势有：无需网络 NAT 映射的引入，对应用的云化网络改造，提出了最大的便利；底层网络的火墙等设备，可对 Pod 通信实现相对较为精细的管控；无需隧道技术，
 网络通信的吞吐量和延时性能也相对的提高了。
 
-## overlay CNI 和 underlay CNI 的性能
+## Overlay CNI 和 Underlay CNI 的性能
 
-overlay CNI 需要借助隧道封装和宿主机转发实现跨主机的 POD 通信，而 underlay CNI 可实现直接对接宿主机网络，因此在网络延时和吞吐量表现上有差异。
+Overlay CNI 需要借助隧道封装和宿主机转发实现跨主机的 Pod 通信，而 Underlay CNI 可实现直接对接宿主机网络，因此在网络延时和吞吐量表现上有差异。
 
 在一个具备 2 个裸金属节点的集群上，安装一个 25G mellanox CX5 网卡，分别测试如下：
 
 * 2 个裸金属节点间的网卡的性能
 
-* 基于 macvlan 的跨节点 POD 网络性能
+* 基于 macvlan 的跨节点 Pod 网络性能
 
-* 基于 SR-IOV 的跨节点 POD 网络性能
+* 基于 SR-IOV 的跨节点 Pod 网络性能
 
-* 基于 calico(v3.23) vxlan 的跨节点 POD 的网络性能
+* 基于 calico(v3.23) vxlan 的跨节点 Pod 的网络性能
 
-* 基于 cilium(v1.13) vxlan 的跨节点 POD 的网络性能
+* 基于 cilium(v1.13) vxlan 的跨节点 Pod 的网络性能
 
 ![performance](../images/network_performance.png)
 
-最终的测试报告如上所示，诸如 macvlan 和 SRIOV 的 underlay CNI 性能较好。
+最终的测试报告如上所示，诸如 macvlan 和 SRIOV 的 Underlay CNI 性能较好。