构建基于服务网格的 AI 应用程序并开始运行很容易

作者：尹航。

在 2023 年云栖大会上，阿里云 Service Mesh ASM 发表了题为“两全其美：融合 Sidecarless 和 Sidecar 模式的服务网格新形式”的主题演讲，展示了基于 Service Mesh ASM 能力构建的 AI 应用演示。 该应用程序展示了 ASM 在模型服务、请求处理、请求路由和安全中心与单点登录集成方面的功能，所有这些都以无边路的形式进行。

看完我们的演示后，您可能还想尝试一下，从头开始构建这样的应用程序来玩绝对！我们向您保证，我们能建造什么，您就能建造什么。 这篇文章对你来说就是这样一本入门书，所以让我们开始吧！

1. 先决条件

一个 ACK 集群、一个 ASM 实例以及 Istioctl 等相关工具是一切的基础，我们先准备一些实验环境。

已创建实例版本为 1 的 ASM 实例18.0.131 及以上。 具体操作，请参见创建ASM实例。在创建服务网格页面配置数据平面模式检查启用环境网格模式。 已创建Kubernetes集群，满足Kubernetes集群和配置要求。关于如何创建集群，请参见创建Kubernetes独享集群或者创建 Kubernetes 托管集群。已将集群添加到ASM实例中。 具体操作，请参见为ASM实例添加集群。istioctl 服务网格调试工具已根据实际操作系统和平台使用。 有关更多信息，请参阅 Istio2. 构建模型推理服务

1）开启ASM的多模型推理服务生态集成能力。

对于一个基于AI模型推理的应用服务来说，将训练好的模型快速转化为弹性灵活的模型推理服务，无疑是工作的重点之一。

作为应用感知的下一代云原生基础设施，ASM 还通过其丰富的生态集成能力集成了云原生推理服务框架 Kserve（参见 ASM 集成云原生推理服务框架 Kserve），为AI模型推理服务化提供一站式解决方案。

在最新版本的 Service Mesh （ASM） 中，我们引入了多模型服务框架 （ModelMesh），用于 alpha 阶段的模型推理服务集成。 在新的 ModelMesh 服务框架中，不同的模型及其推理将被卸载到多个运行时工作负载。 每个运行时都支持不同的模型格式;并且可以同时为多个模型提供推理服务。 当我们使用 InferenceService 资源定义模型时，模型文件会根据模型的格式动态加载到相应的运行时工作负载中。 单个运行时可以同时为多个模型提供推理服务。

我们可以将多模型推理服务框架ModelMesh：与以下步骤集成

1.在 ASM 实例中创建名为 modelmesh-serving 的全局命名空间（请参阅管理全局命名空间

2.要使用此功能，我们首先使用 kubectl 连接到 ASM 实例（参见通过控制平面 Kubectl 访问 Istio 资源）。

3.使用以下文件创建 asmkserveconfigyaml

apiversion: istio.alibabacloud.com/v1beta1kind: asmkserveconfigmetadata: name: defaultspec: enabled: true multimodel: true tag: v0.11.0

kubectl apply -f asmkserveconfig.yaml

2）准备模型文件并声明推理服务。

模型推理服务框架准备就绪后，我们需要准备训练模型文件，并将模型加载到运行时工作负载中，成为可以对外暴露的推理服务。

1.准备模型文件。

机器学习模型训练完成后，可以保存在各种序列化方式中（例如：s**ed model、PKL 等），模型推理服务器可以加载并使用这些模型文件，为训练好的机器学习模型提供推理服务。

在这个演示应用程序中，我们还需要准备这样一个模型文件。 事实上，我们已经准备了两个经过训练的模型。 这两个模型分别基于 TensorFlow 和 PyTorch，其中 PyTorch 模型生成固定样式，而 TensorFlow 模型可以提取样式并执行不同的风格化处理。

模型的获取也非常简单，不需要自己训练。 我们只需要通过 TensorFlow 和 PyTorch 的官方渠道获取即可。

