k8s：服务网格Service Mesh（服务网格）istio和envoy

微服务-》k8s-》服务网格

这是技术进化方向

Service Mesh 为什么重要？

因为它把微服务最困难的部分 ------ 服务治理 ------ 从业务代码中移除，放到基础设施层。

以前要写复杂 SDK

→ 现在全自动由 Envoy 完成
以前安全靠自己管理证书

→ 现在 Istio 自动给每个服务下发证书
以前灰度发布要写代码、改配置

→ 现在改一个 YAML 即可

Service Mesh（服务网格）就是一个用来管理微服务之间通信的基础设施层

它不需要改业务代码，通过 Sidecar 代理（如 Envoy）自动提供：

流量管理（路由、灰度、负载均衡）
安全（mTLS、认证、鉴权）
可观测性（指标、日志、链路追踪）
故障恢复（重试、熔断、超时）

不用 SDK、无需修改业务逻辑，应用只写业务代码。

服务网格就是替代了原先java引入的一些依赖

👉 服务网格不是取代微服务，而是取代微服务中的"服务治理部分"。

👉 让你不再把大量非业务代码写在微服务里。

所有请求都经过 Envoy，不直接经过业务代码。

Envoy 做：

流量转发、路由、负载均衡

超时、重试、限流、熔断

mTLS 加密、证书管理

指标、日志、链路追踪

控制面（Istio）做：

把策略下发给 Envoy

管理证书

管理流量规则

监控 sidecar 状态

Service Mesh = 控制面 + 数据面

✔ 数据面（Data Plane）→ Envoy

负责真正处理流量。

✔ 控制面（Control Plane）→ Istio

负责策略、配置、证书、安全、服务发现。

完整结构：

复制代码

      +------------------+
      |   Istio (控制面)   |
      +------------------+
        ↓      ↓      ↓
   Envoy   Envoy   Envoy
   Sidecar Sidecar Sidecar
        ↓      ↓      ↓
     App     App     App

kube-proxy = 基本的流量转发器

Envoy = 智能流量控制器

两者的关系是什么？

默认情况下，两者都存在：

请求 → kube-proxy (iptables) → Pod 内部 → Envoy sidecar → 应用

但在 Istio 中：

Envoy 可以取代 kube-proxy 的部分工作

具体取代的是：

Service 的负载均衡（通过 EDS/Cluster 代替）

Service 之间的流量路由（Envoy instead of kube-proxy）

所以：

在 Istio 中，kube-proxy 的作用弱化，但仍然需要存在。

（也可以彻底禁用 kube-proxy，但那属于高级玩法）

理解重点：kube-proxy 是底层网络，Envoy 是高层治理

你可以这样理解：

kube-proxy = "Linux iptables 提供的基础网络连通能力"

Envoy = "Nginx + API 网关 + 安全代理 + 流量治理 + 可观测性"

Nginx Ingress Controller = 传统入口控制器（不属于 Service Mesh）