Istio 入门（五）：访问控制和流量管理

Istio 入门（五）：访问控制和流量管理
本教程已加入 Istio 系列：https://istio.whuanle.cn
目录
- 4，流量管理
  基于版本的路由配置
  基于 Http header 的路由配置
  故障注入
  两种故障注入
  比例分配流量
  请求超时
  熔断
  什么是熔断
  创建 httpbin 服务
  创建访问者服务
  创建 productpage 熔断
  清理
4，流量管理

主要演示了使用 Istio Gateway、VirtualService 对外暴露服务的访问地址，以及基于 Istio 实现可观察性的 Kiali 组件。让我们回在上一章中部署的 bookinfo 示例已经学习了什么：
- 使用 Istio Gateway 创建 “站点”；
- 使用 Istio VistualService 暴露 Kubernetes Service，并指定暴露的路由后缀。
- 使用 Kiali 收集服务间的指标。
通过快速练习，我们学到了如何在 Istio 中暴露服务，以及只暴露部分 API。可是只暴露服务并没有太大的用处，因为市面上各种网关都可以做到，并且功能更加丰富。

在微服务系统中，我们会碰到很多关于服务治理的问题，下面是笔者从 ChatGPT 中获取到的一些关于服务治理常见的问题。
1. 服务发现：在动态的微服务环境中，如何实时地发现和注册新的服务实例？
2. 负载均衡：如何在服务实例之间有效地分配请求流量，以实现高性能和高可用性？
3. 容错处理：如何处理服务之间的故障，例如服务实例故障、网络故障等？
4. 流量管理：如何控制服务间的请求流量，例如请求路由、流量分割、金丝雀发布等？
5. 服务监控：如何实时地监控服务的性能和健康状况？
6. 链路追踪：如何跟踪和分析分布式系统中的请求调用链？
7. 安全性：如何确保服务之间的通信安全，例如身份验证、授权和加密？
8. 策略执行：如何实施和管理服务治理的策略，例如限流、熔断、访问控制等？
9. 配置管理：如何在服务之间统一和动态地管理配置信息？
10. 服务编排：如何协调服务之间的交互，以实现复杂的业务流程？
前面的章节提到过， Istio 是服务治理的工具。所以，在本章中，将会介绍 Istio 的流量管理能力，来解决微服务中关于服务治理的部分问题。

Istio 的流量管理模型源于和服务一起部署的 Envoy，网格内 Pod 中的应用发送和接收的所有流量（data plane流量）都经由 Envoy，而应用本身不需要对服务做任何的更改，这对业务来说是非侵入式的，却可以实现强大的流量管理。

【不要点了，这只是一张图片】
基于版本的路由配置

在第三章访问的 http://192.168.3.150:30666/productpage?u=normal 地址中，我们每次刷新得到的结果都不一样。

因为 Kubenetes Service 通过标签中的 app: reviews 来绑定对应的 Pod，正常情况下，Kubernetes 会将客户端的请求以轮询的方式转发到 Deployment 中的 Pod，VirtualService 也是如此。
```
  selector:
    app: reviews
```
三个不同的 Reviews Deployment 都带有相同的 app: reviews 标签，所以 Service 会把它们的 Pod 放到一起，VirtualService 会将流量以轮询的方式分发到每个版本中。
```
  labels:
    app: reviews
    version: v1
    
  labels:
    app: reviews
    version: v2
    
  labels:
    app: reviews
    version: v3
```
所以，流量进入 Reviews VirtualService 之后，会被 Kubernetes 均衡地分配到各个 Pod 中。接下来我们将会使用按照版本的形式将流量划分到不同的版本服务中。

Istio 通过 DestinationRule 定义了应用的版本，使用 Istio DestinationRule 设置 reviews v1/v2/v3 版本的定义如下所示：
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
```
看看就行，不用执行命令。

这看起来非常简单， DestinationRule 没有什么特别的配置。通过 name: v1 定义版本，通过 labels 指定哪些符合条件的 Pod 划分到这个版本中。

接下来我们创建一个 yaml 文件，给书店微服务的四个应用都创建一个 DestinationRule 。

service_version.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
```
```
kubectl -n bookinfo apply -f service_version.yaml
```
执行命令查询更多信息
```
$> kubectl get destinationrules -o wide -n bookinfo
NAME          HOST          AGE
details       details       59s
productpage   productpage   60s
ratings       ratings       59s
reviews       reviews       59s
```
接着我们为三个微服务 productpage、ratings、details 定义 Istio VirtualService，因为它们都只有 v1 版本，所以在 VirtualService 中直接将流量转发的 v1 版本即可。

