istio使用教程和示例（导流，请求路由，访问拒绝，黑白名单，限速）

进大厂,身价翻倍的法宝来了!

主讲内容：docker/kubernetes 云原生技术，大数据架构，分布式微服务，自动化测试、运维。

视频地址：ke.qq.com/course/419718

---

全栈工程师开发手册 （作者：栾鹏）
架构系列文章

Istio 对 Pod 和服务的要求

要成为服务网格的一部分，Kubernetes 集群中的 Pod 和服务必须满足以下几个要求：

需要给端口正确命名：服务端口必须进行命名。端口名称只允许是<协议>[-<后缀>-]模式，其中<协议>部分可选择范围包括 http、http2、grpc、mongo 以及 redis，Istio 可以通过对这些协议的支持来提供路由能力。例如 name: http2-foo 和 name: http 都是有效的端口名，但 name: http2foo 就是无效的。如果没有给端口进行命名，或者命名没有使用指定前缀，那么这一端口的流量就会被视为普通 TCP 流量（除非显式的用 Protocol: UDP 声明该端口是 UDP 端口）。

关联服务：Pod 必须关联到 Kubernetes 服务，如果一个 Pod 属于多个服务，这些服务不能在同一端口上使用不同协议，例如 HTTP 和 TCP。

Deployment 应带有 app 以及 version 标签：在使用 Kubernetes Deployment 进行 Pod 部署的时候，建议显式的为 Deployment 加上 app 以及 version 标签。每个 Deployment 都应该有一个有意义的 app 标签和一个用于标识 Deployment 版本的 version 标签。app 标签在分布式跟踪的过程中会被用来加入上下文信息。Istio 还会用 app 和 version 标签来给遥测指标数据加入上下文信息。

自动边车注入

理解原理

被 Kubernetes 调用时，admissionregistration.k8s.io/v1beta1#MutatingWebhookConfiguration 会进行配置。Istio 提供的缺省配置，会在带有 istio-injection=enabled 标签的命名空间中选择 Pod。使用 kubectl edit mutatingwebhookconfiguration istio-sidecar-injector 命令可以编辑目标命名空间的范围。

注意：修改 mutatingwebhookconfiguration 之后，应该重新启动已经被注入 Sidecar 的 Pod。

istio-system 命名空间中的 ConfigMap istio-sidecar-injector 中包含了缺省的注入策略以及 Sidecar 的注入模板。

策略

disabled - Sidecar 注入器缺省不会向 Pod 进行注入。在 Pod 模板中加入 sidecar.istio.io/inject 注解并赋值为 true 才能启用注入。

enabled - Sidecar 注入器缺省会对 Pod 进行注入。在 Pod 模板中加入 sidecar.istio.io/inject 注解并赋值为 false 就会阻止对这一 Pod 的注入。

参考：https://istio.io/zh/docs/setup/kubernetes/sidecar-injection/

Bookinfo示例部署

我们先下载下来istio的压缩包，其中samples目录中包含使用示例，我们使用其中的Bookinfo应用

使用下面命令可以创建Bookinfo应用的组件，部署在istio-demo命名空间下

kubectl create ns istio-demo

kubectl create -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml) --namespace=istio-demo 

如果您正在使用 启用了自动边车注入的群集，请使用 标记istio-demo命名空间istio-injection=enabled

$ kubectl label namespace istio-demo istio-injection=enabled

然后简单地使用部署服务 kubectl

$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml --namespace=istio-demo 

Bookinfo应用程序分为四个独立的微服务：

• productpage。该productpage微服务调用details和reviews微服务来填充页面。
• details。该details微服务包含图书信息。
• reviews。该reviews微服务包含了书评。它也称为ratings微服务。
• ratings。该ratings微服务包含伴随书评书排名信息。

reviews微服务有3个版本：

• 版本v1不会调用该ratings服务。
• 版本v2调用该ratings服务，并将每个评级显示为1到5个黑色星。
• 版本v3调用该ratings服务，并将每个评级显示为1到5个红星。