TensorFlow 模型可通过 TensorFlow Hub 获得，可在此处访问**： 至于 PyTorch 模型，我们在本例中使用了官方演示中的模型，并将其转换为 Onnx 格式。 我们可以参考这个教程来转换模型文件： 注意：在转换为 onnx 模型的步骤中，我们使用 512*512 作为输入，注意输入大小，这对于 onnx 格式的模型很重要）。Demo 中提供了四种固定样式的模型，我们可以选择其中任何一种，我们在 Demo 中选择了 Candy 模型。 到达本地后，我们可以随机找到一个路径作为根目录，新建一个 tensorflow 文件夹和一个 pytorch 文件夹，分别保存两个模型的文件。 我们将两个模型的模型文件保存如下，以便于跟进。

tensorflow 模型如下所示：

下面是 pytorch 模型的样子：

在根目录下执行ls -r命令，查看以下文件结构：

$ ls -rpytorch tensorflow./pytorch:style-transfer./pytorch/style-transfer:candy.onnx./tensorflow:style-transfer./tensorflow/style-transfer:s**ed_model.pb variables./tensorflow/style-transfer/variables:variables.data-00000-of-00002 variables.data-00001-of-00002 variables.index

首先，创建一个存储类，进入容器服务控制台的存储>存储类，创建一个存储类

接下来，创建一个 pvc，进入 容器服务控制台 存储> 存储声明，使用您刚刚创建的存储类创建存储声明 pvc，名为 my-models-pvc。

创建 Pod 将模型文件复制到 pvc 中 进入 TKE 控制台的工作负载>容器组，点击“使用 yaml 创建”，在 yaml 框中输入以下内容，单击“创建”即可创建 Pod。

apiversion: v1kind: podmetadata: name: "pvc-access" namespace: modelmesh-servingspec: containers: -name: main image: ubuntu command: ["/bin/sh", "-ec", "sleep 10000"] volumemounts: -name: "my-pvc" mountpath: "/mnt/models" volumes: -name: "my-pvc" persistentvolumeclaim: claimname: "my-models-pvc"

首先，使用 kubectl 连接 ACK 集群（参考获取集群 kubeconfig 并通过 kubectl 工具连接集群）。

接下来，在模型文件的根目录下，打开命令行并运行以下命令：

kubectl cp -n modelmesh-serving tensorflow pvc-access:/mnt/models/kubectl cp -n modelmesh-serving pytorch pvc-access:/mnt/models/

kubectl exec -n modelmesh-serving pvc-access --ls /mnt/models

pytorchtensorflow

使用以下命令创建 ISVCyaml 文件。

apiversion: serving.kserve.io/v1beta1kind: inferenceservicemetadata: name: tf-style-transfer namespace: modelmesh-serving annotations: serving.kserve.io/deploymentmode: modelmesh #serving.kserve.io/secretkey: myossspec: predictor: model: modelformat: name: tensorflow storage: parameters: type: pvc name: my-models-pvc path: tensorflow/style-transfer/---apiversion: serving.kserve.io/v1beta1kind: inferenceservicemetadata: name: pt-style-transfer namespace: modelmesh-serving annotations: serving.kserve.io/deploymentmode: modelmeshspec: predictor: model: modelformat: name: onnx storage: parameters: type: pvc name: my-models-pvc path: pytorch/style-transfer/

使用以下命令在ACK集群中创建模型推理服务。

kubectl apply -f isvc.yaml

当运行时启动和模型加载都完成后，使用 kubectl 获取 InferenceService，可以看到两个 InferenceService 也都处于就绪状态

$ kubectl get isvc -n modelmesh-serving name url ready prev latest prevrolledoutrevision latestreadyrevision agept-style-transfer grpc: true 11dtf-style-transfer grpc: true 11d

模型推理服务前面是我们的业务服务，分别是样式转移业务服务和前面的AI应用服务，我们需要将这些服务以及服务的工作量部署在集群中。

1.使用kubectl连接ACK集群，并使用以下命令创建命名空间部署应用。

kubectl create namespace apsara-demo