3vs.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1
---
```
```
kubectl -n bookinfo apply -f 3vs.yaml
```
host: reviews 使用 Service 的名称。如果这样填写，该规则只能应用于当前命名空间的 Service，如果需要将流量引导到其它命名空间的 Service，则需要使用完整的 DNS 路径，如：reviews.bookinfo.svc.cluster.local。

而对于 reviews 服务，我们在 VirtualService 只将流量转发到 v1 版本，忽略 v2、v3。

reviews_v1_vs.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
```
```
kubectl -n bookinfo apply -f reviews_v1_vs.yaml
```
然后我们查看所有的 VirtualService 。
```
$> kubectl get vs -n bookinfo
NAME          GATEWAYS               HOSTS                                AGE
bookinfo      ["bookinfo-gateway"]   ["*"]                                76m
details                              ["details.bookinfo.svc.local"]       103m
productpage                          ["productpage.bookinfo.svc.local"]   103m
ratings                              ["ratings.bookinfo.svc.local"]       103m
reviews                              ["reviews"]                          103m
```
之后，无论怎么刷新 http://192.168.3.150:32666/productpage ，右侧的 Book Reviews 都不会显示星星，因为流量都转发到 v1 版本中，而 v1 版本是不会有星星的。

Istio 起作用的原理大概是这样的，首先是 istio-ingressgateway 将流量转发到 bookinfo 网关中，然后 productpage VirtualService 根据对应的路由规则，判断是否放通流量，最后转发到对应的 productpage 应用中。接着 productpage 需要访问其它服务例如 reviews，发出的请求会经过 Envoy，Envoy 根据配置的 VirtualService 规则，直接将流量转发到对应的 Pod 中。

基于 Http header 的路由配置

基于 Http header 的转发，是通过 HTTP 请求中的 header 值，将流量转发到对应的 Pod 中。

在本节中，我们将会通过配置 DestinationRule ，将 header 带有 end-user: jason 的流量转发到 v2 中，其它情况依然转发到 v1 版本。

将 reviews 的 DestinationRule 描述文件的内容改成：
```
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
```
完整的 YAML如下：
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
```
kubectl -n bookinfo apply -f reviews_v2_vs.yaml

然后在页面中的右上角点击 Sign in 进行登录，账号密码都是 jason。

此时 Book Reviews 一直显示星星。

如果我们查看 productpage 的日志：

productpage 将这个 header 头转发给 http://reviews:9080/ ，然后流量经过 Envoy 时，Envoy 检测到 Http header 中带有 end-user ，通过规则决定将流量转发到 reviews v2。在这个过程中并不需要 Service 参与。
- 经过上面的配置，下面是请求的流程：
  - productpage → reviews:v2 → ratings (针对 jason 用户)
  - productpage → reviews:v1 (其他用户)
当然，我们也可以通过 URL 的方式划分流量，例如 /v1/productpage 、/v2/productpage 等，在本章中，就不再赘述这些了，读者可以从官方文档中了解更多。

故障注入

故障注入是 Istio 模拟故障的一种手段，通过故障注入我们可以模拟一个服务出现故障的情况，然后从实际请求中看到出现故障时，整个微服务是否会乱套。通过故意在服务间通信中引入错误，例如延迟、中断或错误的返回值，可以测试系统在不理想的运行状况下的表现。这有助于发现潜在的问题，提高系统的健壮性和可靠性。

将前面部署的 ratings 的 VirtualService，改造一下。

ratings_delay.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    fault:
      delay:
        percentage:
          value: 100.0
        fixedDelay: 7s
    route:
    - destination:
        host: ratings
        subset: v1
  - route:
    - destination:
        host: ratings
        subset: v1
```
```
kubectl -n bookinfo apply -f ratings_delay.yaml
```
再次访问网页，发现评论区已经加载不出来了，因为超时。

