更新 Servicemesh

isno · Mar 1, 2024 · a970fe5 · a970fe5
1 parent 87110ff
commit a970fe5
Show file tree

Hide file tree

Showing 2 changed files with 10 additions and 10 deletions.
diff --git a/ServiceMesh/ServiceMesh-and-Kubernetes.md b/ServiceMesh/ServiceMesh-and-Kubernetes.md
@@ -1,25 +1,25 @@
 # 8.4 服务网格与 Kubernetes
 
-现在，承载应用 Workload 的形式已经从”物理机“过渡到”容器“。容器意味着创建（包括初始化）和销毁高度自动化，且具备极强弹性。此时，基础设施的功能（服务发现、负载均衡、熔断限流、路由等）与业务代码的集成需要在低成本前提下保证相同的生命周期。物理机时代，基础设施功能添加到业务代码的方式只能选择 SDK，而容器时代，基础设施的功能添加到业务代码的最佳方式变成了 Sidecar。
+现在，承载应用 Workload 的形式已经从”物理机“过渡到”容器“。容器意味着创建（包括初始化）和销毁高度自动化，且具备极强弹性。此时，基础设施的功能（服务发现、负载均衡、熔断限流、路由等）与业务代码的集成需要在低成本前提下保证相同的生命周期。
+
+
+物理机时代，基础设施功能添加到业务代码的方式只能选择 SDK，而容器时代，基础设施的功能添加到业务代码的最佳方式变成了 Sidecar。Kubernetes 通过管理基础设施（Pod）为微服务提供了可扩展、高弹性的部署粗粒度服务。而 ServiceMesh 通过 Pod 内的 Sidecar Proxy 实现透明代理，通过更接近微服务应用层的抽象，实现服务间的流量、安全性和可观察性细粒度管理。
+
 
 <div  align="center">
 	<img src="../assets/istio-k8s.png" width = "350"  align=center />
 	<p></p>
 </div>
 
 
-Kubernetes 通过管理基础设施（Pod）为微服务提供了可扩展、高弹性的部署粗粒度服务。而 ServiceMesh 通过 Pod 内的 Sidecar Proxy 实现透明代理，通过更接近微服务应用层的抽象，实现服务间的流量、安全性和可观察性细粒度管理。
+如下图所示，Kubernetes 与 Servicemesh 天生契合，Istio 最大化地利用了 Kubernetes 这个基础设施，与之叠加在一起形成一套从底层的负载部署运行到上层服务运行和治理的基础设施。
 
 
-
-Kubernetes 与 Servicemesh 天生契合，Istio 最大化地利用了Kubernetes这个基础设施，与之叠加在一起形成一套从底层的负载部署运行到上层服务运行和治理的基础设施。
-
 <div  align="center">
 	<img src="../assets/ServiceMesh-and-Kubernetes.png" width = "450"  align=center />
 	<p>图片来源于《云原生服务网格Istio》</p>
 </div>
 
-
 由下图可见，Istio 补充了 Kubernetes 生态圈的重要一环，是 Google 的微服务版图里一个里程碑式的扩张
 
 <div  align="center">

diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md
@@ -24,15 +24,15 @@ Istio 的架构如下图所示，对于一个仅提供服务与服务之间连
 	<p>Istio 架构</p>
 </div>
 
-## Linkerd 2.0 
+## Linkerd 2.0 出击
 
-Istio 被争相追捧的同时，作为 Service Mesh 概念的创造者 Buoyant 公司自然不甘心出局，公司生死存亡之际，痛定思痛之后，瞄准 Istio 的缺陷（过于复杂）借鉴 Istio 的设计理念（控制平面与数据平面）主打轻量化，重新设计它们的服务网格产品：使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit。目标是世界上最轻、最简单、最安全的 Kubernetes 专用的服务网格。
+Istio 被争相追捧的同时，作为 Service Mesh 概念的创造者 Buoyant 公司自然不甘心出局，公司生死存亡之际，痛定思痛之后，瞄准 Istio 的缺陷（过于复杂）借鉴 Istio 的设计理念（新增控制平面），开始重新设计它们的服务网格产品：使用 Rust 构建数据平面 linkerd2-proxy ，使用 Go 开发了控制平面 Conduit。主打轻量化，目标是世界上最轻、最简单、最安全的 Kubernetes 专用的服务网格。
 
-Buoyant 第二代服务网格产品最初以 Conduit 命名，在 Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为Linkerd 2[^1]，
+Buoyant 第二代服务网格产品最初以 Conduit 命名，在 Conduit 加入 CNCF 后不久，宣布与原有的 Linkerd 项目合并，被重新命名为Linkerd 2[^1]。如下图所示，Linkerd2 也增加控制平面，但是更加简单，控制层面只有（destination 类似Pilot，identity 类似 Citadel）和 proxy injector（代理注入器）。linkerd-init 设置 iptables 规则，拦截进出每个 pod 的 TCP 连接，Linkerd-proxy 实现所有的流量管控（负载均衡、熔断..）。
 
 <div  align="center">
 	<img src="../assets/linkerd-control-plane.png" width = "500"  align=center />
-	<p>Linkerd 架构</p>
+	<p>Linkerd2 架构</p>
 </div>
 
 ## 其他参与者