osswangxining个人页面-阿里云开发者社区

如何使用 Istio 进行多集群部署管理(1): 单控制平面 VPN 连接拓扑

服务网格作为一个改善服务到服务通信的专用基础设施层，是云原生范畴中最热门的话题。随着容器愈加流行，服务拓扑也频繁变动，这就需要更好的网络性能。服务网格能够通过服务发现、路由、负载均衡、心跳检测和支持可观测性，帮助我们管理网络流量。服务网格试图为无规则的复杂的容器问题提供规范化的解决方案。服务网格也可以用于混沌工程 —— “一门在分布式系统上进行实验的学科，目的是构建能够应对极端条件的可靠系统”。服务网格能够将延迟和错误注入到环境中，而不需要在每个主机上安装一个守护进程。容器是云原生应用的基石，通过应用容器化，使得应用开发部署更加敏捷、迁移更加灵活，并且这些实现都是基于标准化的。而容器编排则是更近一步，能够更加有效地编排资源、更加高效地调度利用这些资源。而到了云原生时代，在 Kubernetes 基础架构之上，结合 Istio 服务网格，提供了多云、混合云的支持能力，针对微服务提供了有效的治理能力，并以 Kubernetes 和 Istio 为基础，提供了针对特定应用负载的不同支持，例如针对 Kubeflow 服务的流量治理、为 Knative 提供负载的路由管理能力等。尽管 Service Mesh 在云原生系统方面的应用已经有了快速的增长，但仍然存在巨大的提升空间。无服务器（Serverless）计算正好需要 Service Mesh 的命名和链接模型，这让 Service Mesh 在云原生生态系统中的角色得到了彰显。服务识别和访问策略在云原生环境中仍显初级，而 Service Mesh 毫无疑问将成为这方面不可或缺的基础。就像 TCP/IP 一样，Service Mesh 将在底层基础设施这条道路上更进一步。混合云可以采用多种形式。通常，混合云指的是跨公有云和私有（内部部署）云运行，而多云意味着跨多个公有云平台运行。采用混合云或多云架构可以为你的组织带来诸多好处。例如，使用多个云提供商可以帮助你避免供应商锁定，能够让你为实现目标选择最佳的云服务。使用云和本地环境，你可以同时享受云的优势（灵活性、可扩展性、成本降低）和本地的好处（安全性、低延迟、硬件复用）。如果你是首次迁移到云端，采用混合云步骤可以让你按照自己的节奏，以最适合你业务的方式进行。根据我们在公有云上的实践经验及从客户那里得到的信息，我们认为采用混合服务网络是简化云和本地环境中应用程序管理、安全性和可靠性的关键，无论你的应用程序是在容器中运行，或是在虚拟机中运行。 Istio 的一个关键特性是它为你的工作负载（例如 pod、job、基于 VM 的应用程序）提供服务抽象。当你转向混合拓扑时，这种服务抽象变得更加重要，因为现在你不只需要关注一个环境，而是需要关注若干个环境。当你在一个 Kubernetes 集群上使用 Istio 时，可以获得包括可见性、细粒度流量策略、统一遥测和安全性在内的微服务的所有管理优势。但是当你在多个环境中使用 Istio 时，实际上是为应用程序提供了一个新的超级能力。因为 Istio 不仅仅是 Kubernetes 的服务抽象，也是一种在整个环境中标准化网络的方法。它是一种集中 API 管理并将 JWT 验证与代码分离的方法。它是跨云提供商的安全、零信任网络的快速通道。那么所有这些魔法是如何发生的呢？混合 Istio 是指一组 Istio Sidecar 代理，每一个 Envoy 代理位于所有服务的旁边，而这些服务可能运行在不同环境中的每一个虚拟机、每一个容器中，而且这些 Sidecar 代理之前互相知道如何跨边界交互。这些 Envoy Sidecar 代理可能由一个中央 Istio 控制平面管理，或由每个环境中运行的多个控制平面管理。多集群部署管理服务网格本质上是将一组单独的微服务组合成单个可控的复合应用程序，Istio 作为一种服务网格，也是旨在单一管理域下监视和管理协作微服务网络。对于特定大小的应用程序，所有微服务是可以在单个编排平台如一个 Kubernetes 集群上运行的。然而，由于规模不断增大或者冗余等原因，大多数应用程序最终将需要分发一些服务在其他地方运行。社区越来越关注在多个集群上运行工作负载，以实现更好的扩展，故障可以更好地隔离，从而提升应用程序的敏捷性。Istio v1.0 开始支持一些多集群功能，并在之后的版本中添加了新功能。 Istio 服务网格支持许多可能的拓扑结构，用于在单个集群之外分发应用程序的服务，有两种常见的模式或用例：单网格和网格联合。顾名思义，单个网格将多个集群组合成一个单元，由一个 Istio 控制平面管理；它可以实现为一个物理控制平面，也可以实现为一组控制平面，同时所有控制平面都能通过复制配置保持同步。而网格联合则会将多个集群分离作为单独的管理域，有选择地完成集群之间的连接，仅将服务的子集暴露给其他集群；自然它的实现会包含多个控制平面。具体来说，这些不同的拓扑结构包括以下几个方面：网格中的服务可以使用服务条目（Service Entry）来访问独立的外部服务或访问由另一个松散耦合的服务网格公开的服务，通常称为网格联邦（Mesh Federation）。这种拓扑适合于互相独立并且网络隔离、只能通过公网交互的多集群的场景；支持在虚拟机或物理裸机上运行的服务进行服务网格扩展，通常称为网格联合（Mesh Expansion）。在前面章节中，我们已经讲述了这种 Kubernetes 集群与虚拟机、物理裸机之间混合部署的场景；把来自多个集群的服务组合到单个服务网格中，通常称为多集群网格（Multicluster Mesh）。根据网络拓扑结构的不同，多集群网格通常分为单控制平面 VPN 连接、单控制平面网关连接以及多控制平面拓扑。单控制平面 VPN 连接拓扑作为基准，在 Istio 的 1.1 版本之前，Istio 1.0 多集群仅支持使用单网格设计。它允许多个集群连接到网格中，但所有集群都在一个共享网络上。也就是说，所有集群中所有 pod 和服务的 IP 地址都是可直接路由的，不会发生冲突，同时保证在一个集群中分配的IP地址不会在另一个集群中同时重用。在这种拓扑配置下，在其中一个集群上运行单个 Istio 控制平面。该控制平面的 Pilot 管理本地和远程集群上的服务，并为所有集群配置 Envoy 代理。这种方法在所有参与集群都具有 VPN 连接的环境中效果最佳，因此可以使用相同的 IP 地址从其他任何地方访问网格中的每个 pod。在此配置中，Istio 控制平面部署在其中一个集群上，而所有其他集群运行更简单的远程 Istio 配置，该配置将它们连接到单个 Istio 控制平面，该平面将所有 Envoy 管理为单个网格。各个集群上的 IP 地址不允许重叠，并且远程集群上的服务的 DNS 解析不是自动的。用户需要在每个参与集群上复制服务，这样每个集群中的 Kubernetes 集群服务和应用程序都能够将其内部 Kubernetes 网络暴露给其他集群。一旦一个或多个远程 Kubernetes 集群连接到 Istio 控制平面，Envoy 就可以与单个控制平面通信并形成跨多个集群的网状网络。前提约束事实上，我们已经了解到网格、集群和网络之间的存在各种约束，例如，在某些环境中，网络和集群直接相关。Istio单网格设计下的单控制平面VPN连接拓扑需要满足以下几个条件：运行 Kubernetes 1.9 或更高版本的两个或更多集群；能够在其中一个集群上部署 Istio 控制平面； RFC1918 网络、VPN 或满足以下要求的更高级网络技术：单个集群 pod CIDR 范围和服务 CIDR 范围在多集群环境中必须是唯一的，并且应当不重叠；每个集群中的所有 pod CIDR 必须可以相互路由所有 Kubernetes 控制平面 API 服务器必须可以相互路由。此外，为了跨集群支持 DNS 名称解析，必须确保在所有需要跨集群服务调用的集群中定义对应的命名空间、服务和服务账户；例如，集群 cluster1 中命名空间 ns1 的服务 service1 需要调用集群 cluster2 中命名空间 ns2 的服务 service2，那么在集群 cluster1 中为了支持服务名的 DNS 解析，需要在集群 cluster1 中创建一个命名空间 ns2 以及该命名空间下的服务 service2。以下示例中的两个 Kubernetes 集群的网络假定已经满足上述要求，每个集群中的 pod 都能够互相路由，也就是说网络可通并且端口是可访问的（如果采用的是类似于阿里云的公有云服务，请确保这些端口在安全组规则下是可以访问的；否则服务间的调用会受到影响）。两个 Kubernetes 集群的 pod CIDR 范围和服务 CIDR 范围定义如下表所示：拓扑架构从图中可以看到整个多集群拓扑中只会在一个 Kubernetes 集群上安装 Istio 控制平面。这个安装 Istio 控制平面的集群通常被称为本地集群，所有其它集群称为远程集群。这些远程集群只需要安装 Istio 的 Citadel 和 Sidecar Injector 准入控制器，具有较小的 Istio 占用空间，Citadel 用于这些远程集群的安全管理，Sidecar Injector 准入控制器用于控制平面中的自动注入和数据平面中工作负载的 Sidecar 代理功能。在这个架构中，Pilot 可以访问所有集群中的所有 Kubernetes API 服务器，因此它具有全局网络访问视图。Citadel 和 Sidecar Injector 准入控制器则只会在集群本地范围内运行。每个集群都有唯一的 pod 和服务 CIDR，除此之外，集群之间还有一个共享的扁平网络，以保证能直接路由到任何工作负载，包括到 Istio 的控制平面。例如，远程集群上的 Envoy 代理需要从 Pilot 获得配置，检查并报告给 Mixer 等。启用双向 TLS 通信如果在多个集群中启用跨集群的双向 TLS 通信，就需要按照如下方式在各个集群中进行部署配置。首先，从共享的根 CA 为每个集群的 Citadel 生成中间 CA 证书，共享的根 CA 启用跨不同集群的双向 TLS 通信。为了便于说明，我们将 samples/certs 目录下 Istio 安装中提供的示例根 CA 证书用于两个集群。在实际部署中，你可能会为每个集群使用不同的 CA 证书，所有 CA 证书都由公共根 CA 签名。在每个 Kubernetes 集群中（包括示例中的集群 cluster1 与 cluster2）创建密钥。使用以下的命令为生成的 CA 证书创建 Kubernetes 密钥： kubectl create namespace istio-system kubectl create secret generic cacerts -n istio-system \ --from-file=samples/certs/ca-cert.pem \ --from-file=samples/certs/ca-key.pem \ --from-file=samples/certs/root-cert.pem \ --from-file=samples/certs/cert-chain.pem 当然，如果你的环境只是开发测试或者不需要启用双向 TLS 通信，上述步骤完全可以跳过。部署本地控制平面在所谓的本地集群上安装一个 Istio 控制平面的过程，与在单集群上安装 Istio 并没有太多差别，需要注意的一点是如何配置 Envoy 代理用于管理直接访问某个 IP 范围内的外部服务的参数。如果是使用 Helm 安装 Istio，那么在 Helm 中有一个名为 global.proxy.includeIPRanges 的变量，确保该变量为“*”或者包括本地集群、所有远程集群的 pod CIDR 范围和服务 CIDR。可以通过查看命名空间 istio-system 下的配置项 istio-sidecar-injector 中的 traffic.sidecar.istio.io/includeOutboundIPRanges 来确认 global.proxy.includeIPRanges 参数设置，如下所示： kubectl get configmap istio-sidecar-injector -n istio-system -o yaml| grep includeOutboundIPRanges 在部署 Istio 控制平面组件的集群 cluster1 中，按照以下步骤执行。如果启用了双向 TLS 通信，则需要如下配置参数： helm template --namespace=istio-system \ --values install/kubernetes/helm/istio/values.yaml \ --set global.mtls.enabled=true \ --set security.selfSigned=false \ --set global.controlPlaneSecurityEnabled=true \ install/kubernetes/helm/istio > istio-auth.yaml kubectl apply -f istio-auth.yaml 如果不需要启用双向 TLS 通信，配置参数则需要做出如下修改： helm template --namespace=istio-system \ --values install/kubernetes/helm/istio/values.yaml \ --set global.mtls.enabled=false \ --set security.selfSigned=true \ --set global.controlPlaneSecurityEnabled=false \ install/kubernetes/helm/istio > istio-noauth.yaml kubectl apply -f istio-noauth.yaml 修改 Istio 服务 istio-pilot、istio-telemetry、istio-policy 及 zipkin 的类型为内网负载均衡，将这些服务以内网方式暴露给远程集群使用。不同的云厂商实现机制不尽相同，但大都是通过修改 annotation 的方式实现。针对阿里云容器服务来说，设置为内网负载均衡的方式非常简单，只需要添加如下 annotation 到服务的 YAML 定义中即可：service.beta.kubernetes.io/alicloud-loadbalancer-address-type: intranet。此外，需要按照图中的端口定义为每一个服务进行设置。 istio-pilot 服务端口如表 1 所示。 istio-telemetry 服务端口如表 2 所示 istio-policy 服务端口如表 3 所示。 zipkin 服务端口如表 4 所示。安装 istio-remote 在本地集群中安装完控制平面之后，必须将 istio-remote 组件部署到每个远程 Kubernetes 集群。等待 Istio 控制平面完成初始化，然后再执行本节中的步骤。你必须在 Istio 控制平面集群上运行这些操作以捕获 Istio 控制平面服务端点，例如上述提到的 Istio 服务 istio-pilot、istio-telemetry、istio-policy 以及 zipkin。在远程集群 cluster2 中部署 Istio-remote 组件，按照以下步骤执行： 1.在本地集群上使用以下命令设置环境变量： export PILOT_IP=$(kubectl -n istio-system get service istio-pilot -o jsonpath='{.status.loadBalancer.ingress[0].ip}') export POLICY_IP=$(kubectl -n istio-system get service istio-policy -o jsonpath='{.status.loadBalancer.ingress[0].ip}') export TELEMETRY_IP=$(kubectl -n istio-system get service istio-telemetry -o jsonpath='{.status.loadBalancer.ingress[0].ip}') export ZIPKIN_IP=$(kubectl -n istio-system get service zipkin -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echo $PILOT_IP $POLICY_IP $TELEMETRY_IP $ZIPKIN_IP 2.如果在多个集群中启用跨集群的双向 TLS 通信，就需要在集群中进行部署配置。当然，如果你的环境只是开发测试或者不需要启用双向 TLS 通信的话，该步骤完全可以跳过。在远程 Kubernetes 集群 cluster2 上运行以下命令，在集群中为生成的 CA 证书创建 Kubernetes 密钥： kubectl create namespace istio-system kubectl create secret generic cacerts -n istio-system \ --from-file=samples/certs/ca-cert.pem \ --from-file=samples/certs/ca-key.pem \ --from-file=samples/certs/root-cert.pem \ --from-file=samples/certs/cert-chain.pem 3.在远程 Kubernetes 集群 cluster2 上，通过执行以下命令，使用 Helm 创建 Istio remote 部署 YAML 文件。如果启用了双向 TLS 通信，则需要如下配置参数： helm template install/kubernetes/helm/istio \ --name istio-remote \ --namespace istio-system \ --values install/kubernetes/helm/istio/values-istio-remote.yaml \ --set global.mtls.enabled=true \ --set security.selfSigned=false \ --set global.controlPlaneSecurityEnabled=true \ --set global.remotePilotCreateSvcEndpoint=true \ --set global.remotePilotAddress=${PILOT_IP} \ --set global.remotePolicyAddress=${POLICY_IP} \ --set global.remoteTelemetryAddress=${TELEMETRY_IP} --set global.remoteZipkinAddress=${ZIPKIN_IP} > istio-remote-auth.yaml 然后将 Istio remote 组件部署到 cluster2，如下所示： kubectl apply -f ./istio-remote-auth.yaml 如果不需要启用双向 TLS 通信，配置参数则需要做出如下修改： helm template install/kubernetes/helm/istio \ --name istio-remote \ --namespace istio-system \ --values install/kubernetes/helm/istio/values-istio-remote.yaml \ --set global.mtls.enabled=false \ --set security.selfSigned=true \ --set global.controlPlaneSecurityEnabled=false \ --set global.remotePilotCreateSvcEndpoint=true \ --set global.remotePilotAddress=${PILOT_IP} \ --set global.remotePolicyAddress=${POLICY_IP} \ --set global.remoteTelemetryAddress=${TELEMETRY_IP} --set global.remoteZipkinAddress=${ZIPKIN_IP} > istio-remote-noauth.yaml 然后将 Istio remote 组件部署到 cluster2，如下所示： kubectl apply -f ./istio-remote-noauth.yaml 确保上述步骤在 Kubernetes 集群中执行成功。 4.创建集群 cluster2 的 Kubeconfig。安装 Istio-remote Helm chart 后，在远程集群中创建了一个叫 istio-multi 的 Kubernetes 服务帐号，该服务帐号用于最小化 RBAC 访问请求，对应的集群角色定义如下： kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: istio-reader rules: - apiGroups: [''] resources: ['nodes', 'pods', 'services', 'endpoints'] verbs: ['get', 'watch', 'list'] 下面的过程通过使用先前所述的 istio-multi 服务帐号凭证生成一个远程集群的 kubeconfig 配置文件。通过以下命令，在集群 cluster2 上创建服务帐号 istio-multi 的 Kubeconfig，并保存为文件 n2-k8s-config： CLUSTER_NAME="cluster2" SERVER=$(kubectl config view --minify=true -o "jsonpath={.clusters[].cluster.server}") SECRET_NAME=$(kubectl get sa istio-multi -n istio-system -o jsonpath='{.secrets[].name}') CA_DATA=$(kubectl get secret ${SECRET_NAME} -n istio-system -o "jsonpath={.data['ca\.crt']}") TOKEN=$(kubectl get secret ${SECRET_NAME} -n istio-system -o "jsonpath={.data['token']}" | base64 --decode) cat <<EOF > n2-k8s-config apiVersion: v1 kind: Config clusters: - cluster: certificate-authority-data: ${CA_DATA} server: ${SERVER} name: ${CLUSTER_NAME} contexts: - context: cluster: ${CLUSTER_NAME} user: ${CLUSTER_NAME} name: ${CLUSTER_NAME} current-context: ${CLUSTER_NAME} users: - name: ${CLUSTER_NAME} user: token: ${TOKEN} EOF 5.将集群 cluster2 加入 Istio Pilot 所在集群中。在集群 dusterl 执行以下命令，将上述生成的集群 cluster2 的 kubeconfig 添加到集群 cluster1 的 secret 中。执行这些命令后，集群 cluster1 中的 Istio Pilot 将开始监听集群 cluster2 的服务和实例，就像监听集群 cluster1 中的服务与实例一样： kubectl create secret generic n2-k8s-secret --from-file n2-k8s-config -n istio-system kubectl label secret n2-k8s-secret istio/multiCluster=true -n istio-system 部署示例应用为了演示跨集群访问，在第一个 Kubernetes 集群 cluster1 中部署 sleep 应用服务和版本 v1 的 helloworld 服务，在第二个集群 cluster2 中部署版本 v2 的 helloworld 服务，然后验证 sleep 应用是否可以调用本地或者远程集群的 helloworld 服务。 1.部署 sleep 和版本 v1 的 helloworld 服务到第一个集群 cluster1 中，执行如下命令： kubectl create namespace app1 kubectl label namespace app1 istio-injection=enabled kubectl apply -n app1 -f multicluster/sleep/sleep.yaml kubectl apply -n app1 -f multicluster/helloworld/service.yaml kubectl apply -n app1 -f multicluster/helloworld/helloworld.yaml -l version=v1 export SLEEP_POD=$(kubectl get -n app1 pod -l app=sleep -o jsonpath={.items..metadata.name}) 部署版本 v2 的 helloworld 服务到第二个集群 cluster2 中，执行如下命令： kubectl create namespace app1 kubectl label namespace app1 istio-injection=enabled kubectl apply -n app1 -f multicluster/helloworld/service.yaml kubectl apply -n app1 -f multicluster/helloworld/helloworld.yaml -l version=v2 验证在集群 cluster1 中的 sleep 服务是否可以正常调用本地或者远程集群的 helloworld 服务，在集群 cluster1 下执行如下命令： kubectl exec $SLEEP_POD -n app1 -c sleep -- curl helloworld.app1:5000/hello 如果设置正确，则在返回的调用结果中可以看到两个版本的 helloworld 服务，同时可以通过查看 sleep 容器组中的 istio-proxy 容器日志来验证访问的端点 IP 地址，返回结果如下所示：验证 Istio 路由规则是否生效。创建针对上述两个版本的 helloworld 服务的路由规则，以便验证 Istio 配置是否可以正常工作。创建 Istio 虚拟服务 VirtualService，执行如下命令： kubectl apply -n app1 -f multicluster/helloworld/virtualservice.yaml 接着，创建 Istio 目标规则 DestinationRule：如果启用了双向 TLS 通信，则需要如下配置参数： kubectl apply -n app1 -f multicluster/helloworld/destinationrule.yaml 如果不需要启用双向 TLS 通信，配置参数则需要做出修改，在 YAML 定义中添加trafficPolicy.tls.mode:ISTIO_MUTUAL，定义如下所示： apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: helloworld spec: host: helloworld **trafficPolicy: tls: mode: ISTIO_MUTUAL** subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 通过执行命令 kubectl apply 创建启用双向 TLS 的 Istio 目标规则，如下所示： kubectl apply -n app1 -f multicluster/helloworld/destinationrule-auth.yaml 多次调用 helloworld 服务，只会返回版本 v2 的响应结果，如下所示：

Service Mesh 最火项目 Istio 架构解析

Istio 是一个开源的服务网格，可为分布式微服务架构提供所需的基础运行和管理要素。随着各组织越来越多地采用云平台，开发者必须使用微服务设计架构以实现可移植性，而运维人员必须管理包含混合云部署和多云部署的大型分布式应用。Istio 采用一种一致的方式来保护、连接和监控微服务，降低了管理微服务部署的复杂性。从架构设计上来看，Istio 服务网格在逻辑上分为控制平面和数据平面两部分。其中，控制平面 Pilot 负责管理和配置代理来路由流量，并配置 Mixer 以实施策略和收集遥测数据；数据平面由一组以 Sidecar 方式部署的智能代理（Envoy）组成，这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。作为代理，Envoy 非常适合服务网格的场景，但要发挥 Envoy 的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。Envoy 构成了服务网格的数据平面，Istio 提供的支撑组件则是创建了控制平面。一方面，我们在 Envoy 中看到，可以使用静态配置文件或使用一组发现服务来配置一组服务代理，以便在运行时发现监听器、端点和集群。Istio 在 Pilot 中实现了这些 Envoy 代理的 xDS API。另一方面，Envoy 的服务发现依赖于某种服务注册表来发现服务端点。Istio Pilot 实现了这个 API，但也将 Envoy 从任何特定的服务注册实现中抽象出来。当 Istio 部署在 Kubernetes 上时，Kubernetes 的服务注册表是 Istio 用于服务发现的。其它注册表也可以像 HashiCorp 的 Consul 那样使用。Envoy 数据平面完全不受这些实施细节的影响。此外，Envoy 代理可以发出很多指标和遥测数据，这些遥测数据发送到何处，取决于 Envoy 的配置。Istio 提供遥测接收器 Mixer 作为其控制平面的一部分，Envoy 代理可以将这些数据发送到 Mixer。Envoy 还将分布式跟踪数据发送到开放式跟踪引擎（遵循 Open Tracing API）。Istio 可以支持兼容的开放式跟踪引擎并配置 Envoy 将其跟踪数据发送到该位置。剖析 Istio 控制平面 Istio 的控制平面和 Envoy 的数据平面共同构成了一个引人注目的服务网格实现。两者都拥有蓬勃发展和充满活力的社区，并且面向下一代服务架构。Istio 是独立于平台的，可运行于各种环境中，包括跨云、内部部署、Kubernetes、Mesos 等。你可以在 Kubernetes 上部署 Istio 或在具有 Consul 的 Nomad 上部署。Istio 目前支持在 Kubernetes 上部署的服务、使用 Consul 注册的服务以及在虚拟机上部署的服务。其中，控制平面部分包括了 Pilot、Mixer、Citadel 和 Galley 四个组件。参见 Istio 架构一图。 1. Pilot Istio 的 Pilot 组件用于管理流量，可以控制服务之间的流量流动和 API 调用，通过 Pilot 可以更好地了解流量，以便在问题出现之前发现问题。这使得调用更加可靠、网络更加强健，即使遇到不利条件也能让应用稳如磐石。借助 Istio 的 Pilot，你能够配置熔断器、超时和重试等服务级属性，并设置常见的连续部署任务，如金丝雀发布、A/B 测试和基于百分比拆分流量的分阶段发布。Pilot 为 Envoy 代理提供服务发现功能，为智能路由和弹性能力（如超时、重试、熔断器等）提供流量管理功能。Pilot 将控制流量行为的高级路由规则转换为特定于 Envoy 代理的配置，并在运行时将它们传播到 Envoy。此外，Istio 提供了强大的开箱即用故障恢复功能，包括超时、支持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进行的定期主动运行状况检查，以及被动运行状况检查。 Pilot 将平台特定的服务发现机制抽象化并将其合成为标准格式，符合数据平面 API 的任何 Sidecar 都可以使用这种标准格式。这种松散耦合使得 Istio 能够在多种环境下运行（例如 Kubernetes、Consul、Nomad），同时可保持用于流量管理的操作界面相同。 2. Mixer Istio 的 Mixer 组件提供策略控制和遥测收集功能，将 Istio 的其余部分与各个后端基础设施后端的实现细节隔离开来。Mixer 是一个独立于平台的组件，负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。代理提取请求级属性，发送到 Mixer 进行评估。 Mixer 中包括一个灵活的插件模型，使其能够接入到各种主机环境和后端基础设施，从这些细节中抽象出 Envoy 代理和 Istio 管理的服务。利用 Mixer，你可以精细控制网格和后端基础设施后端之间的所有交互。与必须节省内存的 Sidecar 代理不同，Mixer 独立运行，因此它可以使用相当大的缓存和输出缓冲区，充当 Sidecar 的高度可伸缩且高度可用的二级缓存。 Mixer 旨在为每个实例提供高可用性。它的本地缓存和缓冲区可以减少延迟时间，还有助于屏蔽后端基础设施后端故障，即使后端没有响应也是如此。 3. Citadel Istio Citadel 安全功能提供强大的身份验证功能、强大的策略、透明的 TLS 加密以及用于保护服务和数据的身份验证、授权和审计（AAA）工具，Envoy 可以终止或向网格中的服务发起 TLS 流量。为此，Citadel 需要支持创建、签署和轮换证书。Istio Citadel 提供特定于应用程序的证书，可用于建立双向 TLS 以保护服务之间的流量。借助 Istio Citadel，确保只能从经过严格身份验证和授权的客户端访问包含敏感数据的服务。Citadel 通过内置身份和凭证管理提供了强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。Istio 的配置策略在服务器端配置平台身份验证，但不在客户端强制实施该策略，同时允许你指定服务的身份验证要求。Istio 的密钥管理系统可自动生成、分发、轮换与撤销密钥和证书。 Istio RBAC 为 Istio 网格中的服务提供命名空间级别、服务级别和方法级别的访问权限控制，包括易于使用的基于角色的语义、服务到服务和最终用户到服务的授权，并在角色和角色绑定方面提供灵活的自定义属性支持。 Istio 可以增强微服务及其通信（包括服务到服务和最终用户到服务的通信）的安全性，且不需要更改服务代码。它为每个服务提供基于角色的强大身份机制，以实现跨集群、跨云端的交互操作。 4. Galley Galley 用于验证用户编写的 Istio API 配置。随着时间的推移，Galley 将接管 Istio 获取配置、处理和分配组件的顶级责任。它负责将其他的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节中隔离开来。总而言之，通过 Pilot，Istio 可在部署规模逐步扩大的过程中帮助你简化流量管理。通过 Mixer，借助强健且易于使用的监控功能，能够快速有效地检测和修复问题。通过 Citadel，减轻安全负担，让开发者可以专注于其他关键任务。 Istio 的架构设计中有几个关键目标，这些目标对于系统应对大规模流量和高性能的服务处理至关重要。最大化透明度：要采用 Istio，应该让运维和开发人员只需付出很少的代价就可以从中获得实际价值。为此，Istio 将自身自动注入到服务间所有的网络路径中。Istio 使用 Envoy 代理来捕获流量，并且在可能的情况下自动对网络层进行编程，以便通过这些代理路由流量，而无需对已部署的应用程序代码进行太多的更改，甚至不需要任何更改。在 Kubernetes 中，Envoy 代理被注入到 pod 中，通过 iptables 规则来捕获流量。一旦注入 Envoy 代理到 pod 中并且修改路由规则，Istio 就能够调节所有流量。这个原则也适用于性能。当将 Istio 用于部署时，运维人员可以发现，为提供这些功能而增加的资源开销是很小的。所有组件和 API 在设计时都必须考虑性能和规模。可扩展性：随着运维人员和开发人员越来越依赖 Istio 提供的功能，系统必然和他们的需求一起成长。在我们继续添加新功能的同时，最需要的是能够扩展策略系统，集成其他策略和控制来源，并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外，它允许扩展词汇表，以允许基于网格生成的新信号来强制执行策略。可移植性：使用 Istio 的生态系统在很多方面都有所不同。Istio 必须能够以最少的代价运行在任何云或本地环境中。将基于 Istio 的服务移植到新环境应该是轻而易举的，而使用 Istio 将一个服务同时部署到多个环境中也是可行的，例如可以在混合云上部署以实现冗余灾备。策略一致性：策略应用于服务之间的 API 调用，可以很好地控制网格行为。但对于无需在 API 级别表达的资源来说，对资源应用策略也同样重要。例如，将配额应用到机器学习训练任务消耗的 CPU 数量上，比将配额应用到启动这个工作的调用上更为有用。因此，Istio 将策略系统维护为具有自己的 API 的独特服务，而不是将其放到代理中，这允许服务根据需要直接与其集成。剖析 Istio 数据平面当介绍服务网格的概念时，提到了服务代理的概念以及如何使用代理构建一个服务网格，以调节和控制微服务之间的所有网络通信。Istio 使用 Envoy 代理作为默认的开箱即用服务代理，这些 Envoy 代理与参与服务网格的所有应用程序实例一起运行，但不在同一个容器进程中，形成了服务网格的数据平面。只要应用程序想要与其他服务通信，就会通过服务代理 Envoy 进行。由此可见，Envoy 代理是数据平面和整个服务网格架构中的关键组成部分。 1. Envoy 代理 Envoy 最初是由 Lyft 开发的，用于解决构建分布式系统时出现的一些复杂的网络问题。它于 2016 年 9 月作为开源项目提供，一年后加入了云原生计算基金会（CNCF）。Envoy 是用 C++ 语言实现的，具有很高的性能，更重要的是，它在高负载运行时也非常稳定和可靠。网络对应用程序来说应该是透明的，当网络和应用程序出现问题时，应该很容易确定问题的根源。正是基于这样的一种设计理念，将 Envoy 设计为一个面向服务架构的七层代理和通信总线。为了更好地理解 Envoy，我们需要先搞清楚相关的几个基本术语：进程外（Out of Process）架构：Envoy 是一个独立进程，Envoy 之间形成一个透明的通信网格，每个应用程序发送消息到本地主机或从本地主机接收消息，但无需关心网络拓扑。单进程多线程模型：Envoy 使用了单进程多线程的架构模型。一个主线程管理各种琐碎的任务，而一些工作子线程则负责执行监听、过滤和转发功能。下游（Downstream）：连接到 Envoy 并发送请求、接收响应的主机叫下游主机，也就是说下游主机代表的是发送请求的主机。上游（Upstream）：与下游相对，接收请求的主机叫上游主机。监听器（Listener）：监听器是命名网络地址，包括端口、unix domain socket 等，可以被下游主机连接。Envoy 暴露一个或者多个监听器给下游主机连接。每个监听器都独立配置一些网络级别（即三层或四层）的过滤器。当监听器接收到新连接时，配置好的本地过滤器将被实例化，并开始处理后续事件。一般来说监听器架构用于执行绝大多数不同的代理任务，例如限速、TLS 客户端认证、HTTP 连接管理、MongoDB sniff?ing、原始 TCP 代理等。集群（Cluster）：集群是指 Envoy 连接的一组逻辑相同的上游主机。 xDS 协议：在 Envoy 中 xDS 协议代表的是多个发现服务协议，包括集群发现服务（CDS，Cluster Discovery Service）、监听器发现服务（LDS，Listener Discovery Service）、路由发现服务（RDS，Route Discovery Service）、端点发现服务（EDS，Endpoint Discovery Service），以及密钥发现服务（SDS，Secret Discovery Service）。 Envoy 代理有许多功能可用于服务间通信，例如，暴露一个或者多个监听器给下游主机连接，通过端口暴露给外部的应用程序；通过定义路由规则处理监听器中传输的流量，并将该流量定向到目标集群，等等。后续章节会进一步分析这几个发现服务在 Istio 中的角色和作用。在了解了 Envoy 的术语之后，你可能想尽快知道 Envoy 到底起到了什么作用？首先，Envoy 是一种代理，在网络体系架构中扮演着中介的角色，可以为网络中的流量管理添加额外的功能，包括提供安全性、隐私保护或策略等。在服务间调用的场景中，代理可以为客户端隐藏服务后端的拓扑细节，简化交互的复杂性，并保护后端服务不会过载。例如，后端服务实际上是运行的一组相同实例，每个实例能够处理一定量的负载。其次，Envoy 中的集群（Cluster）本质上是指 Envoy 连接到的逻辑上相同的一组上游主机。那么客户端如何知道在与后端服务交互时要使用哪个实例或 IP 地址？Envoy 作为代理起到了路由选择的作用，通过服务发现（SDS，Service Discovery Service），Envoy 代理发现集群中的所有成员，然后通过主动健康检查来确定集群成员的健康状态，并根据健康状态，通过负载均衡策略决定将请求路由到哪个集群成员。而在 Envoy 代理处理跨服务实例的负载均衡过程中，客户端不需要知道实际部署的任何细节。 2. Envoy 的启动配置 Envoy 目前提供了两个版本的 API，即 v1 和 v2，从 Envoy 1.5.0 起就有 v2 API 了，为了能够让用户顺利地向 v2 版本 API 迁移，Envoy 启动的时候设置了一个参数--v2-conf?ig-only。通过这个参数，可以明确指定 Envoy 使用 v2 API 的协议。幸运的是，v2 API 是 v1 的一个超集，兼容 v1 的 API。在当前的 Istio 1.0 之后的版本中，明确指定了其支持 v2 的 API。通过查看使用 Envoy 作为 Sidecar 代理的容器启动命令，可以看到如下类似的启动参数，其中指定了参数--v2-config-only： $ /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster ratings --service-node sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local --max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only 其中，参数 -c 表示的是基于版本 v2 的引导配置文件的路径，格式为 JSON，也支持其他格式，如 YAML、Proto3等。它会首先作为版本 v2 的引导配置文件进行解析，若解析失败，会根据 [--v2-conf?ig-only] 选项决定是否作为版本 v1 的 JSON 配置文件进行解析。其他参数解释如下，以便读者及时理解 Envoy 代理启动时的配置信息： restart-epoch 表示热重启周期，对于第一次启动默认为 0，每次热重启后都应该增加它。 service-cluster 定义 Envoy 运行的本地服务集群名称。 service-node 定义 Envoy 运行的本地服务节点名称。 drain-time-s 表示热重启期间 Envoy 将耗尽连接的时间（秒），默认为 600 秒（10 分钟）。通常耗尽时间应小于通过 --parent-shutdown-time-s 选项设置的父进程关闭时间。 parent-shutdown-time-s 表示 Envoy 在热重启时关闭父进程之前等待的时间（秒）。 max-obj-name-len 描述的是集群 cluster、路由配置 route_conf?ig 以及监听器 listener 中名称字段的最大长度，以字节为单位。此选项通常用于自动生成集群名称的场景，通常会超过 60 个字符的内部限制。默认为 60。 Envoy 的启动配置文件分为两种方式：静态配置和动态配置。具体表现为：静态配置是将所有信息都放在配置文件中，启动的时候直接加载。动态配置需要提供一个 Envoy 的服务端，用于动态生成 Envoy 需要的服务发现接口，也就是通常说的 xDS，通过发现服务来动态调整配置信息，Istio 实现了 v2 的 xDS API。 3. Envoy 静态与动态配置 Envoy 是由 JSON 或 YAML 格式的配置文件驱动的智能代理，对于已经熟悉 Envoy 或 Envoy 配置的用户来说，相信应该已经知道了 Envoy 的配置也有不同的版本。初始版本 v1 是 Envoy 启动时配置 Envoy 的原始方式。此版本已被弃用，以支持 Envoy 配置的 v2 版本。Envoy 的参考文档（https://www.envoyproxy.io/docs）还提供了明确区分 v1 和 v2 的文档。本文将只关注 v2 配置，因为它是最新的版本，也是 Istio 使用的版本。 Envoy 版本 v2 的配置 API 建立在 gRPC 之上，v2 API 的一个重要特性是可以在调用 API 时利用流功能来减少 Envoy 代理汇聚配置所需的时间。实际上，这也消除了轮询 API 的弊端，允许服务器将更新推送到 Envoy 代理，而不是定期轮询代理。 Envoy 的架构使得使用不同类型的配置管理方法成为可能。部署中采用的方法将取决于实现者的需求。简单部署可以通过全静态配置来实现，更复杂的部署可以递增地添加更复杂的动态配置。主要分为以下几种情况：全静态：在全静态配置中，实现者提供一组监听器和过滤器链、集群和可选的 HTTP 路由配置。动态主机发现仅能通过基于 DNS 的服务发现。配置重载必须通过内置的热重启机制进行。仅SDS/EDS：在静态配置之上，Envoy 可以通过该机制发现上游集群中的成员。 SDS/EDS 和 CDS：Envoy 可以通过该机制发现使用的上游集群。 SDS/EDS、CDS 和 RDS：RDS 可以在运行时发现用于 HTTP 连接管理器过滤器的整个路由配置。 SDS/EDS、CDS、RDS 和 LDS：LDS 可以在运行时发现整个监听器。这包括所有的过滤器堆栈，包括带有内嵌到 RDS 的应用的 HTTP 过滤器。静态配置我们可以使用 Envoy 的配置文件指定监听器、路由规则和集群。如下示例提供了一个非常简单的 Envoy 配置： static_resources: listeners: - name: httpbin-demo address: socket_address: { address: 0.0.0.0, port_value: 15001 } filter_chains: - filters: - name: envoy.http_connection_manager config: stat_prefix: egress_http route_config: name: httpbin_local_route virtual_hosts: - name: httpbin_local_service domains: ["*"] routes: - match: { prefix: "/" } route: auto_host_rewrite: true cluster: httpbin_service http_filters: - name: envoy.router clusters: - name: httpbin_service connect_timeout: 5s type: LOGICAL_DNS # Comment out the following line to test on v6 networks dns_lookup_family: V4_ONLY lb_policy: ROUND_ROBIN hosts: [{ socket_address: { address: httpbin, port_value: 8000 }}] 在这个简单的 Envoy 配置文件中，我们声明了一个监听器，它在端口 15001 上打开一个套接字并为其附加一个过滤器链。过滤器 http_connection_manager 在 Envoy 配置中使用路由指令（在此示例中看到的简单路由指令是匹配所有虚拟主机的通配符），并将所有流量路由到 httpbin_service 集群。配置的最后一部分定义了 httpbin_service 集群的连接属性。在此示例中，我们指定端点服务发现的类型为 LOGICAL_DNS、与上游 httpbin 服务通信时的负载均衡算法为 ROUND_ROBIN。这是一个简单的配置文件，用于创建监听器传入的流量，并将所有流量路由到 httpbin 集群。它还指定要使用的负载均衡算法的设置以及要使用的连接超时配置。你会注意到很多配置是明确指定的，例如指定了哪些监听器，路由规则是什么，我们可以路由到哪些集群等。这是完全静态配置文件的示例。有关这些参数更多信息的解释，请参阅 Envoy 的文档（www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns）。在前面的部分中，我们指出 Envoy 能够动态配置其各种设置。下面将介绍 Envoy 的动态配置以及 Envoy 如何使用 xDS API 进行动态配置。动态配置 Envoy 可以利用一组 API 进行配置更新，而无需任何停机或重启。Envoy 只需要一个简单的引导配置文件，该配置文件将配置指向正确的发现服务 API，其余动态配置。Envoy 进行动态配置的 API 通常统称为 xDS 服务，具体包括如下：监听器发现服务（LDS）：一种允许 Envoy 查询整个监听器的机制，通过调用该 API 可以动态添加、修改或删除已知监听器；每个监听器都必须具有唯一的名称。如果未提供名称，Envoy 将创建一个 UUID。路由发现服务（RDS）：Envoy 动态获取路由配置的机制，路由配置包括 HTTP 标头修改、虚拟主机以及每个虚拟主机中包含的单个路由规则。每个 HTTP 连接管理器都可以通过 API 独立地获取自身的路由配置。RDS 配置隶属于监听器发现服务 LDS 的一部分，是 LDS 的一个子集，用于指定何时应使用静态和动态配置，以及指定使用哪个路由。集群发现服务（CDS）：一个可选的 API，Envoy 将调用该 API 来动态获取集群管理成员。Envoy 还将根据 API 响应协调集群管理，根据需要添加、修改或删除已知的集群。在 Envoy 配置中静态定义的任何集群都不能通过 CDS API 进行修改或删除。端点发现服务（EDS）：一种允许 Envoy 获取集群成员的机制，基于 gRPC 或 RESTJSON 的 API，它是 CDS 的一个子集；集群成员在 Envoy 术语中称为端点（Endpoint）。对于每个集群，Envoy 从发现服务获取端点。EDS 是首选的服务发现机制。密钥发现服务（SDS）：用于分发证书的 API；SDS 最重要的好处是简化证书管理。如果没有此功能，在 Kubernetes 部署中，必须将证书创建为密钥并挂载到 Envoy 代理容器中。如果证书过期，则需要更新密钥并且需要重新部署代理容器。使用密钥发现服务 SDS，那么 SDS 服务器会将证书推送到所有 Envoy 实例。如果证书过期，服务器只需将新证书推送到 Envoy 实例，Envoy 将立即使用新证书而无需重新部署。聚合发现服务（ADS）：上述其他 API 的所有更改的序列化流；你可以使用此单个 API 按顺序获取所有更改；ADS 并不是一个实际意义上的 xDS，它提供了一个汇聚的功能，在需要多个同步 xDS 访问的时候，ADS 可以在一个流中完成。配置可以使用上述服务中的一个或其中几个的组合，不必全部使用它们。需要注意的一点是，Envoy 的 xDS API 是建立在最终一致性的前提下，正确的配置最终会收敛。例如，Envoy 最终可能会使用新路由获取RDS的更新，该路由将流量路由到尚未在 CDS 中更新的集群。这意味着，路由可能会引入路由错误，直到更新 CDS。Envoy 引入了聚合发现服务 ADS 来解决这种问题，而 Istio 实现了聚合发现服务 ADS，并使用 ADS 进行代理配置的更改。例如，Envoy 代理要动态发现监听器，可以使用如下配置： dynamic_resources: lds_config: api_config_source: api_type: GRPC grpc_services: - envoy_grpc: cluster_name: xds_cluster clusters: - name: xds_cluster connect_timeout: 0.25s type: STATIC lb_policy: ROUND_ROBIN http2_protocol_options: {} hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}] 通过上面的配置，我们不需要在配置文件中显式配置每个监听器。我们告诉 Envoy 使用 LDS API 在运行时发现正确的监听器配置值。但是，我们需要明确配置一个集群，这个集群就是 LDS API 所在的位置，也就是该示例中定义的集群 xds_cluster。在静态配置的基础上，比较直观地表示出各个发现服务所提供的信息。在静态配置的基础上，比较直观地表示出各个发现服务所提供的信息。本文摘自于《Istio 服务网格解析与实战》，经出版方授权发布。本书由阿里云高级技术专家王夕宁撰写，详细介绍 Istio 的基本原理与开发实战，包含大量精选案例和参考代码可以下载，可快速入门 Istio 开发。Gartner 认为，2020 年服务网格将成为所有领先的容器管理系统的标配技术。本书适合所有对微服务和云原生感兴趣的读者，推荐大家对本书进行深入的阅读。

osswangxining个人页面-阿里云开发者社区

个人介绍

擅长的技术

如何使用 Istio 进行多集群部署管理(2): 单控制平面 Gateway 连接拓扑

如何使用 Istio 进行多集群部署管理(1): 单控制平面 VPN 连接拓扑

Service Mesh 最火项目 Istio 架构解析

阿里云服务网格ASM之多集群管理：同 VPC下的多个集群

阿里云服务网格ASM之扩展能力(4)：在ASM中实现分布式跟踪

如何使用 Istio 进行多集群部署管理(2): 单控制平面 Gateway 连接拓扑

如何使用 Istio 进行多集群部署管理(1): 单控制平面 VPN 连接拓扑

Service Mesh 最火项目 Istio 架构解析

阿里云服务网格ASM之多集群管理：同 VPC下的多个集群

阿里云服务网格ASM之扩展能力(4)：在ASM中实现分布式跟踪

阿里云服务网格ASM之扩展能力(3)：在ASM中使用开放策略代理OPA

阿里云服务网格ASM之扩展能力(2)：在ASM中支持自定义外部授权

阿里云服务网格ASM之扩展能力(1)：在ASM中通过EnvoyFilter添加HTTP请求头

阿里云服务网格ASM公测来袭系列之六：在ASM中为应用定义路由规则

阿里云服务网格ASM公测来袭系列之五：部署应用到ASM的数据面集群中

阿里云服务网格ASM公测来袭系列之四：添加入口网关

阿里云服务网格ASM公测来袭系列之三：添加一个ACK集群到 服务网格ASM 实例

阿里云服务网格ASM公测来袭系列之二：快速创建一个服务网格ASM 实例

阿里云服务网格ASM公测来袭系列之一：快速了解什么是ASM

多云混合云之多集群统一管理：基于阿里云ACK统一纳管多个不同Kubernetes集群

Istio on ACK集成生态(2): 扩展AlertManager集成钉钉助力可观测性监控能力

如何使用 Istio 进行多集群部署管理(2): 单控制平面 Gateway 连接拓扑

如何使用 Istio 进行多集群部署管理(1): 单控制平面 VPN 连接拓扑

Service Mesh 最火项目 Istio 架构解析

阿里云服务网格ASM之多集群管理：同 VPC下的多个集群

阿里云服务网格ASM之扩展能力(4)：在ASM中实现分布式跟踪

阿里云服务网格ASM之扩展能力(3)：在ASM中使用开放策略代理OPA

阿里云服务网格ASM之扩展能力(2)：在ASM中支持自定义外部授权

阿里云服务网格ASM之扩展能力(1)：在ASM中通过EnvoyFilter添加HTTP请求头

阿里云服务网格ASM公测来袭系列之六：在ASM中为应用定义路由规则

阿里云服务网格ASM公测来袭系列之五：部署应用到ASM的数据面集群中

阿里云服务网格ASM公测来袭系列之四：添加入口网关

阿里云服务网格ASM公测来袭系列之三：添加一个ACK集群到 服务网格ASM 实例

阿里云服务网格ASM公测来袭系列之二：快速创建一个服务网格ASM 实例

阿里云服务网格ASM公测来袭系列之一：快速了解什么是ASM

阿里云服务网格ASM公测来袭！

多云混合云之多集群统一管理：基于阿里云ACK统一纳管多个不同Kubernetes集群

扩展AlertManager集成钉钉助力Istio on ACK可观测性监控能力

Istio on ACK集成生态(2): 扩展AlertManager集成钉钉助力可观测性监控能力

Istio on ACK集成生态(1): 集成TSDB助力可观测性存储

阿里云Kubernetes容器服务上体验Knative

阿里云服务网格ASM公测来袭系列之三：添加一个ACK集群到服务网格ASM 实例

阿里云服务网格ASM公测来袭系列之三：添加一个ACK集群到服务网格ASM 实例