官网
https://istio.io/latest/zh/docs/tasks/traffic-management/request-routing/
一、配置请求路由
应用默认目标规则
在使用 Istio 控制 Bookinfo 版本路由之前，您需要在目标规则中定义好可用的版本，命名为 subsets 。
运行以下命令为 Bookinfo 服务创建的默认的目标规则：
#如果没有启用双向 TLS，本次执行没有 kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml # 启用双向 TLS #kubectl apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml # 查看目标规则 kubectl get destinationrules -o yaml
应用 virtual service
要仅路由到一个版本，请应用为微服务设置默认版本的 virtual service。在这种情况下，virtual service 将所有流量路由到每个微服务的 v1 版本。
#1 运行以下命令以部署 virtual services: kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml #2 查看已定义路由 kubectl get virtualservices -o yaml #3 显示相应的 subset 定义 kubectl get destinationrules -o yaml
测试路由， 在访问只有 v1版本,Reviewer1
http://192.168.1.132:31877/productpage
===========================================
基于用户身份的路由
测试，自名为 Jason 用户 的所有流量将被路由到服务 reviews:v2。
Istio 对用户身份没有任何特殊的内置机制。productpage 服务在所有到 reviews 服务的 HTTP 请求中都增加了自定义的 end-user 请求头，从而达到了本例子的效果。
reviews:v2 是包含星级评分功能的版本。
部署
# 部署 kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml # 确认规则已经创建 kubectl get virtualservice reviews -o yaml
访问测试
# 依然是v1版本的 http://192.168.1.132:31877/productpage # 用户登录 jason 登录之后访问， 是黑色带星级评分的页面 http://192.168.1.132:31877/productpage
# 清除
kubectl delete -f samples/bookinfo/networking/virtual-service-all-v1.yaml
二、故障注入
注入 HTTP 延迟故障
为了测试微服务应用程序 Bookinfo 的弹性，我们将为用户 jason 在 reviews:v2 和 ratings 服务之间注入一个 7 秒的延迟。 这个测试将会发现一个故意引入 Bookinfo 应用程序中的 bug。
注意 reviews:v2 服务对 ratings 服务的调用具有 10 秒的硬编码连接超时。 因此，尽管引入了 7 秒的延迟，我们仍然期望端到端的流程是没有任何错误的。
部署
1 创建故障注入规则以延迟来自测试用户 jason 的流量：
kubectl apply -f samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml
2 确认规则已经创建
kubectl get virtualservice ratings -o yaml
测试延迟配置
1、通过浏览器打开 Bookinfo 应用。
http://192.168.1.130:31445/productpage
2、使用用户 jason 登陆到 /productpage 页面。
你期望 Bookinfo 主页在大约 7 秒钟加载完成并且没有错误。 但是，出现了一个问题：Reviews 部分显示了错误消息：
Sorry, product reviews are currently unavailable for this book.
3、查看页面的响应时间：
打开浏览器的 开发工具 菜单
打开 网络 标签
重新加载 productpage 页面。你会看到页面加载实际上用了大约 6s。
理解原理
你发现了一个 bug。微服务中有硬编码超时，导致 reviews 服务失败。
按照预期，我们引入的 7 秒延迟不会影响到 reviews 服务，因为 reviews 和 ratings 服务间的超时被硬编码为 10 秒。 但是，在 productpage 和 reviews 服务之间也有一个 3 秒的硬编码的超时，再加 1 次重试，一共 6 秒。 结果，productpage 对 reviews 的调用在 6 秒后提前超时并抛出错误了。
这种类型的错误可能发生在典型的由不同的团队独立开发不同的微服务的企业应用程序中。 Istio 的故障注入规则可以帮助您识别此类异常，而不会影响最终用户。
请注意，此次故障注入限制为仅影响用户 jason。如果您以任何其他用户身份登录，则不会遇到任何延迟。
三、流量转移
本任务将向您展示如何将流量从微服务的一个版本逐步迁移到另一个版本。例如，您可以将流量从旧版本迁移到新版本。
一个常见的用例是将流量从微服务的一个版本的逐渐迁移到另一个版本。在 Istio 中，您可以通过配置一系列规则来实现此目标。这些规则将一定比例的流量路由到一个或另一个服务。在本任务中，您将会把 50％ 的流量发送到 reviews:v1，另外，50％ 的流量发送到 reviews:v3。接着，再把 100％ 的流量发送到 reviews:v3 来完成迁移。
1、首先，运行此命令将所有流量路由到各个微服务的 v1 版本。
kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
2、访问测试访问都是 一版本的
http://192.168.1.130:31445/productpage
3、使用下面的命令把 50% 的流量从 reviews:v1 转移到 reviews:v3：
kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml
4、如果您认为 reviews:v3 微服务已经稳定，您可以通过应用 Virtual Service 规则将 100% 的流量路由 reviews:v3：
kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-v3.yaml
访问验证，都是v3版本
http://192.168.1.130:31445/productpage
=
卸载清理
# 删除路由规则 samples/bookinfo/platform/kube/cleanup.sh # 确认应用已经关停 kubectl get virtualservices #-- there should be no virtual services kubectl get destinationrules #-- there should be no destination rules kubectl get gateway #-- there should be no gateway kubectl get pods #-- the Bookinfo pods should be deleted
end..