两种故障注入

在 Istio 的 VirtualService 中，fault 配置用于注入故障，以模拟和测试应用程序在出现问题时的行为。主要有两种类型的故障注入：延迟（delay）和异常（abort）。

延迟故障注入

延迟故障注入用于在应答之前向请求添加指定的延迟时间。这可以测试应用程序在网络延迟或服务响应缓慢的情况下的表现。以下是一个示例，演示了如何在 VirtualService 中添加一个延迟故障注入：
```
  http:  
  - fault:  
      delay:  
        percentage:  
          value: 100.0  
        fixedDelay: 5s  
```
延迟（delay）故障注入有两个主要属性。
- percentage: 表示注入延迟的概率，取值范围为 0.0 到 100.0。例如，50.0 表示有 50% 的概率注入延迟。
- fixedDelay: 表示注入的固定延迟时间，通常以秒（s）或毫秒（ms）为单位。例如，5s 表示 5 秒延迟。
延迟故障注入的示例：
```
fault:  
  delay:  
    percentage:  
      value: 50.0  
    fixedDelay: 5s  
```
在这个示例中，delay 配置了一个 50% 概率发生的 5 秒固定延迟。

异常故障注入

异常故障注入用于模拟请求失败的情况，例如 HTTP 错误状态码或 gRPC 状态码。这可以帮助测试应用程序在遇到故障时的恢复能力。以下是一个示例，演示了如何在 VirtualService 中添加一个异常故障注入：
```
  http:  
  - fault:  
      abort:  
        percentage:  
          value: 100.0  
        httpStatus: 503 
```
也可以将延迟故障注入和异常故障注入两者放在一起同时使用。
```
  http:  
  - fault:  
      delay:  
        percentage:  
          value: 50.0  
        fixedDelay: 5s  
      abort:  
        percentage:  
          value: 50.0  
        httpStatus: 503 
```
虽然放在一起使用，但是并不会两种情况同时发生，而是通过 percentage 来配置出现的概率。

异常（abort）故障注入有四个主要属性。
- percentage: 表示注入异常的概率，取值范围为 0.0 到 100.0。例如，50.0 表示有 50% 的概率注入异常。
- httpStatus: 表示要注入的 HTTP 错误状态码。例如，503 表示 HTTP 503 错误。
- grpcStatus: 表示要注入的 gRPC 错误状态码。例如，UNAVAILABLE 表示 gRPC 服务不可用错误。
- http2Error: 表示要注入的 HTTP/2 错误。例如，CANCEL 表示 HTTP/2 流被取消。
异常故障注入的示例：
```
fault:  
  abort:  
    percentage:  
      value: 50.0  
    httpStatus: 503  
```
实验完成后，别忘了将 ratings 服务恢复正常。
```
kubectl -n bookinfo apply -f 3vs.yaml
```
比例分配流量

使用下面的配置，可以把 50% 的流量分配给 reviews:v1 和 reviews:v3：
```
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% 的几率会看到页面中带红色星级的评价内容。这是因为 reviews 的 v3 版本可以访问带星级评价，但 v1 版本不能。

请求超时

不同编程语言都会提供 http client 类库，程序发起 http 请求时，程序本身一般都会有超时时间，超过这个时间，代码会抛出异常。例如网关如 nginx、apisix 等，也有 http 连接超时的功能。

在 Istio 中，服务间的调用由 Istio 进行管理，可以设置超时断开。

我们可以为 reviews 服务设置 http 入口超时时间，当其它服务请求reviews 服务时，如果 http 请求超过 0.5s，那么 Istio 立即断开 http 请求。

reviews_timeout.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
    timeout: 0.5s
```
```
kubectl -n bookinfo apply -f reviews_timeout.yaml
```
因为 reviews 依赖于 ratings 服务，为了模拟这种超时情况，我们可以给 ratings 注入延迟故障。这样 ratings 会给所有请求都延迟 2s 才会返回响应，但是 reviews 要求所有请求 reviews 的流量在 0.5s 内响应。

