一句话总结
Service Mesh 把微服务间的通信、安全、可观测性从业务代码下沉到基础设施层，以 sidecar 代理接管所有进出流量；GitOps 用 Git 仓库作为系统期望状态唯一事实源，通过声明式配置 + 自动同步实现安全、可审计、可回滚的持续交付。
二者解决的是不同层面的问题：Mesh 管"服务怎么通信"，GitOps 管"集群要变成什么样"。下表对比传统 SDK 治理与 Sidecar 治理：
| 维度 | SDK/框架治理（如 Spring Cloud） | Service Mesh（Sidecar） |
|---|---|---|
| 治理逻辑位置 | 业务进程内 | 独立 sidecar 容器 |
| 语言绑定 | 强绑定（Java 生态为主） | 语言无关 |
| 升级成本 | 改代码 + 重新发布 | 升级 sidecar 镜像 |
| 流量管控粒度 | 依赖框架能力 | L7 细粒度（按版本/header） |
Service Mesh 基础
核心定义：Service Mesh 是专门处理服务间通信的基础设施层，是一个轻量级网络代理（sidecar）网格，与应用部署在一起，对应用透明。
- Sidecar 模式：每个 Pod 注入一个代理容器（如 Envoy），应用只与 localhost 的代理通信，代理再转发到对端代理，形成数据面。
- 数据面（Data Plane）：一组 sidecar 代理，负责实际的流量转发、熔断、加密、指标采集。
- 控制面（Control Plane）：如 Istio 的 istiod，负责配置下发、服务发现、证书签发，统一管理所有 sidecar。
三大核心能力：① 流量管理（路由、切分、重试）；② 安全（mTLS 零信任、认证授权）；③ 可观测性（指标、日志、链路统一采集）。应用代码彻底解耦这些横切关注点。
Istio 流量治理
Istio 通过两类 CRD 描述期望流量：VirtualService 定义路由规则，DestinationRule 定义目标服务的策略（负载均衡、熔断、子集）。
金丝雀发布：将 90% 流量导 v1、10% 导 v2，按权重切分，无需改代码即可灰度：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews-route
spec:
hosts: ["reviews"]
http:
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10熔断与超时：在 DestinationRule 配 outlierDetection 实现异常实例驱逐，配 trafficPolicy 的 timeout/retry 控制弹性。mTLS 设 PeerAuthentication 为 STRICT 后，服务间自动双向 TLS，应用无感。
可观测性
Mesh 的最大红利之一：无需埋点即可获得全栈可观测性。Sidecar 天然处于流量路径上，自动产生三类信号：
- 指标（Metrics）：请求量、错误率、延迟（RED 指标），经 Envoy 暴露给 Prometheus 抓取。
- 日志（Logs）：访问日志结构化输出，关联 traceId。
- 链路（Tracing）：自动注入 b3/traceparent 头，串联跨服务调用，由 Jaeger 收集。
Kiali 基于以上信号绘制服务拓扑图与流量健康度，是排查调用异常、定位高延迟边的首选面板。
GitOps 声明式交付
核心思想：Git 仓库里的声明式配置（K8s YAML / Helm / Kustomize）就是集群的"期望状态"；一个控制器持续比对"期望"与"实际"，并自动纠偏（sync）。所有变更经 Pull Request 评审合并，天然具备审计 trail。
Argo CD 架构：argocd-server 提供 UI/API，repo-server 解析 Git，application-controller 负责同步与健康检查。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo.git
path: manifests/overlays/prod
targetRevision: HEAD
destination:
server: https://kubernetes.default.svc
namespace: my-app
syncPolicy:
automated:
prune: true
selfHeal: true回滚：argocd app rollback 切到旧 commit 即可；selfHeal 保证手动改集群会被自动还原，杜绝配置漂移。
面试模拟
Q1：Service Mesh 相比 SDK 微服务治理有什么优缺点？
答：优点是语言无关、升级解耦、零侵染、统一可观测；缺点是资源开销（每 Pod 多一容器）、运维复杂度、延迟增加（多一跳）。
Q2：Istio 的 sidecar 注入方式有哪两种？
答：自动注入（namespace 打 istio-injection=enabled 标签，admission webhook 拦截 Pod 创建）与手动注入（istioctl kube-inject）。
Q3：GitOps 与传统 CI/CD 的区别？
答：传统是"推送式"（CI 构建后 push 到集群）；GitOps 是"拉取式"（控制器常驻集群内，主动比对 Git 并 sync），更安全、可回滚、抗漂移。
Q4：K8s 滚动更新和 Istio 金丝雀的本质区别？
答：滚动更新按 Pod 副本比例替换，流量无差别切；金丝雀按请求维度（权重/header）精确路由，可快速暂停与回退，对用户体验影响更小。