3、Istio流量管理 <a class="header-anchor" href="#_3、istio流量管理" aria-label="Permalink to &quot;3、Istio流量管理&quot;">​

Istio 使用 VirtualService来定义路由规则，只需要应用下面的资源对象即可：

应用规则

该资源清单中定义了四个 VirtualService对象，分别是 productpage、reviews、ratings、details，它们分别对应着 Bookinfo应用中的四个微服务，完整的清单如下所示：

$kubectlapply-fsamples/bookinfo/networking/virtual-service-all-v1.yamlvirtualservice.networking.istio.io/productpagecreatedvirtualservice.networking.istio.io/reviewscreatedvirtualservice.networking.istio.io/ratingscreatedvirtualservice.networking.istio.io/detailscreated

我们可以看到这里的 VirtualService对象中都定义了 subset字段，这个字段就是用来指定微服务的版本的，这里我们将所有的微服务都指定为 v1版本，这样所有的流量都会被路由到 v1版本的微服务中，包括 reviews服务，这样我们就不会再看到星级评分了。

# virtual-service-all-v1.yamlapiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:productpagespec:hosts:- productpagehttp:- route:- destination:host:productpagesubset:v1---apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:reviewsspec:hosts:- reviewshttp:- route:- destination:host:reviewssubset:v1---apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:ratingsspec:hosts:- ratingshttp:- route:- destination:host:ratingssubset:v1---apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:detailsspec:hosts:- detailshttp:- route:- destination:host:detailssubset:v1---

但是如果我们现在直接去访问 Bookinfo应用的话，是不能正常访问的，因为我们压根就还没指定这些 v1版本的微服务到底在哪里。

这个时候就需要用到另外一个资源对象 DestinationRule了，我们需要为每个微服务创建一个 DestinationRule对象，用来指定这些微服务的实际地址，这样 VirtualService对象才能将流量路由到这些微服务中。Istio 在 DestinationRule目标规则中使用 subsets定义服务的版本，运行以下命令为 Bookinfo服务创建默认的目标规则即可：

该资源清单中定义了四个 DestinationRule对象，分别是 productpage、reviews、ratings、details几个服务的目标规则，它们分别对应着 Bookinfo应用中的四个微服务，完整的清单如下所示：

$kubectlapply-fsamples/bookinfo/networking/destination-rule-all.yamldestinationrule.networking.istio.io/productpagecreateddestinationrule.networking.istio.io/reviewscreateddestinationrule.networking.istio.io/ratingscreateddestinationrule.networking.istio.io/detailscreated

# destination-rule-all.yamlapiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:productpagespec:host:productpagesubsets:- name:v1labels:version:v1---apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:reviewsspec:host:reviewssubsets:- name:v1labels:version:v1- name:v2labels:version:v2- name:v3labels:version:v3---apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:ratingsspec:host:ratingssubsets:- name:v1labels:version:v1- name:v2labels:version:v2- name:v2-mysqllabels:version:v2-mysql- name:v2-mysql-vmlabels:version:v2-mysql-vm---apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:detailsspec:host:detailssubsets:- name:v1labels:version:v1- name:v2labels:version:v2---

现在我们就可以正常访问 Bookinfo 应用了，并且无论刷新多少次，页面的评论部分都不会显示评级星标，这是因为我们将 Istio 配置为将 reviews 服务的所有流量路由到版本 reviews:v1，而此版本的服务不访问星级评分服务。

这样我们就成功将流量路由到服务的某一个版本上了。

原理分析

前面章节中我们只定义了一个名为 bookinfo的 VirtualService资源对象就可以正常访问了：

链接：https:A[实战步骤] -->B(1️⃣ 更新VirtualService)A[实战步骤] -->C(2️⃣ 测试)

apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:bookinfonamespace:defaultspec:gateways:- bookinfo-gatewayhosts:- "*"http:- match:- uri:exact:/productpage- uri:prefix:/static- uri:exact:/login- uri:exact:/logout- uri:prefix:/api/v1/productsroute:- destination:host:productpageport:number:9080

