作者：尹航。
在 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.0kubectl 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/modelspytorchtensorflow使用以下命令建立 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-demoapiversion: 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: clusteripkubectl 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-demokubectl get deploy -n apsara-demoname 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.yamlapiversion: 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] 官方檔案。