给 ratings 设置延迟故障：
```
kubectl -n bookinfo apply -f - <
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percent: 100
        fixedDelay: 2s
    route:
    - destination:
        host: ratings
        subset: v1
EOF
```
我们再次刷新页面。

注：因为 productpage 是 Python 编写的，其代码中设置了请求失败后自动重试一次，因此页面刷新后 1 s 后才会完成，而不是 0.5s。

还有一点关于 Istio 中超时控制方面的补充说明，除了像本文一样在路由规则中进行超时设置之外，还可以进行请求一级的设置，只需在应用的对外请求中加入 x-envoy-upstream-rq-timeout-ms 请求头即可。在这个请求头中的超时设置单位是毫秒而不是秒。

现在让我们将本小节的故障清理掉，恢复正常的微服务。
```
kubectl -n bookinfo apply -f - <
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
EOF
kubectl -n bookinfo apply -f - <
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
EOF
```
熔断

什么是熔断

熔断（Circuit Breaking）是微服务架构中的一种重要的弹性设计模式，在微服务环境中，不同的服务存在依赖关系，当其中一个依赖的服务出现问题时，可能导致请求积压，从而影响到其他服务和整个系统的稳定性。比如说，B 服务来了 100 个请求，B 需要请求 100 次 A 服务，但是 A 服务故障了，那么每次失败时都会重试一次，那么整体上就一共请求了 200 次。这样就会造成很大的浪费。而熔断器可以检测到这种情况，当检测到 A 服务故障之后，一段时间内所有对 A 的请求都会直接返回错误。

熔断器模式的工作原理如下：
1. 正常状态：熔断器处于关闭状态，允许请求通过（熔断器会监控请求的成功和失败率）。
2. 故障检测：当失败率达到预先定义的阈值时，熔断器就会启动。
3. 熔断状态：熔断器处于打开状态时，将拒绝所有新的请求，并返回错误响应。这可以防止故障级联和给故障服务带来更多的压力。
4. 恢复状态：在一段时间后，熔断器会进入半打开状态，允许一部分请求通过。如果这些请求成功，则熔断器将返回到关闭状态；如果仍然存在失败请求，则熔断器继续保持打开状态。
使用熔断器模式可以提高微服务系统的弹性和稳定性。这些工具提供了熔断器模式的实现，以及其他弹性设计模式，如负载均衡、重试和超时等。

创建 httpbin 服务

接下来本节将会使用一个 httpbin 服务，这个服务代码可以在 istio 官方仓库中找到： https://github.com/istio/istio/tree/release-1.17/samples/httpbin

创建一个 httpbin 服务。

httpbin.yaml
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  labels:
    app: httpbin
    service: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
      version: v1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      serviceAccountName: httpbin
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        ports:
        - containerPort: 80
```
```
kubectl -n bookinfo apply -f  httpbin.yaml
```
这里使用的 NodePort 只是为了分别预览访问，后续还需要通过 Gateway 来实验熔断。

然后查看 Service 列表。

通过浏览器打开对应的服务。

接着给 httpbin 创建一个 DestinationRule ，里面配置了熔断规则。

httpbin_circurt.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
```
```
kubectl -n bookinfo apply -f  httpbin_circuit.yaml
```
DestinationRule（目标规则）用于定义访问特定服务的流量策略。DestinationRule 配置中的 trafficPolicy 属性允许为服务指定全局的流量策略，这些策略包括负载均衡设置、连接池设置、异常检测等。

另外，我们在创建熔断时也可以设置重试次数。
```
    retries:
      attempts: 3
      perTryTimeout: 1s
      retryOn: 5xx
```
创建访问者服务

在 Istio 服务网格环境下，流量进入网格后会被 Envoy 拦截，接着根据相应的配置实现路由，熔断也是在 Envoy 之间实现的，只有流量经过 Envoy ，才会触发 Istio 的熔断机制。

上一小节中我们部署了 httpbin 应用，但是熔断是服务之间通讯出现的，所以我们还需要部署一个服务请求 httpbin，才能观察到熔断过程。Istio 官方推荐使用 fortio 。

部署 fortio 的 YAML 如下：