很明显上面这个虚拟服务对象是我们访问 Bookinfo 应用的入口路由规则，所以这个虚拟服务对象实际上是为 istio-ingressgateway入口网关服务定义的。它将所有的流量都路由到了 productpage这个服务上，而 productpage这个服务又会去调用其他的服务来获取数据，在 productpage服务中调用其他微服务其实就是直接通过服务名称来调用的，比如调用 reviews服务就是直接通过 reviews:9080这个服务来调用的，我们可以查看 productpage的代码来验证这一点：

🍀

我们可以再次查看 Bookinfo 在网格内的请求架构图：

当我们在浏览器中访问 http:kind:VirtualServicemetadata:name:reviewsspec:hosts:- reviewshttp:- route:- destination:host:reviewssubset:v1---apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:reviewsspec:host:reviewssubsets:- name:v1labels:version:v1- name:v2labels:version:v2- name:v3labels:version:v3

那么这两个对象是如何来影响 Envoy Sidecar 的呢？前面我们已经分析了流量从 istio-ingressgateway进来后被路由到了 productpage服务，那么 productpage又该如何去访问其他微服务呢？同样我们可以使用 istioctl proxy-config来查看 productpage服务的 Envoy 配置。

🍀

每个 Envoy Sidecar 都有一个绑定到 0.0.0.0:15001的监听器，然后利用 IP tables 将 pod 的所有入站和出站流量路由到这里，此监听器会配置一个 useOriginalDst:true，这意味着它将请求交给最符合请求原始目标的监听器。如果找不到任何匹配的虚拟监听器，它会将请求发送给返回 404 的 BlackHoleCluster，我们可以查看下 15001 端口的监听器配置：

yaml

[root@master1 istio-1.19.3]#istioctl proxy-config listeners productpage-v1-564d4686f-7vhks --port 15001 -oyaml- accessLog:- filter:responseFlagFilter:flags:- NRname:envoy.access_loggers.filetypedConfig:'@type':type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLoglogFormat:textFormatSource:inlineString:|[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"%RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% "%UPSTREAM_TRANSPORT_FAILURE_REASON%"%BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%""%REQ(USER-AGENT)%""%REQ(X-REQUEST-ID)%""%REQ(:AUTHORITY)%""%UPSTREAM_HOST%"%UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%path:/dev/stdoutaddress:socketAddress:address:0.0.0.0portValue:15001filterChains:- filterChainMatch:destinationPort:15001filters:- name:istio.statstypedConfig:'@type':type.googleapis.com/stats.PluginConfig- name:envoy.filters.network.tcp_proxytypedConfig:'@type':type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxycluster:BlackHoleClusterstatPrefix:BlackHoleClustername:virtualOutbound-blackhole- filters:- name:istio.statstypedConfig:'@type':type.googleapis.com/stats.PluginConfig- name:envoy.filters.network.tcp_proxytypedConfig:'@type':type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxyaccessLog:- name:envoy.access_loggers.filetypedConfig:'@type':type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLoglogFormat:textFormatSource:inlineString:|[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"%RESPONSE_CODE% %RESPONSE_FLAGS% %RESPONSE_CODE_DETAILS% %CONNECTION_TERMINATION_DETAILS% "%UPSTREAM_TRANSPORT_FAILURE_REASON%"%BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%""%REQ(USER-AGENT)%""%REQ(X-REQUEST-ID)%""%REQ(:AUTHORITY)%""%UPSTREAM_HOST%"%UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%path:/dev/stdoutcluster:PassthroughClusterstatPrefix:PassthroughClustername:virtualOutbound-catchall-tcpname:virtualOutboundtrafficDirection:OUTBOUNDuseOriginalDst:true[root@master1 istio-1.19.3]#

🍀

