修改服务网格未来

ServiceMesh/The-future-of-ServiceMesh.md

@@ -1,49 +1,14 @@
 # 8.5 服务网格的未来
 
-基于 Istio 的 ServiceMesh 架构在互联网公司进行大规模线上部署的时候逐渐遇到以下问题：
+使用服务网格的架构，在大规模线上部署的时候逐渐遇到了以下两个主要问题：
 
-- Envoy 上手难度大、维护成本高。
-- Sidecar 带来的额外资源开销以及 Proxy 模式带来的延迟增加。
-- xDs 全量下发带来的内存消耗过大以及配置文件过多，出现问题难以排查。
+- **资源消耗过大**：以 sidecar 方式运行，每一个 Pod 都要注入 sidecar，还得为 sidecar 预留足够的 CPU 和内存资源。整个集群全都是 Sidecar，非业务逻辑消耗了大量的资源。
+- **Proxy 模式带来的请求延迟**：针对请求的拦截，目前常规的做法是使用 iptbales，当原来本来是A->B，现在变成A->iptables+sidecar->iptables+sidecar->B。代理增加了业务请求的链路长度，那必然会带来性能损耗（代理之后每次 400-500us）。
 
+针对以上问题，社区出现以 Ambient Mesh（无代理） 和 Cilium Service Mesh（跨内核，绕过 iptables 实现）两类代表的解决方案。
 
-Envoy 作为 Sidecar 其提供的核心功能可以总结为以下三点：
+## Ambient Mesh 
 
-- 对业务透明的请求拦截。
-- 对拦截请求基于一定的规则进行校验、认证、统计、流量调度以及路由等。
-- 将请求转发出去。
-
-ServiceMesh 中所有的流量出入都要经过 Sidecar。Sidecar 的加入增加了业务请求的链路长度，那必然会带来性能损耗。但细观察以上三点，其中第1、3点都是与业务无关的，属于通用型功能，而第2点的性能是与业务复杂度强相关的，比如请求校验规则的多与少、遥测数据的采样率等等。
-
-因为最有可能提升 Sidecar 性能的点就是高效处理对请求的拦截以降低 Sidcar 之间通信的延迟。
-
-## 跨内核处理
-
-针对请求的拦截，目前常规的做法是使用 iptbales，在部署 Sidecar 时配置好 iptbales 的拦截规则，当请求来临后 iptables 会从规则表中从上之下按顺序一条条进行匹配。如果遇到匹配的规则，那就执行本规则并根据本规则的动作（accept、reject、log 等），决定下一步的执行情况。
-
-了解 iptbales 的基本流程之后，不难发现其中性能的瓶颈：
-
-- iptables 的规则匹配是线性的，匹配的时间复杂度是 O(N)，当规则较多时候，性能会严重下滑。
-- 每个请求的处理都要经过内核态到用户态再到内核态的过程。当网络中有大量数据包到达内核时，会产生频繁的硬件中断、上下文切换以及数据在内核态和用户态来回拷贝的性能损耗。
-
-针对以上的两点性能瓶颈，Linux 社区以及 Envoy 社区通过以下方式进行优化：
-
-Linux 社区发布了 bpfilter，这是一个使用 Linux BPF 提供的高性能网络过滤内核模块，计划用来替换 netfilter 作为 iptables 的内核底层实现，实现 Linux 网络包过滤框架从 netfilter 向 BPF 过渡的演进。
-
-其次，Envoy 社区也在推动官方重构其架构，实现用户自定义 network socket 实现。最终目的为了添加对 VPP（Vector Packt Processing）扩展支持。
-
-无论是使用 VPP 或者 Cilium 都可以实现数据包在纯用户态或者内核态的处理，避免来回的拷贝、上下文切换，且可以绕过 Linux 协议栈，提高报文转发效率。进而达到提升请求拦截效率的目的。
-
-## QUIC
-
-
-## 高效通信
-
-## xDS 全量下发的问题
-
-当前 Istio 下发 xDS 使用的是全量的下发策略，也就是网络里面所有的 Sidecar 内存里都会有整个网格内所有的服务发现数据。这种方式在规模化的场景中，往往会出现性能瓶颈，主要体现在 xDS 的全量下发和频繁低效变更。
-
-设计 xDS 按需下发的方案，即下发的 xDS 数据一定是 Sidecar 所需要的，避免非必要的冗余数据和无效变更。提升服务网格的整体性能，满足规模化落地场景的需要。
-
-这里的按需下发主要是通过微服务调用的依赖关系，通过手动或者程序自动收集的方式来收集。
+## Cilium Service Mesh
 
+说明了运行 Cilium Envoy filter（棕色）的单个节点范围的 Envoy 代理与运行 Istio Envoy filter（蓝色）的双边车 Envoy 模型的 HTTP 处理的典型延迟成本。黄色是没有代理且未执行 HTTP 处理的基线延迟

ServiceMesh/overview.md

@@ -69,9 +69,6 @@ Buoyant 第二代服务网格产品最初以 Conduit 命名，在 Conduit 加入
 
 总结 Linkerd 和 Istio 在性能和资源成本上的巨大差异主要归结于 Linkerd2-proxy，这个微代理为 Linkerd 的整个数据平面提供动力，所以这个基准在很大程度上反映了 Linkerd2-proxy 和 Envoy 的性能和资源消耗对比。Linkerd2-proxy 虽然性能卓越，但语言过于小众，开源社区的 contributor 数量稀少，未选择实现 xDS 那么它的未来的发展也取决于 Linkerd 发展如何
 
-iptables带来的性能损耗，原来本来是A->B，现在变成A->iptables+sidecar->iptables+sidecar->B，如果不用iptables而采用手动接入又会对业务方产生工作量。感觉只能等ebpf的普及可能会绕过iptables实现流量的高效代理。但是目前ebpf需要的内核还比较新，所以也需要一段时间的等待。
-
-
 [^1]: 参见 https://github.com/linkerd/linkerd2
 [^2]: 参见 https://github.com/kinvolk/service-mesh-benchmark
 [^3]: 参见 https://github.com/linkerd/linkerd2/wiki/Linkerd-Benchmark-Setup

container/k8s-deploy-cilium.md

@@ -1,4 +1,4 @@
-# 使用 clilium 配置网络
+# 使用 cilium 配置网络
 
 里面介绍到 Kubernetes Service 性能和扩展性问题 默认的 Kubernetes 的 Service 实现 kube-proxy，它是使用了 iptables 去配置 Service IP 和负载均衡：