fortio_deploy.yaml
```
apiVersion: v1
kind: Service
metadata:
  name: fortio
  labels:
    app: fortio
    service: fortio
spec:
  ports:
  - port: 8080
    name: http
  selector:
    app: fortio
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fortio-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fortio
  template:
    metadata:
      annotations:
        # This annotation causes Envoy to serve cluster.outbound statistics via 15000/stats
        # in addition to the stats normally served by Istio. The Circuit Breaking example task
        # gives an example of inspecting Envoy stats via proxy config.
        proxy.istio.io/config: |-
          proxyStatsMatcher:
            inclusionPrefixes:
            - "cluster.outbound"
            - "cluster_manager"
            - "listener_manager"
            - "server"
            - "cluster.xds-grpc"
      labels:
        app: fortio
    spec:
      containers:
      - name: fortio
        image: fortio/fortio:latest_release
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
          name: http-fortio
        - containerPort: 8079
          name: grpc-ping
```
```
 kubectl -n bookinfo apply -f  fortio_deploy.yaml
```
部署 fortio 之后，我们进入到 fortio 容器中，执行命令请求 httpbin。

执行命令获取 fortio 的 Pod 名称：
```
export FORTIO_POD=$(kubectl get pods -n bookinfo -l app=fortio -o 'jsonpath={.items[0].metadata.name}')
```
然后让 Pod 容器执行命令：
```
kubectl -n bookinfo exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://httpbin:8000/get
```
如果上面的命令执行没问题的话，我们可以通过下面的命令对 httpbin 服务进行大量请求，并且分析请求统计结果。
```
kubectl -n bookinfo exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 20 -loglevel Warning http://httpbin:8000/get
```
在控制台中可以看到请求返回 200 和 503 的比例。

创建 productpage 熔断

在前面的小节中，我们使用了 httpbin 进行熔断实验，当然我们也可以给那些暴露到集群外的应用创建熔断。

这里我们继续使用之前的 bookinfo 微服务的 productpage 应用。

给 productpage 创建一个熔断规则：

productpage_circuit.yaml
```
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100
```
```
kubectl -n bookinfo apply -f productpage_circuit.yaml
```
然后我们使用 fortio 测试 productpage 应用，从 istio gateway 入口进行访问。
```
kubectl -n bookinfo exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 20 -loglevel Warning http://192.168.3.150:32666/productpage
```
然后删除 productpage 的熔断配置，重新恢复成一个正常的应用。
```
kubectl -n bookinfo apply -f - <
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1DestinationRule
    labels:
      version: v1
EOF
```
重新执行命令：
```
kubectl -n bookinfo exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 20 -loglevel Warning http://192.168.3.150:32666/productpage
```
通过打印的日志可以看出，不会再有 503 错误。

此时访问 http://192.168.3.150:32666/productpage ，页面也应恢复正常。

清理

本文明实验之后，可以执行命令清理以下服务：

然后我们清理 fortio：
```
kubectl -n bookinfo delete svc fortio
kubectl -n bookinfo delete deployment fortio-deploy
```
清理示例程序：
```
kubectl -n bookinfo delete destinationrule httpbin
kubectl -n bookinfo delete sa httpbin
kubectl -n bookinfo delete svc httpbin
kubectl -n bookinfo delete deployment httpbin
```
相关阅读:
vue项目打包成H5apk中使用语音播放
 大白话讲讲 Go 语言的 sync.Map（二）
【Linux】基本指令-入门级文件操作（一）
微服务改造过程中那些必须重视的问题
 常用黑客指令【建议收藏】
【408数据结构与算法】—堆排序（二十一）
小程序容器技术加持下，利好混合App开发
 ai批量剪辑矩阵无人直播一站式托管系统源头技术开发
 从本地到全球：跨境电商的壮丽崛起
 FPGA串口回环实验
原文地址：https://www.cnblogs.com/whuanle/p/17538681.html

4， 流量管理

基于版本的路由配置

基于 Http header 的路由配置

故障注入

两种故障注入

比例分配流量

请求超时

熔断

什么是熔断

创建 httpbin 服务

创建访问者服务

创建 productpage 熔断

清理

4，流量管理