[外链图片转存失败(img-3oynzygM-1565423259305)(https://istio.io/docs/examples/bookinfo/withistio.svg)]

确定入口IP和端口

现在Bookinfo服务已启动并运行，您需要从Kubernetes集群外部访问应用程序，例如，从浏览器访问。一个Istio网关 用于此目的。

为应用程序定义入口网关：

$ kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml  -n istio-demo

确认已创建网关：

$ kubectl get gateway  -n istio-demo
NAME               AGE
bookinfo-gateway   32s

按照以下说明设置访问网关的INGRESS_HOST和INGRESS_PORT变量。当它们被设置时返回这里。

设置GATEWAY_URL：

$ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

Kiali——Istio Service Mesh 的可观察性工具

kiali安装只要在安装istio集群的时候，将value.yaml中的kiali设置为true就可以。

Kiali 提供的功能：

• 服务拓扑图
• 分布式跟踪
• 指标度量收集和图标
• 配置校验
• 健康检查和显示
• 服务发现

下图展示了 kiali 中显示的 Bookinfo 示例的服务拓扑图。

在dashboard中查看服务的地址，通过端口号即可登录到页面

Kiali 中的基本概念

在了解 Kiali 如何提供 Service Mesh 中微服务可观察性之前，我们需要先了解下 Kiali 如何划分监控类别的。

• Application：使用运行的工作负载，必须使用 Istio 的将 Label 标记为 app 才算。注意，如果一个应用有多个版本，只要 app 标签的值相同就是属于同一个应用。
• Deployment：即 Kubernetes 中的 Deployment。
• Label：这个值对于 Istio 很重要，因为 Istio 要用它来标记 metrics。每个 Application 要求包括 app 和 version 两个 label。
• Namespace：通常用于区分项目和用户。
• Service：即 Kubernetes 中的 Service，不过要求必须有 app label。
• Workload：Kubernetes 中的所有常用资源类型如 Deployment、StatefulSet、Job 等都可以检测到，不论这些负载是否加入到 Istio Service Mesh 中。

kiali架构

Kiali 部署完成后只启动了一个 Pod，前后端都集成在这一个 Pod 中。Kiali 也有一些依赖的组件，例如如果要在 Kiali 的页面中获取到监控 metric 需要使用在 istio-system 中部署 Prometheus。分布式卓总直接下图是 Kiali 的架构，来自 Kiali 官网。

Kiali 使用传统的前后端分离架构：

• 后端使用 Go 编写：https://github.com/kiali/kiali，为前端提供 API，所有消息使用 JSON 编码，使用 ConfigMap 和 Secret 来存储配置。直接与 Kubernetes 和 Istio 通信来获取数据。
• 前端使用 Typescript 编写：https://github.com/kiali/kiali-ui，无状态，除了一些证书保存在浏览器中。于查询后端 API，可以跳转访问 Jaeger 分布式追踪和 Grafana 监控页面。
  Jaeger 和 Grafana 都是可选组件，使用的都是外部服务，不是由 Kiali 部署的，需要在 kiali-configmap.yaml 中配置 URL。注意该 URL 必须是从你本地浏览器中可以直接访问到的地址。

注意：如果服务之间没有任何请求就不会在 Prometheus 中保存数据也就无法显示服务拓扑图，所以大家在部署完 Bookinfo 服务之后向 productpage 服务发送一些请求用于生成服务拓扑图。

Denier 适配器以及黑白名单

Bookinfo 示例中的每个微服务都包含了多个版本，所以首先要创建目标规则，为每个版本创建一个对应的服务子集。

如果没有启用双向 TLS，运行如下命令：

$ istioctl create -f samples/bookinfo/networking/destination-rule-all.yaml -n istio-demo

如果启用了双向 TLS，运行：

$ istioctl create -f samples/bookinfo/networking/destination-rule-all-mtls.yaml -n istio-demo

可以用下面的命令显示目标规则：

$ istioctl get destinationrules -o yaml  -n istio-demo

虚拟服务中引用的子集是依赖于目标规则的，因此需要等待几秒钟，让目标规则传播出去，然后再添加虚拟服务来引用这些子集。

初始化版本路由，对目标为 reviews 服务的请求，来自用户 “jason” 的请求分配给 v2 版本，其他请求分配到 v3 版本。

先把每个服务的缺省路由设置到 v1 版本，如果已经给示例应用创建了路由规则，那么下面的命令中应该使用 replace 而不是 create。

$ istioctl create -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

然后运行如下命令：

$ istioctl replace -f samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml  -n istio-demo

用浏览器打开 Bookinfo 的 productpage（http://$GATEWAY_URL/productpage）。

如果用 “jason” 的身份登录，就应该能看到每条 Review 都伴随着黑色的星形图标，这表明 ratings 服务是被 reviews 服务的 v2 版本调用的。

但如果使用其他用户登录（或者未登录），就会看到伴随 Review 的是红色的星星图标，这种情况下 ratings 服务是被 reviews 服务的 v3 版本调用的。

如果在之前的例子中遗留下了同名规则，则应使用 istioctl replace 而非 istioctl create。如果使用的命名空间不是 default，就需要用 istioctl -n namespace … 来指定命名空间。

简单的 Denier 适配器(拒绝来自指定服务的访问)

在 Istio 环境里，可以使用 Mixer 中的任何属性来对服务进行访问控制。这是一种简易的访问控制，使用 Mixer 选择器来有条件的拒绝请求。

比如 Bookinfo 示例应用中 ratings 服务会被多个版本的 reviews 服务访问。我们尝试切断来自 reviews:v3 的访问。

ratings 服务显式拒绝来自 reviews:v3 服务的调用。

运行下列命令设置一条拒绝规则，其中包含了一个 handler 以及一个 instance。

$ istioctl create -f samples/bookinfo/policy/mixer-rule-deny-label.yaml  -n istio-demo
Created config denier/default/denyreviewsv3handler at revision 2882105
Created config checknothing/default/denyreviewsv3request at revision 2882106
Created config rule/default/denyreviewsv3 at revision 2882107

着重关注 denyreviewsv3 规则中的这段内容（在mixer-rule-deny-label.yaml 文件中）：

match: destination.labels["app"] == "ratings" && source.labels["app"]=="reviews" && source.labels["version"] == "v3"

这段表达式匹配的条件是，来自服务 reviews，version 标签值为 v3 的，目标为 ratings 服务的请求。

这条规则使用 denier 适配器拒绝来自 reviews:v3 服务的请求。这个适配器会使用预定的状态码和消息拒绝请求。状态码和消息的定义可以参考 Denier 适配器的配置文档。

在浏览器中刷新 productpage 页面。

如果已经登出或者使用不是 “jason” 的用户身份登录，就无法看到评级图标了，这是因为 reviews:v3 服务对 ratings 服务的访问已经被拒绝了。反之，如果使用 “jason” 用户登录，因为这一用户使用的是 reviews:v2 的服务，不符合拒绝条件，所以还是能够看到黑色的星形图标。

whitelists 或者 blacklists（允许或拒绝指定登录用户的访问）

Istio 也支持基于属性的黑名单和白名单。下面的白名单配置和前面的 Denier 配置是等价的——拒绝来自 reviews:v3 的请求。

删除前文配置的 Denier 规则。

$ istioctl delete -f samples/bookinfo/policy/mixer-rule-deny-label.yaml   -n istio-demo

在登出状态下浏览 Bookinfo 的 productpage（http://$GATEWAY_URL/productpage），应该看到红星图标。在完成后续步骤之后，只有在使用 “jason” 的身份进行登录之后才能看到星形图标。

给 list 适配器创建配置，其中包含 v1, v2 两个版本。保存下面的 YAML 代码为 whitelist-handler.yaml：

apiVersion: config.istio.io/v1alpha2
kind: listchecker
metadata:
  name: whitelist
spec:
  # providerUrl: 通常会在外部管理列表内容，然后使用这一参数进行异步的抓取
  overrides: ["v1", "v2"]  # 用 overrides 字段提供静态内容
  blacklist: false

然后运行命令：

$ istioctl create -f whitelist-handler.yaml  -n istio-demo

创建一个 listentry 适配器的模板，用于解析版本标签，将下面的 YAML 代码段保存为 appversion-instance.yaml：

apiVersion: config.istio.io/v1alpha2
kind: listentry
metadata:
  name: appversion
spec:
  value: source.labels["version"]

接下来运行命令：

$ istioctl create -f appversion-instance.yaml -n istio-demo

为 ratings 服务启用 whitelist 检查功能，将下面的 YAML 代码段保存为 checkversion-rule.yaml：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: checkversion
spec:
  match: destination.labels["app"] == "ratings"
  actions:
  - handler: whitelist.listchecker
    instances:
    - appversion.listentry

然后运行命令：

$ istioctl create -f checkversion-rule.yaml  -n istio-demo

校验，在没有登录的情况下访问 Bookinfo 的 productpage（http://$GATEWAY_URL/productpage），应该是看不到星形图标的；如果使用 “jason” 用户登录，则应该看到黑星图标。

清理

移除 Mixer 配置：

$ istioctl delete -f checkversion-rule.yaml  -n istio-demo
$ istioctl delete -f appversion-instance.yaml  -n istio-demo
$ istioctl delete -f whitelist-handler.yaml  -n istio-demo

移除应用路由规则：

$ istioctl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml  -n istio-demo

移除应用目标规则：

如果没启用双向 TLS，需要运行如下命令：

$ istioctl delete -f samples/bookinfo/networking/destination-rule-all.yaml  -n istio-demo

如果启用了双向 TLS，则需要运行如下命令：

$ istioctl delete -f samples/bookinfo/networking/destination-rule-all-mtls.yaml  -n istio-demo

如果没有计划尝试后续任务，参考 Bookinfo 清理部分的介绍，关停示例应用。

启用速率限制

编辑istio-1.0.4/samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml文件中末尾修改为

spec:
  quotaSpecs:
  - name: request-count
    namespace: istio-system
  services:
  - name: ratings
    namespace: istio-demo
  - name: reviews
    namespace: istio-demo
  - name: details
    namespace: istio-demo
  - name: productpage
    namespace: istio-demo

把每个服务的缺省路由设置到 v1 版本，如果已经给示例应用创建了路由规则，那么下面的命令中应该使用 replace 而不是 create。

$ istioctl create -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

为 reviews 服务编写基于应用版本的路由，将来自 “jason” 用户的请求发送到版本 “v2”，其他请求发送到版本 “v3”。

$ istioctl replace -f samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml -n istio-demo

速率限制

istio 允许用户对服务进行限流。

假设 ratings 是一个像 Rotten Tomatoes® 这样的付费的外部服务，但是他提供了 1 qps 的免费额度可以使用。下面我们尝试使用 Istio 来确保只使用这免费的 1 qps。

用浏览器打开 Bookinfo 的 productpage 页面（http://$GATEWAY_URL/productpage）。

如果用 “jason” 的身份登录，应该能看到黑色评级图标，这说明 ratings 服务正在被 reviews:v2 服务调用。

如果用其他身份登录，就会看到红色的评级图标，这表明调用 ratings 服务的是 reviews:v3 服务。

为实现速率限制，需要配置 memquota、quota、rule、QuotaSpec 以及 QuotaSpecBinding 五个对象(这些对象会创建在istio-system命名空间)：

$ istioctl create -f samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml

检查 memquota 的创建情况：

$ kubectl -n istio-system get memquota handler -o yaml
apiVersion: config.istio.io/v1alpha2
kind: memquota
metadata:
  name: handler
  namespace: istio-system
spec:
  quotas:
  - name: requestcount.quota.istio-system
    maxAmount: 5000
    validDuration: 1s
    overrides:
    - dimensions:
        destination: ratings
        source: reviews
        sourceVersion: v3
      maxAmount: 1
      validDuration: 5s
    - dimensions:
        destination: ratings
      maxAmount: 5

memquota 定义了三个不同的速率限制。dimensions可以理解为属性，在没有 overrides 生效的缺省情况下，每秒限制 5000 请求、另外还定义了两个 overrides 条目。如果 destination 的值为 ratings，来源为 reviews 并且 sourceVersion 是 v3，限制值为每 5 秒 1 次；第二条 overrides 条目的条件是 destinatin 等于 ratings 的时候限制为每 10 秒 5 个请求。Istio 会选择第一条符合条件的 overrides（读取顺序为从上到下）应用到请求上。

确认 quota 的创建情况。

$ kubectl -n istio-system get quotas requestcount -o yaml
apiVersion: config.istio.io/v1alpha2
kind: quota
metadata:
  name: requestcount
  namespace: istio-system
spec:
  dimensions:
    source: source.labels["app"] | source.service | "unknown"
    sourceVersion: source.labels["version"] | "unknown"
    destination: destination.labels["app"] | destination.service | "unknown"
    destinationVersion: destination.labels["version"] | "unknown"

quota 模板为 memquota 定义了 4 个 demensions 条目（demensions理解为属性），用于在符合条件的请求上设置 overrides。destination 会被设置为 destination.labels[“app”] 中的第一个非空的值。可以在表达式语言文档中获取更多表达式方面的内容。

quota根据服务请求的情况得到source，sourceVersion，destination，destinationVersion这4个人自定义属性的值，在这4个属性送给memquota，memquota根据属性来限速。

确认 rule 的创建情况：

$ kubectl -n istio-system get rules quota -o yaml
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: quota
  namespace: istio-system
spec:
  actions:
  - handler: handler.memquota
    instances:
    - requestcount.quota

rule 通知 Mixer，使用 Instance requestcount.quota 构建对象并传递给上面创建的 handler.memquota。这一过程使用 quota 模板将 dimensions 数据映射给 memquota 进行处理。

确认 QuotaSpec 的创建情况：

$ kubectl -n istio-system get QuotaSpec request-count -o yaml
apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
  name: request-count
  namespace: istio-system
spec:
  rules:
  - quotas:
    - charge: "1"
      quota: requestcount

QuotaSpec 为上面创建的 quota 实例（requstcount）设置了 charge 值为 1。

确认 QuotaSpecBinding 的创建情况：

$ kubectl -n istio-system get QuotaSpecBinding request-count -o yaml
kind: QuotaSpecBinding
metadata:
  name: request-count
  namespace: istio-system
spec:
  quotaSpecs:
  - name: request-count
    namespace: istio-system
  services:
  - name: ratings
    namespace: istio-demo
  - name: reviews
    namespace: istio-demo
  - name: details
    namespace: istio-demo
  - name: productpage
    namespace: istio-demo

QuotaSpecBinding 把前面的 QuotaSpec 绑定到需要应用限流的服务上。因为 QuotaSpecBinding 所属命名空间和这些服务是不一致的，所以这里必须定义每个服务的 namespace。

在浏览器中刷新 productpage 页面。

如果处于登出状态，reviews-v3 服务的限制是每 5 秒 1 次请求。持续刷新页面，会发现每 5 秒钟评级图标只会显示大概 1 次。

如果使用 “jason” 登录，reviews-v2 服务的速率限制是每 10 秒钟 5 次请求。如果持续刷新页面，会发现 10 秒钟之内，评级图标大概只会显示 5 次。

所有其他的服务则会适用于 5000 qps 的缺省速率限制。

注意：istio-1.0.4版本的示例改成了reviews到ratings1秒只能访问1次的限制。

有条件的速率限制

在前面的例子中，ratings 服务受到的速率限制并没有考虑没有 dimension 属性的情况。还可以在配额规则中使用任意属性进行匹配，从而完成有条件的配额限制。

例如下面的配置：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: quota
  namespace: istio-system
spec:
  match: source.namespace != destination.namespace
  actions:
  - handler: handler.memquota
    instances:
    - requestcount.quota

如果一个请求的源服务和目的服务处于不同的命名空间，这个配额限制就会生效。

理解速率限制

在前面的例子中演示了 Mixer 根据条件对请求实施速率限制的过程。

每个有名称的 Quota 实例，例如前面的 requestcount，都代表了一套计数器。这一个集合就是所有 Quota dimensions 的笛卡尔积定义的。如果上一个 expiration 区间内的请求数量超过了 maxAmount，Mixer 就会返回 RESOURCE_EXHAUSTED 信息给 Proxy。Proxy 则返回 HTTP 429 给调用方。

memquota 适配器使用一个为亚秒级分辨率的滑动窗口来实现速率限制。

适配器配置中的 maxAmount 设置了关联到 Quota 实例中的所有计数器的缺省限制。如果所有 overrides 条目都无法匹配到一个请求，就只能使用 maxAmount 限制了。Memquota 会选择适合请求的第一条 override。override 条目无需定义所有 quota dimension， 例如例子中的 0.2 qps 条目在 4 条 quota dimensions 中只选用了三条。

如果要把上面的策略应用到某个命名空间而非整个 Istio 网格，可以把所有 istio-system 替换成为给定的命名空间。

清理

删除速率限制配置：

$ istioctl delete -f samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml

删除应用路由规则：

$ istioctl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

流量转移（导流）

一个常见的用例是将流量从一个版本的微服务逐渐迁移到另一个版本。 在Istio中，您可以通过配置一系列规则来实现此目标， 这些规则将一定百分比的流量路由到一个或另一个服务。 在此任务中，您将先分别向 reviews:v1 和 reviews:v3 各发送50%流量。 然后，您将通过向 reviews:v3 发送100％的流量来完成迁移。

应用基于权重的路由

首先，运行此命令将所有流量路由到 v1 版本的各个微服务。

$ istioctl create -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

在浏览器中打开 Bookinfo 站点。 URL为 http://$GATEWAY_URL/productpage，其中 $GATEWAY_URL是 ingress 的外部IP地址， 其描述参见 Bookinfo。

请注意，不管刷新多少次，页面的评论部分都不会显示评级星号。这是因为 Istio 被配置为将 reviews 服务的的所有流量都路由到了 reviews：v1 版本， 而该版本的服务不会访问带星级的 ratings 服务。

使用下面的命令把50%的流量从 reviews:v1 转移到 reviews:v3:

$ istioctl replace -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml -n istio-demo

等待几秒钟以让新的规则传播到代理中生效。

确认规则已被替换:

$ istioctl get virtualservice reviews -o yaml  -n istio-demo
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
  ...
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

刷新浏览器中的 /productpage 页面，大约有50%的几率会看到页面中出带红色星级的评价内容。这是因为 v3 版本的 reviews 访问了带星级评级的 ratings 服务，但v1版本却没有。

在目前的Envoy sidecar实现中，可能需要刷新 /productpage 很多次–可能15次或更多–才能看到流量分发的效果。您可以通过修改规则将90%的流量路由到v3，这样看到更多带红色星级的评价。

如果您认为 reviews：v3 微服务已经稳定，你可以通过应用此 virtual service 将100％的流量路由到 reviews：v3：

$ istioctl replace -f samples/bookinfo/networking/virtual-service-reviews-v3.yaml -n istio-demo

现在，当您刷新 /productpage 时，您将始终看到带有红色星级评分的书评。

了解发生了什么

在这项任务中，我们使用Istio的加权路由功能将流量从旧版本的 reviews 服务迁移到新版本。请注意，这和使用容器编排平台的部署功能来进行版本迁移完全不同，后者使用了实例扩容来对流量进行管理。

使用Istio，两个版本的 reviews 服务可以独立地进行扩容和缩容，并不会影响这两个版本服务之间的流量分发。

如果想了解支持自动伸缩的版本路由的更多信息，请查看使用 Istio 的 Canary Deployments 。

清理

删除应用程序路由规则。

$ istioctl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

配置请求路由（同一来源固定路由）

由于 Bookinfo 示例部署了三个版本的 reviews 微服务，因此我们需要设置默认路由。 否则，如果您当多次访问应用程序，您会注意到有时输出包含星级评分，有时又没有。 这是因为没有为应用明确指定缺省路由时，Istio 会将请求随机路由到该服务的所有可用版本上。

此任务假定您尚未设置任何路由。 如果您已经为示例应用程序创建了存在冲突的路由规则，则需要在下面的命令中使用 replace 代替 create。 请注意：本文档假设还没有设置任何路由规则

将所有微服务的默认版本设置为 v1。

$ istioctl create -f samples/bookinfo/networking/destination-rule-all.yaml -n istio-demo

如果您启用了 mTLS ，请运行以下代码

$ istioctl create -f samples/bookinfo/networking/destination-rule-all-mtls.yaml -n istio-demo

部署完上面的目的规则，我们在部署虚拟服务

$ istioctl create -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

在kubernetes中部署 Istio 时，您可以在上面及其它所有命令行中用 kubectl 代替 istioctl。 但请注意，目前 kubectl 不提供输入验证。

您可以通过下面的命令来显示已创建的路由规则和虚拟服务:

$ istioctl get virtualservices -o yaml -n istio-demo
$ istioctl get destinationrule -o yaml -n istio-demo

由于路由规则是通过异步方式分发到代理的，因此在尝试访问应用程序之前，您应该等待几秒钟，以便规则传播到所有 pod 上。

在浏览器中打开 Bookinfo 应用程序的 URL (http://$GATEWAY_URL/productpage)。 回想一下，在部署 Bookinfo 示例时，应已参照该说明设置好 GATEWAY_URL 。

您应该可以看到 Bookinfo 应用程序的 productpage 页面。 请注意， productpage 页面显示的内容中没有评分星级，这是因为 reviews:v1 服务不会访问 ratings 服务。

将来自特定用户的请求路由到 reviews:v2。

通过将来自 productpage 的流量路由到 reviews:v2 实例，为测试用户 “jason” 启用 ratings 服务。

$ istioctl replace -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml -n istio-demo

确认规则已创建：

istioctl get virtualservice reviews -o yaml -n istio-demo

在 productpage 网页上以用户 “jason” 身份登录。

您现在应该在每次评论旁边看到评分（1-5颗星）。 请注意，如果您以任何其他用户身份登录，您将会继续看到 reviews:v1 版本服务，即不包含星级评价的页面。

理解原理

在此任务中，您首先使用 Istio 将 100% 的请求流量都路由到了 Bookinfo 服务的 v1 版本。 然后再设置了一条路由规则，该路由规则在 productpage 服务中添加基于请求的 “end-user” 自定义 header 选择性地将特定的流量路由到了 reviews 服务的 v2 版本。

请注意，为了利用 Istio 的 L7 路由功能，Kubernetes 中的服务（如本任务中使用的 Bookinfo 服务）必须遵守某些特定限制。 参考 sidecar 注入文档了解详情。

在流量转移任务中，您将按照在此处学习的相同基本模式来配置路由规则，以逐步将流量从服务的一个版本发送到另一个版本。

清除

删除应用程序 virtual service。

$ istioctl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml -n istio-demo

如果您不打算探索任何后续任务，请参阅 Bookinfo 清理 的说明关闭应用程序。

熔断