📚 课程目录第1章治理工程导入

1. 治理工程导入

在进入 OpenShift Service Mesh 的具体配置之前，必须先回答一个工程上最容易被忽略、却决定后续所有工作是否可维护的问题：治理边界在哪里。Service Mesh 不是"给微服务加个代理"这么简单，它是一层独立于业务代码的基础设施，承担流量路由、安全身份、可观测性和策略执行四类职责。如果边界不清，团队很容易把业务逻辑、网关职责、集群网络策略和网格治理混在一起，最终导致配置散落、故障定位困难、升级风险不可控。

一、治理边界：网格管什么，不管什么

OpenShift Service Mesh 基于上游 Istio 构建，其治理能力落在数据平面（Envoy Sidecar 或 Ambient 模式下的 ztunnel/Waypoint）与控制平面（Istiod）之间。工程上需要明确三条边界线：

东西向 vs 南北向：网格主要治理集群内部服务间的东西向流量；南北向入口通常由 OpenShift Ingress/Gateway 或独立的 Istio Ingress Gateway 承担，二者职责要分开定义，避免把外部暴露策略写进内部 VirtualService。
网格内 vs 网格外：只有被注入 Sidecar（或纳入 Ambient 数据平面）的工作负载才受网格策略约束。未注入的 Pod 之间的调用不受 mTLS、AuthorizationPolicy 影响，这是排障时最常见的"策略不生效"根因。
平台层 vs 应用层：网格提供的是通用能力（重试、超时、熔断、mTLS、遥测），业务语义（如订单状态机、幂等键）仍属于应用。把业务判断塞进 EnvoyFilter 是典型的越界，会带来不可维护的技术债。

判断一条需求是否属于网格治理，可以问：它是否只依赖服务身份、流量特征和通用策略？如果是，适合放进网格；如果依赖业务字段语义，应回到应用层实现。

二、核心对象全景

OpenShift Service Mesh 的治理对象可以分为四组，理解它们的层级关系比记住字段更重要：

分组	核心对象	作用
身份与安全	PeerAuthentication、RequestAuthentication、AuthorizationPolicy	定义 mTLS 模式、JWT 校验、服务级访问控制
流量治理	VirtualService、DestinationRule、Gateway、ServiceEntry	路由匹配、版本分流、负载均衡、熔断、外部服务注册
可观测性	Telemetry、Prometheus、Kiali、Jaeger	指标、拓扑、链路追踪的采集与展示
网格生命周期	ServiceMeshControlPlane、ServiceMeshMemberRoll	控制平面版本与配置、命名空间纳管范围

其中 ServiceMeshControlPlane（SMCP）和 ServiceMeshMemberRoll（SMMR）是 OpenShift 特有的封装对象，前者管理 Istiod 的部署与版本，后者决定哪些命名空间加入网格。它们决定了"网格的物理范围"，是所有其他策略生效的前提。

三、工程化落地全景

从零到可治理，工程落地通常经历四个阶段，下图展示了对象之间的依赖与数据流关系：

图中实线表示控制与数据流，虚线表示策略下发。可以看到，所有策略最终都作用在数据平面的 Envoy 代理上，而代理又依附于具体工作负载。这意味着：策略生效的前提是工作负载已被纳管且已注入代理。如果 SMMR 中没有某个命名空间，即使写了 AuthorizationPolicy 也不会对该命名空间内的 Pod 产生任何效果。

四、一个可执行的落地起点

假设我们要把 order-ns 和 payment-ns 两个命名空间纳入网格，并开启严格 mTLS。工程上建议按以下顺序操作，每一步都有明确的验证点：

# 1. 确认控制平面就绪
oc get smcp -n istio-system
# 期望：READY=True，版本与 OpenShift 版本匹配

# 2. 将命名空间加入成员列表
oc patch smmr default -n istio-system --type merge \
  -p '{"spec":{"members":["order-ns","payment-ns"]}}'
# 验证：oc get smmr default -n istio-system -o yaml

# 3. 为工作负载开启注入
oc label namespace order-ns istio-injection=enabled
oc label namespace payment-ns istio-injection=enabled
# 验证：重启 Pod 后 oc get pod -n order-ns 应显示 2/2 Ready

# 4. 下发严格 mTLS 策略
cat <<EOF | oc apply -f -
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: order-ns
spec:
  mtls:
    mode: STRICT
EOF

# 5. 验证 mTLS 是否生效
istioctl x describe pod -n order-ns <order-pod-name>
# 期望输出包含：mTLS: STRICT

这里的关键判断依据是：Pod 的 Ready 列从 1/1 变为 2/2，说明 Sidecar 已注入；istioctl x describe 输出中 mTLS 模式为 STRICT，说明策略已下发到该工作负载。如果这两步任一不满足，后续所有流量治理和可观测性都无从谈起。

常见误区：先写 VirtualService 再检查注入状态。正确顺序是先确认纳管与注入，再下发策略。否则会出现"配置写了但流量没变化"的假象，浪费大量排障时间。

五、工程化落地的四个阶段

从治理工程视角看，落地不是一次性动作，而是分阶段推进：

纳管与注入：确定 SMMR 成员，开启自动注入，验证 Sidecar 就绪。此阶段不改变业务行为，风险最低。
安全基线：逐步从 PERMISSIVE 过渡到 STRICT mTLS，配合 AuthorizationPolicy 建立最小访问集。建议先在测试命名空间验证，再推广。
流量治理：引入 VirtualService 做灰度、超时、重试，DestinationRule 做负载均衡与熔断。此阶段开始影响业务流量，需要灰度发布和回滚预案。
可观测与运营：接入 Kiali 拓扑、Prometheus 指标、Jaeger 追踪，建立 SLO 看板和告警规则，形成持续运营闭环。

这四个阶段的顺序不是教条，但跳过第一阶段直接做流量治理，几乎必然遇到"策略不生效"的问题。工程化落地的核心不是配置数量，而是每一步都有可验证的中间状态，让问题在最小范围内暴露。