实际上我们的请求是到 9080 端口（productpage 服务绑定 9080 端口）的 HTTP 出站请求，这意味着它被切换到 0.0.0.0:9080虚拟监听器。所以我们查看下 9080 端口的监听器配置：

bash

# productpage 默认访问其他服务的 9080 端口$istioctlproxy-configlistenersproductpage-v1-564d4686f-wwqqf--port9080-oyaml-address:socketAddress:address:0.0.0.0portValue:9080# ......rds:configSource:ads:{}initialFetchTimeout:0sresourceApiVersion:V3routeConfigName:"9080"# RDS的路由配置名称# ......name:0.0.0.0_9080trafficDirection:OUTBOUND# 出流量

可以看到此监听器在其配置的 RDS 中查找名为 9080的路由配置，我们可以使用 istioctl proxy-config routes命令来查看这个路由配置的详细信息：

bash

# 查看 9080 这个路由配置$istioctlproxy-configroutesproductpage-v1-564d4686f-wwqqf--name9080-oyaml-name:"9080"virtualHosts:-domains:-details.default.svc.cluster.local-details-details.default.svc-details.default-10.111.83.224name:details.default.svc.cluster.local:9080routes:-decorator:operation:details.default.svc.cluster.local:9080/*match:prefix:/metadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/detailsroute:cluster:outbound|9080|v1|details.default.svc.cluster.local# ......-domains:-productpage.default.svc.cluster.local-productpage-productpage.default.svc-productpage.default-10.97.120.23name:productpage.default.svc.cluster.local:9080routes:-decorator:operation:productpage.default.svc.cluster.local:9080/*match:prefix:/name:defaultroute:cluster:outbound|9080||productpage.default.svc.cluster.local# ......-domains:-ratings.default.svc.cluster.local-ratings-ratings.default.svc-ratings.default-10.101.184.235name:ratings.default.svc.cluster.local:9080routes:-decorator:operation:ratings.default.svc.cluster.local:9080/*match:prefix:/metadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/ratingsroute:cluster:outbound|9080|v1|ratings.default.svc.cluster.local# ......-domains:-reviews.default.svc.cluster.local-reviews-reviews.default.svc-reviews.default-10.97.120.56name:reviews.default.svc.cluster.local:9080routes:-decorator:operation:reviews.default.svc.cluster.local:9080/*match:prefix:/metadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviewsroute:cluster:outbound|9080|v1|reviews.default.svc.cluster.local# ......-domains:-'*'name:allow_anyroutes:-match:prefix:/name:allow_anyroute:cluster:PassthroughCluster# ......

这个路由配置中其实包含了 K8s Service 对象中监听 9080 端口的所有服务，如果没有创建对应的 VirtualService对象，对应的路由配置就没有 metadata.filterMetadata.istio.config这个属性。比如现在我们正在通过 productpage请求前往 reviews服务，因此 Envoy 将选择我们的请求与域匹配的虚拟主机。一旦在域上匹配，Envoy 会查找与请求匹配的第一条路径，我们这里没有任何高级路由，因此只有一条路由匹配所有内容。这条路由告诉 Envoy 将请求发送到 outbound|9080|v1|reviews.default.svc.cluster.local集群，因为前面我们创建的 reviews这个 VirtualService对象配置了的 destination.subset:v1，所以这里的集群命名上多了一个 subset。

需要注意的是我们在 VirtualService对象里面配置了 destination.subset:v1，那么必须要有对应的 subset存在才行，否则不会生成对应的 Envoy 集群配置，那么就不能正常访问该服务了，而该 subset就是通过前面的 DestinationRule对象来定义的，现在我们就可以来查看这个集群配置了：

bash