apiversion: v1kind: serviceaccountmetadata: name: ai-backend namespace: apsara-demo---apiversion: v1kind: serviceaccountmetadata: name: style-transfer namespace: apsara-demo---apiversion: apps/v1kind: deploymentmetadata: labels: app: ai-backend name: ai-backend namespace: apsara-demospec: progressdeadlineseconds: 600 replicas: 1 revisionhistorylimit: 10 selector: matchlabels: app: ai-backend strategy: rollingupdate: maxsurge: 25% maxun**ailable: 25% type: rollingupdate template: metadata: labels: app: ai-backend spec: serviceaccountname: ai-backend containers: -image: 'registry.cn-hangzhou.aliyuncs.com/build-test/asm-apsara:g56a99cd1-aliyun' imagepullpolicy: ifnotpresent name: ai-backend ports: -containerport: 8000 name: http protocol: tcp resources: requests: cpu: 250m memory: 512mi terminationmessagepath: /dev/termination-log terminationmessagepolicy: file dnspolicy: clusterfirst restartpolicy: always schedulername: default-scheduler securitycontext: {terminationgraceperiodseconds: 30---apiversion: apps/v1kind: deploymentmetadata: labels: app: style-transfer name: style-transfer-tf namespace: apsara-demospec: progressdeadlineseconds: 600 replicas: 1 revisionhistorylimit: 10 selector: matchlabels: app: style-transfer model-format: tensorflow strategy: rollingupdate: maxsurge: 25% maxun**ailable: 25% type: rollingupdate template: metadata: labels: app: style-transfer model-format: tensorflow spec: serviceaccountname: style-transfer containers: -image: >registry.cn-hangzhou.aliyuncs.com/build-test/style-transfer-tf:g78d00b1c-aliyun imagepullpolicy: ifnotpresent name: style-transfer-tf env: -name: model_server value: istio-ingressgateway.istio-system.svc.cluster.local:8008 - name: model_name value: tf-style-transfer ports: -containerport: 8000 name: http protocol: tcp resources: requests: cpu: 250m memory: 512mi terminationmessagepath: /dev/termination-log terminationmessagepolicy: file dnspolicy: clusterfirst restartpolicy: always schedulername: default-scheduler securitycontext: {terminationgraceperiodseconds: 30---apiversion: apps/v1kind: deploymentmetadata: labels: app: style-transfer name: style-transfer-torch namespace: apsara-demospec: progressdeadlineseconds: 600 replicas: 1 revisionhistorylimit: 10 selector: matchlabels: app: style-transfer model-format: pytorch strategy: rollingupdate: maxsurge: 25% maxun**ailable: 25% type: rollingupdate template: metadata: labels: app: style-transfer model-format: pytorch spec: serviceaccountname: style-transfer containers: -image: >registry.cn-hangzhou.aliyuncs.com/build-test/style-transfer-torch:g78d00b1c-aliyun imagepullpolicy: ifnotpresent name: style-transfer-torch env: -name: model_server value: istio-ingressgateway.istio-system.svc.cluster.local:8008 - name: model_name value: pt-style-transfer ports: -containerport: 8000 name: http protocol: tcp resources: requests: cpu: 250m memory: 512mi terminationmessagepath: /dev/termination-log terminationmessagepolicy: file dnspolicy: clusterfirst restartpolicy: always schedulername: default-scheduler securitycontext: {terminationgraceperiodseconds: 30---apiversion: v1kind: servicemetadata: labels: app: ai-backend name: ai-backend-svc namespace: apsara-demospec: internaltrafficpolicy: cluster ipfamilies: -ipv4 ipfamilypolicy: singlestack ports: -name: http port: 8000 protocol: tcp targetport: 8000 selector: app: ai-backend type: clusterip---apiversion: v1kind: servicemetadata: labels: app: style-transfer name: style-transfer namespace: apsara-demospec: internaltrafficpolicy: cluster ipfamilies: -ipv4 ipfamilypolicy: singlestack ports: -name: http port: 8000 protocol: tcp targetport: 8000 selector: app: style-transfer sessionaffinity: none type: clusterip

kubectl apply -f ai-apps.yaml

部署的最后一部分是关于服务网格的，具体如下：

ASM 入口网关。 Mesh Waypoint **它是一种无边车服务网格能力载体。 Service Mesh 流量规则，该规则将对 ASM 网关和 Waypoint** 生效，以确保流量路径的行为符合我们的设计。 1.部署ASM入口网关。

例如，我们可以参考 创建 Ingress 网关创建 ASM 入口网关。 我们需要创建两个 ASM ingresgateway 网关，其中一个叫 API-ingresgateway，服务类型是 loadbalancer，网关上需要开启 80 端口另一个叫IngressGateway，服务类型为ClusterIP，需要在网关上开启8008端口。 网关配置的其余部分可以保留为默认值。

创建完所有内容后，我们应该能够在 ASM 入口网关页面上看到以下内容：

2.在apsara-demo命名空间中开启环境网格模式。

登录ASM控制台在左侧导航栏，选择服务网格>网格管理。 在网格管理页面中，单击目标实例名称，然后在左侧导航栏选择网格实例>全局命名空间。 在全局命名空间页面上，单击从 Kubernetes 集群同步自动注入选择数据平面 ack 集群并单击它是否确定。 在全局命名空间页之数据平面模式列中，单击apsara-demo命名空间切换到环境网格模式然后确认对话框中，单击是否确定。 3.部署 WayPoint

使用 kubectl 连接 ACK 集群，然后使用前提条件中安装的 istioctl 工具执行以下命令：

istioctl x waypoint apply --service-account style-transfer -n apsara-demo

kubectl get deploy -n apsara-demo

name ready up-to-date **ailable ageai-backend 1/1 1 1 13dstyle-transfer-istio-waypoint 1/1 1 1 13dstyle-transfer-tf 1/1 1 1 13dstyle-transfer-torch 1/1 1 1 13d

部署服务网格规则 使用以下命令创建模型vc-routingyaml 文件。

# make sure voyage is 1.13.4.13 or higherapiversion: networking.istio.io/v1beta1kind: gatewaymetadata: name: grpc-gateway namespace: modelmesh-servingspec: selector: istio: ingressgateway servers: -hosts: -'*' port: name: grpc number: 8008 protocol: grpc - hosts: -'*' port: name: http number: 80 protocol: http---apiversion: networking.istio.io/v1beta1kind: virtualservicemetadata: name: vs-modelmesh-serving-service namespace: modelmesh-servingspec: gateways: -grpc-gateway hosts: -'*' http: -headertodynamicsubsetkey: -header: x-model-format-tensorflow key: model.format.tensorflow - header: x-model-format-pytorch key: model.format.pytorch match: -port: 8008 name: default route: -destination: host: modelmesh-serving port: number: 8033---apiversion: networking.istio.io/v1beta1kind: destinationrulemetadata: name: dr-modelmesh-serving-service namespace: modelmesh-servingspec: host: modelmesh-serving-service trafficpolicy: loadbalancer: dynamicsubset: subsetselectors: -keys: -model.format.tensorflow - keys: -model.format.pytorch---apiversion: istio.alibabacloud.com/v1beta1kind: asmgrpcjsontranscodermetadata: name: grpcjsontranscoder-for-kservepredictv2 namespace: istio-systemspec: builtinprotodescriptor: kserve_predict_v2 isgateway: true portnumber: 8008 workloadselector: labels: istio: ingressgateway---apiversion: networking.istio.io/v1alpha3kind: envoyfiltermetadata: labels: asm-system: 'true' provider: asm name: grpcjsontranscoder-increasebufferlimit namespace: istio-systemspec: configpatches: -applyto: listener match: context: gateway listener: portnumber: 8008 proxy: proxyversion: ^1.* patch: operation: merge value: per_connection_buffer_limit_bytes: 100000000 workloadselector: labels: istio: ingressgateway

模型推理服务中不同运行时工作负载的动态子集的高路由能力，以及 Kserve V2 推理接口的 JSON HTTP-gRPC 请求转码能力，我们将在下一大节中详细介绍。

使用 kubectl 连接 ASM 实例，执行以下命令部署 modelsvc-routing 流量规则。

kubectl apply -f modelsvc-routing.yaml

apiversion: networking.istio.io/v1beta1kind: gatewaymetadata: name: ai-app-gateway namespace: apsara-demospec: selector: istio: api-ingressgateway servers: -hosts: -'*' port: name: http number: 8000 protocol: http - hosts: -'*' port: name: http-80 number: 80 protocol: http---apiversion: networking.istio.io/v1beta1kind: virtualservicemetadata: name: ai-app-vs namespace: apsara-demospec: gateways: -ai-app-gateway hosts: -'*' http: -route: -destination: host: ai-backend-svc port: number: 8000---apiversion: networking.istio.io/v1beta1kind: virtualservicemetadata: name: style-transfer-vs namespace: apsara-demospec: hosts: -style-transfer.apsara-demo.svc.cluster.local http: -match: -headers: user_class: exact: premium route: -destination: host: style-transfer.apsara-demo.svc.cluster.local port: number: 8000 subset: tensorflow - route: -destination: host: style-transfer.apsara-demo.svc.cluster.local port: number: 8000 subset: pytorch---apiversion: networking.istio.io/v1beta1kind: destinationrulemetadata: name: style-transfer-dr namespace: apsara-demospec: host: style-transfer.apsara-demo.svc.cluster.local subsets: -labels: model-format: tensorflow name: tensorflow - labels: model-format: pytorch name: pytorch

使用 kubectl 连接 ASM 实例，执行以下命令部署 app-routing 流量规则：

kubectl apply -f app-routing.yaml

设置整个应用程序的最后一步是在应用程序的主入口处，即 ASM 入口网关。 在这里，我们还需要将网关与阿里云 Idaas 的 OIDC 应用程序对接，并为整个应用程序配置单点登录。

我们可以参考这个文档进行对接操作： ASM集成阿里云Idaas，实现网格内应用单点登录

值得注意的是，我们在用户 jwt 声明中使用了 user type 附加字段来完成对用户的识别，这需要以下操作：

点击云身份服务的扩展字段，添加扩展字段（扩展字段名称和 OIDC 登录后返回的字段名称可以自定义，这里扩展字段定义为用户类型，OIDC 登录后返回的字段名称会在后面定义为用户类）。

然后编辑用户信息以设置指定用户的字段：

设置该字段后，您需要配置OIDC登录成功后返回的字段。 转到 OIDC 应用程序设置，单击“登录访问”选项卡，然后单击“显示高级配置”。 这里可以设置oidc登录成功后返回的键值对，key为用户类型，value为用户类的值。

我们戴着星星和月亮，我们终于不在乎自己了！我们的 AI 应用程序已准备就绪！可以看出，从零开始构建这样一套集成模型推理的业务服务，确实不是一步到位的爬天，但 Service Mesh ASM 通过一些生态集成能力和完整的 Web UI 简化了很多步骤。

3、try it out！

在ASM控制台的网格管理页面，我们可以直接看到API-IngressGateway的服务地址

整个应用程序的入口点是 http： home。 在您的浏览器中打开它，然后开始使用我们的 AI 应用程序

本节将简要介绍 Service Mesh ASM 在此演示中开放的一些功能，以帮助我们完成更多工作。 这就是我们在飞天大会上向您介绍的内容。

1. 模型服务运行时的动态子集路由

在AI应用的构建中，如何将训练好的模型转化为可靠的推理服务是工作的重点，所以我们在这个Demo中首先介绍模型推理服务。

在模型推理服务的整体框架中，所有模型的推理都是由整个 k8s 服务对外提供的。 但是，模型有很多种，如何才能将 Sklearn、TensorFlow、Pytorch 等不同种类的模型统一到具有相同 API 的推理服务中这需要不同的运行时。

在统一的模型推理服务下，不同的模型及其推理被卸载到多个运行时工作负载。 每个运行时都支持不同的模型格式;并且可以同时为多个模型提供推理服务。 当我们使用 InferenceService 资源定义模型时，模型文件会根据模型的格式动态加载到相应的运行时工作负载中。 单个运行时可以同时为多个模型提供推理服务。

这样一来，模型推理服务部署就具有高弹性、高弹性、高成本、低成本的特点。

但是，这种方法存在一个问题，即存在额外的路由成本。 由于 K8S Service 的机制，请求发送到模型推理服务后，K8S 不会区分请求的模型格式，而是将请求随机分发到不同的运行时工作负载，因此无法保证请求能够正确发送到可以提供服务的运行时。 这需要将额外的模型代理注入运行时，以执行额外的路由操作并确保正确响应请求，随着运行时的扩展，这可能会导致成本和性能问题。

这就是服务网格的价值所在。 服务网格可以通过数据平面的网格动态识别模型推理服务内部支持不同模型格式的运行时。 当推理请求发送时，它会根据请求元数据搜索匹配的运行时分组，以确保请求可以直接发送到正确的运行时，在不增加运维成本的情况下减少系统路由消耗，这被称为动态子集路由能力。

要实现动态子集路由，我们只需要使用为 service 配置的 destinationrule 资源和 virtualservice 资源即可。

运行时标识基于工作负载标签，工作负载标签声明了一系列与模型格式相关的标签，服务网格会根据这些标签对运行时进行动态分组。 在目标规则中，声明了一系列标签，这些标签将用于对工作负载进行分组。

在下面的虚拟服务 virtualservice 中，我们可以看到基于标签的动态分组的路由配置。 具体来说，服务网格可以从请求标头信息生成请求元数据，该信息包含目标工作负载的标签信息，并且可以与工作负载的分组相匹配。

在此演示中，我们将请求中以 x-model-format 开头的标头转换为请求元数据，并将其与 destinationrule 中声明的工作负载分组进行匹配，以查找应将请求发送到的组。

2. JSON HTTP - gRPC 请求转码能力

在实现动态子集路由的网格**之上，我们还配置了JSON到GRPC的转码能力。

目前，大多数模型推理服务器只实现 grpc 协议服务，对于依赖模型推理的业务服务，可能会使用 RESTful 方法实现服务之间的相互调用。 因此，当业务服务调用模型推理服务时，可能会出现协议不兼容的情况，导致调用困难。

通过在服务网格中配置 JSON 到 GRPC 的转码能力，以前只能通过 GRPC 协议访问的模型推理服务现在可以通过 HTTP 传输 JSON 数据来访问。

如图所示，我们只需要声明 grpc 服务的 proto 描述，集群中的网格就会为我们完成 JSON 数据从 RESTful 请求到 gRPC 请求体的动态转换，为集群中的服务调用增加了更大的灵活性，解决了调用协议的兼容性问题。

3. 基于用户身份的无边车流量路由能力

我们重点看调用链的前端，对于AI应用服务调用风格转移业务服务，我们也充分发挥了服务网格的能力，实现基于用户身份的流量分配。

对于这个业务服务，我们分别为 TensorFlow 和 Pytorch 这两个模型提供了不同的工作负载，分别命名为 style-transfer-tf 和 style-transfer-torch，它们负责将下游应用的传入 ** 作为模型可接受的张量进行处理，并将其交给依赖模型进行推理。 服务网格负责根据用户身份信息将下游传输的数据移交给不同的工作负载。

我们来看一下相关的配置，首先，我们使用目标规则将不同的工作负载分组到中台业务服务下。 然后，虚拟服务 virtualservice 会根据请求中的用户信息向不同的工作负载发送流量，并用不同的模型响应请求。 请求的用户信息是用户的 JWT 声明，由 OIDC 应用程序提供。

在本次 Demo 中，服务网格的使用完全基于 sidecarless 模式，以上能力是通过独立部署的网格 ** 航点实现的，即这些能力的实现不需要任何业务意识，可以大大提高服务网格的运维效率。

4. ASM网关集成OIDC应用，实现单点登录能力

最后，在整个呼叫链的最前面是 ASM 网关，它充当流量的入口。

该演示在ASM网关上实现与OIDC应用的快速对接，以配置单点登录。 本演示使用阿里云IDAS应用身份服务。 通过网关与 OIDC 应用对接，网关背后的应用可以完成对集群中应用的单点登录，获取用户身份，而无需自行实现身份认证。

如图所示，在Service Mesh ASM中，您可以通过完整的Web界面快速配置与现有OIDC应用的对接，可以大大降低单点登录系统的实施和运维成本，提高运维效率。

总结

最后，让我们简要总结一下。 在本次演示应用中，ASM可以根据服务调用链路上不同业务的特点和业务需求，灵活配置不同的流量路由和流量处理规则，快速完成应用的各种运维任务同时，这些能力的有效性也完全基于无边车模式，业务几乎察觉不到，服务网格进一步沉淀到应用的流量基础设施中。 ASM Ingress 网关作为业务入口，不仅满足基本的路由和安全能力，还提供丰富的生态集成、证书管理等增强能力，并辅以完整的 Web 界面，帮助用户快速配置。

您可以根据自己的需求选择使用服务网格的相应能力，让服务网格帮助您实现更多！更多产品功能请参考官方文档

相关链接：

1] 创建ASM实例。

2] Kubernetes 集群和配置要求。

3] 创建一个 Kubernetes 专用集群。

4] 创建一个 Kubernetes 托管集群。

5] 向 ASM 实例添加集群。

6] istio

7] ASM 集成了云原生推理服务框架 KSERVE

8] 管理全局命名空间。

9] 通过控制平面 kubectl 访问 Istio 资源。

10] 获取集群 kubeconfig，通过 kubectl 工具连接集群。

11] 创建入口网关。

12] ASM 控制台。

13] ASM 与阿里云 Idaas 集成，实现网格内应用的单点登录。

14] 官方文件。