📚 课程目录第3章安装与初始化

3. 安装与初始化

OpenShift Service Mesh 的安装并不是“装一个组件”这么简单，它实际上由三层对象叠加而成：最底层是 Operator，负责把控制面与数据面的镜像、CRD、Webhook 和 RBAC 准备好；中间层是 ServiceMeshControlPlane（SMCP），它声明一个网格控制面实例（Istiod、Ingress/Egress Gateway、Prometheus、Grafana、Jaeger 等）；最上层是 ServiceMeshMemberRoll（SMMR），它决定哪些命名空间被纳入这个控制面的治理范围。多租户场景下，还要额外准备成员角色，让租户命名空间能被网格接管而不越权。理解这三层对象的职责边界，是后续所有治理动作的前提。

一、Operator 部署：先确认安装模式与命名空间

在 OpenShift 4.x 中，Service Mesh Operator 通过 OperatorHub 安装，通常选择 stable 通道，安装模式建议使用 All namespaces on the cluster（即全局安装），这样 Operator 可以监听所有命名空间中的 SMCP 与 SMMR 资源。安装命名空间一般固定为 openshift-operators，而控制面实例则建议放在独立命名空间，例如 istio-system 或按租户划分的 mesh-<tenant>。

安装完成后，先不要急着创建 SMCP，而应确认三件事：Operator Pod 是否 Running、CRD 是否已注册、Webhook 是否可用。可用以下命令快速核对：

oc get csv -n openshift-operators | grep servicemesh
oc get crd | grep -E 'servicemesh|maistra'
oc get pods -n openshift-operators | grep servicemesh

如果 CSV 处于 Succeeded，CRD 中存在 servicemeshcontrolplanes.maistra.io 与 servicemeshmemberrolls.maistra.io，说明 Operator 层已就绪。此时再创建控制面，失败概率会显著降低。

二、SMCP：控制面的“规格说明书”

SMCP 是声明式对象，它不描述“怎么装”，而描述“要什么”。一个最小可用的 SMCP 通常包含 version、profiles、policy、telemetry、tracing、gateways 等字段。生产环境建议显式指定版本，避免 Operator 升级时自动漂移。下面是一个教学示例（参数为示例值，实际请按集群规格调整）：

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
  namespace: istio-system
spec:
  version: v2.5
  profiles:
    - default
  policy:
    type: Istiod
  telemetry:
    type: Istiod
  tracing:
    type: Jaeger
    sampling: 10000
  gateways:
    ingress:
      enabled: true
      service:
        type: ClusterIP
    egress:
      enabled: true

创建后，Operator 会依次拉起 Istiod、Ingress Gateway、Egress Gateway、Prometheus、Grafana、Jaeger 等组件。观察 oc get smcp -n istio-system 的 READY 列变为 True，且 oc get pods -n istio-system 中所有 Pod 处于 Running，才认为控制面初始化完成。若卡在 False，优先看 oc describe smcp 的 Conditions 与 Operator 日志，常见原因是资源不足、Webhook 证书未就绪或版本不匹配。

三、SMMR：把命名空间“拉进网格”

SMMR 必须与控制面同命名空间，且名称固定为 default。它通过 members 列表声明哪些命名空间加入网格。注意：SMMR 只负责“成员资格”，不负责“权限授予”。也就是说，即使命名空间被列入 members，如果该命名空间没有对应的 RoleBinding，Sidecar 注入和配置分发仍可能失败。

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:
    - bookinfo
    - tenant-a
    - tenant-b

创建后可用 oc get smmr -n istio-system 查看 READY 与 CONFIGURED 状态。若某个成员命名空间未就绪，通常是因为该命名空间缺少 maistra.io/member-of 标签或缺少必要的 RoleBinding。

四、多租户成员角色准备：让租户“能加入、不越权”

多租户的核心矛盾是：租户需要在自己的命名空间里创建 Deployment、Service、VirtualService 等资源，但不应看到或修改其他租户的网格配置。标准做法是：为每个租户命名空间创建 RoleBinding，把 OpenShift Service Mesh 提供的 servicemesh-member 角色绑定给租户用户或 Group。这样租户只能操作自己命名空间内的网格资源，而 SMMR 的成员资格由平台团队统一维护。

一个可复用的准备清单如下：

为租户创建独立命名空间，例如 tenant-a，并打上 maistra.io/member-of: istio-system 标签。
在租户命名空间内创建 RoleBinding，将 servicemesh-member 绑定到租户 Group。
由平台团队把租户命名空间加入 SMMR 的 members 列表。
验证：租户用户能在自己命名空间创建 Deployment，且 Sidecar 自动注入；同时无法查看 istio-system 中的 SMCP。

若租户命名空间未出现在 SMMR 中，Sidecar 注入不会生效；若缺少 RoleBinding，租户用户可能连自己的 Deployment 都无法创建。两者必须同时满足。

五、三层对象的关系与初始化顺序

把 Operator、SMCP、SMMR 与成员角色放在一起看，它们构成一条清晰的依赖链：Operator 提供能力，SMCP 定义控制面，SMMR 划定范围，RoleBinding 授予权限。初始化顺序也应按此依赖推进，否则容易出现“控制面已就绪但命名空间未纳入”或“命名空间已纳入但租户无权限”的中间态。

实际初始化时，建议按“Operator → SMCP → SMMR → RoleBinding”的顺序推进，并在每一步都做一次状态确认。这样一旦出现异常，可以快速定位是能力层、控制面层、范围层还是权限层的问题，而不是在多个对象之间反复猜测。对于多租户平台，SMMR 的 members 列表和 RoleBinding 往往由平台团队统一维护，租户只负责在自己命名空间内声明工作负载与流量规则，这种职责分离正是 Service Mesh 多租户治理能够稳定运行的关键。