$istioctlproxy-configclusterproductpage-v1-564d4686f-wwqqf--fqdnreviews.default.svc.cluster.local-oyaml-edsClusterConfig:edsConfig:ads:{}initialFetchTimeout:0sresourceApiVersion:V3serviceName:outbound|9080||reviews.default.svc.cluster.locallbPolicy:LEAST_REQUESTmetadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviewsservices:-host:reviews.default.svc.cluster.localname:reviewsnamespace:default# ......name:outbound|9080||reviews.default.svc.cluster.localtype:EDS-edsClusterConfig:edsConfig:ads:{}initialFetchTimeout:0sresourceApiVersion:V3serviceName:outbound|9080|v1|reviews.default.svc.cluster.locallbPolicy:LEAST_REQUESTmetadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviewsservices:-host:reviews.default.svc.cluster.localname:reviewsnamespace:defaultsubset:v1name:outbound|9080|v1|reviews.default.svc.cluster.local# ......type:EDS-edsClusterConfig:edsConfig:ads:{}initialFetchTimeout:0sresourceApiVersion:V3serviceName:outbound|9080|v2|reviews.default.svc.cluster.localfilters:-name:istio.metadata_exchangetypedConfig:'@type':type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchangeprotocol:istio-peer-exchangelbPolicy:LEAST_REQUESTmetadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviewsservices:-host:reviews.default.svc.cluster.localname:reviewsnamespace:defaultsubset:v2name:outbound|9080|v2|reviews.default.svc.cluster.local# ......type:EDS-edsClusterConfig:edsConfig:ads:{}initialFetchTimeout:0sresourceApiVersion:V3serviceName:outbound|9080|v3|reviews.default.svc.cluster.localfilters:-name:istio.metadata_exchangetypedConfig:'@type':type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchangeprotocol:istio-peer-exchangelbPolicy:LEAST_REQUESTmetadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/destination-rule/reviewsservices:-host:reviews.default.svc.cluster.localname:reviewsnamespace:defaultsubset:v3name:outbound|9080|v3|reviews.default.svc.cluster.local# ......type:EDS

从上面配置可以看到里面一共包含了 4 个 reviews相关的集群，一个是原始的不包含 subset 的，而另外三个就是前面我们在 DestinationRule对象中配置的 3 个 subset，所以其实 DestinationRule 映射到 Envoy 的配置文件中就是 Cluster。

🍀

最后我们同样还可以查看每个集群下面包含的 endpoint 有哪些：

bash

$istioctlproxy-configendpointproductpage-v1-564d4686f-wwqqf--cluster"outbound|9080||reviews.default.svc.cluster.local"-oyaml-edsServiceName:outbound|9080||reviews.default.svc.cluster.local-address:socketAddress:address:10.244.2.84portValue:9080# ......weight:1-address:socketAddress:address:10.244.2.83portValue:9080# ......weight:1-address:socketAddress:address:10.244.2.88portValue:9080# ......weight:1name:outbound|9080||reviews.default.svc.cluster.localobservabilityName:outbound|9080||reviews.default.svc.cluster.local$istioctlproxy-configendpointproductpage-v1-564d4686f-wwqqf--cluster"outbound|9080|v1|reviews.default.svc.cluster.local"-oyaml-edsServiceName:outbound|9080|v1|reviews.default.svc.cluster.localhostStatuses:-address:socketAddress:address:10.244.2.84portValue:9080weight:1name:outbound|9080|v1|reviews.default.svc.cluster.localobservabilityName:outbound|9080|v1|reviews.default.svc.cluster.local# 过滤 version=v1 的 reviews pod$kubectlgetpod-lapp=reviews,version=v1-owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATEDNODEREADINESSGATESreviews-v1-86896b7648-zjh2n2/2Running4(5h18m ago) 6d17h 10.244.2.84 node2 <none><none>

可以看到不包含 subset 的集群下面的 endpoint 其实就是 reviews这个 Service 对象的 endpoint 集合，包含 subset 就只有和该子集匹配的后端实例了。到了这一步，一切皆明了，后面的事情就跟之前的套路一样了，具体的 Endpoint 对应打了标签 version=v1的 Pod。

🍀

到这里我们是不是就实现了通过 VirtualService和 DestinationRule对象将流量路由到了指定的版本上面了，上面的整个过程就是请求从 productpage 到 reviews 的过程，从 reviews 到网格内其他应用的流量与上面类似，就不展开讨论了。

