服务网格核心由数据平面（Envoy Sidecar）和控制平面（Pilot、Citadel、Galley 等）组成；流量策略通过 VirtualService、DestinationRule 等 CRD 定义；可观测性依赖 Envoy 指标与 Kiali 联动；安全需渐进式启用 mTLS 并精细化配置。
服务网格（Service Mesh）是云原生架构中实现微服务间通信、可观测性与安全治理的关键基础设施。它将网络通信逻辑从应用代码中剥离，以轻量代理（如 Envoy）Sidecar 形式注入每个服务实例，由控制平面统一调度策略。
服务网格的核心组件怎么搭
典型服务网格（如 Istio）分数据平面和控制平面：
- 数据平面 ：由一组与业务容器同 Pod 部署的 Envoy 代理组成，负责拦截进出流量、执行 路由、熔断、重试等策略；
- 控制平面：包括 Pilot（服务发现与配置分发）、Citadel（证书签发与 mTLS 管理）、Galley（配置校验）等模块，Kubernetes 上常以 CRD+Operator 方式部署。
在 Linux 云环境中，推荐用 Helm 或 istioctl 命令行 工具 安装 Istio，避免手动部署组件。安装后需启用自动 Sidecar 注入（label namespace with istio-injection=enabled），让新创建的 Pod 自动携带 Envoy 容器。
流量治理策略怎么写才有效
服务网格的价值集中体现在可编程的流量控制能力上。关键策略通过 Kubernetes CRD 定义：
- VirtualService：定义路由规则，比如按 HTTP 头、路径、权重分流到不同版本服务（如 v1/v2 灰度发布）；
- DestinationRule：设置目标服务的连接池、熔断阈值、TLS 模式（如强制 mTLS）；
- Gateway：暴露入口流量，替代传统 Ingress，支持更细粒度的 L7 策略；
- PeerAuthentication 和 RequestAuthentication：分别管控服务间双向认证与终端用户 JWT 鉴权。
注意：策略生效依赖于服务注册一致性，确保所有服务在 Kubernetes 中正确声明 Service 与 Endpoint，且 Pod 就绪探针（readinessProbe）配置合理，否则 Envoy 可能将未就绪实例纳入负载均衡。
可观测性怎么跟服务网格联动
Envoy 默认上报指标（Prometheus 格式）、访问日志与分布式追踪（Zipkin/Jaeger 格式）。要真正用起来，需三步打通：
- 开启 Istio 遥测组件（如 istiod 内置的 Telemetry v2，或独立部署 Prometheus+Grafana+Jaeger）；
- 为服务添加 app 和version标签，让指标带业务维度；
- 在 Kiali 控制台中查看服务拓扑、延迟热力图、错误率趋势——它直接解析 Istio CRD 与 Envoy 指标，无需修改应用代码。
常见误区是只看全局 QPS，忽略单个服务实例的连接数激增或上游超时率突升，这些细节在 Kiali 的服务详情页里点开“Metrics”就能定位。
安全策略怎么落地不踩坑
服务网格让零信任网络在 Linux 容器环境变得可实施，但配置不当反而引发通信中断：
- mTLS 默认仅对网格内服务启用，外部调用（如 浏览器 访问 Ingress Gateway）仍走明文，需单独配置 Gateway TLS 终止；
- PeerAuthentication 设为 STRICT 模式前，先用 PERMISSIVE 模式观察流量是否正常，再逐步收紧；
- 避免在 Namespace 级粗粒度启用 mTLS，应按服务对（source→destination）精细化配置，减少误伤；
- Citadel 已弃用，新版 Istio 使用 istiod 内置 CA，证书有效期默认为 1 年，可通过 –set values.global.ca.signedCertTTL=360h 调整。
安全不是一劳永逸，建议配合定期轮换根 CA、审计 RBAC 绑定关系、禁用默认允许的 NetworkPolicy，形成纵深防御。
