在上一篇博客中对前面4个场景进行了练习，这篇博客将对后面的5个场景进行练习。具体场景信息如下所示，应用仍然采用istio官网的bookinfo应用。
六：通过开启Kiali，利用Promethues收集服务调用关系信息
6.1：安装Promethues，这里才用Istio官网下的yaml文件进行安装，yaml文件目录是(samples/addons/promethues.yaml)
6.2: 开启Kiali插件，这样可以通过Kiali插件收集服务间调用关系信息。Kiali的yaml文件在Istio官网的Sample目录下（samples/addons/kiali.yaml）。
6.3：将Kiali的svc修改成NodePort类型，这样可以在外网访问kiali服务。
6.4: 访问Kiali，可以在Graph menu下，看到bookinfo各微服务间调用关系。
七：实现灰度发布
7.1:查看bookInfo应用，可以发现review服务有3个版本。
7.2通过destination定义不同的subset,yaml文件地址在istio官网的这个目录
(samples/bookinfo/networking/destination-rule-all.yaml)
接着定义VirtualService来控制流量，有两个yaml文件，这两个yaml文件也在上面的目录下。
virtual-service-all-v1.yaml：将所有流量导入V1版本的reviews服务，V1版本的reviews不能显示星星的图标。
virtual-service-reviews-test-v2.yaml：如果登陆的用户是JASON，则将流量导入到V2版本上，而review的V2版本是能够显示星星的。这有点像，例如V2是新版本，对于尝鲜类用户，可以把V2版本的新功能让尝鲜用户先使用，收集反馈。v2的virtualservice规则如下所示：
7.3:规则生效后，访问productpage，可以看到如果用jason登录，则显示星星，说明访问的是V2.
八：故障注入，通过注入一些故障的手段来查看应用是否存在技术暗债。
Istio支持通过配置VertualService来注入一些例如延迟等故障，来查看服务是否有进行合理的容错处理。实际对于故障注入有专门的工具，例如chaosmesh，chaoslade，在后续的博客中会在混沌工程专栏专门介绍各类故障注入工具使用，故这里只做简要介绍。
8.1:例如这里注入返回555 code的100%的街口层故障错误。
8.2:例如注入100%的延迟7s的故障错误。
九：在VirtualService中配置超时时间、断路器等
9.1:访问reviews这个服务，如果响应时间超过0.5s，那么就返回超时错误
9.2:断路器规则配置小例子
kubectl apply -f - <