2.基于用户身份的路由

==🚩 实战：基于用户身份的路由-2023.11.11(测试成功)==

实验环境：

bash

k8sv1.27.6（containerd:[root@master1 ~]#istioctl versionclientversion:1.19.3controlplaneversion:1.19.3dataplaneversion:1.19.3(8 proxies)

实验软件：

接下来我们继续更改路由配置，将来自特定用户的所有流量路由到特定服务版本。我们这里将配置来自名为 Jason的用户的所有流量被路由到服务 reviews:v2。

注意 Istio 对用户身份没有任何特殊的内置机制，productpage服务在所有到 reviews服务的 HTTP 请求中都增加了一个自定义的 end-user请求头来实现该效果：headers['end-user'] =session['user']。

要实现该功能，只需要创建下面的资源对象即可：

该资源清单文件创建了一个如下所示的 VirtualService资源对象：

$kubectlapply-fsamples/bookinfo/networking/virtual-service-reviews-test-v2.yamlvirtualservice.networking.istio.io/reviewsconfigured

该对象设置了一条路由规则，它会根据 productpage 服务发起的请求的 end-user自定义请求头内容进行匹配，如果有该内容且为 jason则会将流量路由到 reviews服务的 v2版本，其余的还是被路由到 v1版本去。

# virtual-service-reviews-test-v2.yamlapiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:reviewsspec:hosts:- reviewshttp:- match:- headers:end-user:exact:jasonroute:- destination:host:reviewssubset:v2- route:- destination:host:reviewssubset:v1

现在我们可以前往浏览器访问 Bookinfo 应用，多刷新几次可以看到评论始终访问到的是 v1版本的服务，即没有星标的：

然后我们点击页面右上角的 Sign in按钮，使用 jason进行登录，登录后页面就会出现带有黑色星标的 v2版本的评论服务，即使多刷新几次依然如此：

如果我们选择使用其他用户进行登录或者注销则星标就会消失，这是因为除了 Jason之外，所有用户的流量都被路由到 reviews:v1。

同样的我们可以去查看下对应的 Envoy Sidecar 配置的变化，因为这里我们只更新了一个 VirtualService对象，所以只会对 Envoy 的路由表产生影响，查看对应的路由配置即可：

从配置上我们可以看到现在的 Envoy 配置中新增了一条路由规则，如下所示：

$istioctlproxy-configroutesproductpage-v1-564d4686f-wwqqf--name9080-oyaml-name:"9080"validateClusters:falsevirtualHosts:# ......-domains:-reviews.default.svc.cluster.local-reviews-reviews.default.svc-reviews.default-10.97.120.56includeRequestAttemptCount:truename:reviews.default.svc.cluster.local:9080routes:-decorator:operation:reviews.default.svc.cluster.local:9080/*match:caseSensitive:trueheaders:-name:end-userstringMatch:exact:jasonprefix:/metadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviewsroute:cluster:outbound|9080|v2|reviews.default.svc.cluster.localmaxGrpcTimeout:0s# ......-decorator:operation:reviews.default.svc.cluster.local:9080/*match:prefix:/metadata:filterMetadata:istio:config:/apis/networking.istio.io/v1alpha3/namespaces/default/virtual-service/reviewsroute:cluster:outbound|9080|v1|reviews.default.svc.cluster.localmaxGrpcTimeout:0s# ......

当请求头中包含 end-user：jason的时候请求会被路由到 outbound|9080|v2|reviews.default.svc.cluster.local这个 Envoy Cluster 集群，这个集群就是前面我们通过 DestinationRule创建的 v2这个子集，所以最后请求会被路由到带有黑色星标的评论服务去。

match:caseSensitive:trueheaders:- name:end-userstringMatch:exact:jasonprefix:/route:cluster:outbound|9080|v2|reviews.default.svc.cluster.local