From de6f1927696073f3ffbb61d6e2a7b1bdccc79e18 Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 1 Mar 2024 18:46:23 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E6=9C=8D=E5=8A=A1=E7=BD=91?= =?UTF-8?q?=E6=A0=BC=E6=9C=AA=E6=9D=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ServiceMesh/The-future-of-ServiceMesh.md | 49 ++++-------------------- ServiceMesh/overview.md | 3 -- container/k8s-deploy-cilium.md | 2 +- 3 files changed, 8 insertions(+), 46 deletions(-) diff --git a/ServiceMesh/The-future-of-ServiceMesh.md b/ServiceMesh/The-future-of-ServiceMesh.md index fcc11968..7a043088 100644 --- a/ServiceMesh/The-future-of-ServiceMesh.md +++ b/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 处理的基线延迟 \ No newline at end of file diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md index 4a19f103..4bc76033 100644 --- a/ServiceMesh/overview.md +++ b/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 diff --git a/container/k8s-deploy-cilium.md b/container/k8s-deploy-cilium.md index 4677b7a6..466f4498 100644 --- a/container/k8s-deploy-cilium.md +++ b/container/k8s-deploy-cilium.md @@ -1,4 +1,4 @@ -# 使用 clilium 配置网络 +# 使用 cilium 配置网络 里面介绍到 Kubernetes Service 性能和扩展性问题 默认的 Kubernetes 的 Service 实现 kube-proxy，它是使用了 iptables 去配置 Service IP 和负载均衡：