32.云原生Istio流量管理之官网Bookinfo应用实战演示

云原生专栏大纲

文章目录

- 流量管理
- - 基于版本的路由配置
  - 基于 Http header 的路由配置
  - 故障注入
  - - 延迟故障注入
    - 异常故障注入
    - 故障注入测试
  - 比例分配流量
  - 请求超时
  - 熔断
  - - 什么是熔断
    - 创建 httpbin 服务
    - 创建访问者服务

流量管理

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

常见服务治理的问题：

服务发现：在动态的微服务环境中，如何实时地发现和注册新的服务实例？
负载均衡：如何在服务实例之间有效地分配请求流量，以实现高性能和高可用性？
容错处理：如何处理服务之间的故障，例如服务实例故障、网络故障等？
流量管理：如何控制服务间的请求流量，例如请求路由、流量分割、金丝雀发布等？
服务监控：如何实时地监控服务的性能和健康状况？
链路追踪：如何跟踪和分析分布式系统中的请求调用链？
安全性：如何确保服务之间的通信安全，例如身份验证、授权和加密？
策略执行：如何实施和管理服务治理的策略，例如限流、熔断、访问控制等？
配置管理：如何在服务之间统一和动态地管理配置信息？
服务编排：如何协调服务之间的交互，以实现复杂的业务流程？

基于版本的路由配置

Kubenetes Service 通过标签中的 app: reviews 来绑定对应的 Pod，

  selector:app: reviews

正常情况下，Kubernetes 会将客户端的请求以轮询的方式转发到 Deployment 中的 Pod。

三个不同的 Reviews Deployment 都带有相同的 app: reviews 标签，标记不同的版本。所以 Service 会把它们的 Pod 放到一起，VirtualService 会将流量以轮询的方式分发到每个版本中。
如何将流量划分到不同的版本服务中？
Istio 通过 DestinationRule 定义了应用的版本，使用 Istio DestinationRule 设置 reviews v1/v2/v3 版本的定义如下所示：

编写service_br.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: productpage
spec:host: productpagesubsets:- name: v1labels:version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: reviews
spec:host: reviewssubsets:- name: v1labels:version: v1- name: v2labels:version: v2- name: v3labels:version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: ratings
spec: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/v1alpha3
kind: DestinationRule
metadata:name: details
spec:host: detailssubsets:- name: v1labels:version: v1- name: v2labels:version: v2
---

部署br

kubectl -n bookinfo apply -f service_br.yaml

查看规则

# kubectl get destinationrules -o wide -n bookinfo
NAME          HOST          AGE
details       details       13s
productpage   productpage   13s
ratings       ratings       13s
reviews       reviews       13s

为微服务 productpage、ratings、details 定义 Istio VirtualService

因为它们都只有 v1 版本，所以在 VirtualService 中直接将流量转发的 v1 版本即可。
编写3vs.yaml，主要定义route目的地，若不定义则轮询方式访问，该三个微服务只有一个版本（此处也可不部署vs）

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: productpage
spec:hosts:- productpagehttp:- route:- destination:host: productpagesubset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- route:- destination:host: ratingssubset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: details
spec:hosts:- detailshttp:- route:- destination:host: detailssubset: v1
---

部署

kubectl -n bookinfo apply -f 3vs.yaml

reviews 服务，流量只进入v1版本配置

reviews_v1_vs.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: reviews
spec:hosts:- reviewshttp:- route:- destination:host: reviewssubset: v1

kubectl -n bookinfo apply -f reviews_v1_vs.yaml

查看vs

# kubectl get vs -n bookinfo
NAME          GATEWAYS               HOSTS             AGE
bookinfo      ["bookinfo-gateway"]   ["*"]             155m
details                              ["details"]       2m13s
productpage                          ["productpage"]   2m13s
ratings                              ["ratings"]       2m13s
reviews                              ["reviews"]       9s

访问测试

http://192.168.31.21:32666/productpage
此时无论怎么访问都不好出现星（v1版本没星星）

查看kiali链路图也可看到v2、v3没有流量

原理分析：

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

基于 Http header 的路由配置

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

编写reviews_v2_vs.yaml

将 header 带有 end-user: jason 的流量转发到 v2 中，其它情况依然转发到 v1 版本。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: reviews
spec:hosts:- reviewshttp:- match:- headers:end-user:exact: jasonroute:- destination:host: reviewssubset: v2- route:- destination:host: reviewssubset: v1

kubectl -n bookinfo apply -f reviews_v2_vs.yaml

登录访问测试

然后在页面中的右上角点击 Sign in 进行登录，账号密码都是 jason。此时登录无论怎么刷新都显示黑色星星（v2版本）

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

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

延迟故障注入

延迟故障注入用于在应答之前向请求添加指定的延迟时间。这可以测试应用程序在网络延迟或服务响应缓慢的情况下的表现。延迟故障注入配置如下：

http:  fault:  delay:  percentage:  value: 50.0  fixedDelay: 5s

延迟（delay）故障注入有两个主要属性。

percentage: 表示注入延迟的概率，取值范围为 0.0 到 100.0。例如，50.0 表示有 50% 的概率注入延迟。
fixedDelay: 表示注入的固定延迟时间，通常以秒（s）或毫秒（ms）为单位。例如，5s 表示 5 秒延迟。

异常故障注入

异常故障注入用于模拟请求失败的情况，例如 HTTP 错误状态码或 gRPC 状态码。这可以帮助测试应用程序在遇到故障时的恢复能力。以下是一个示例，演示了如何在 VirtualService 中添加一个异常故障注入：

http:  fault:  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 流被取消。

故障注入测试

编写ratings_vs.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- match:- headers:end-user:exact: jasonfault:delay:percentage:value: 100.0fixedDelay: 7sroute:- destination:host: ratingssubset: v1- route:- destination:host: ratingssubset: v1

访问测试

再次访问网页，因为超时，发现评论区已经加载不出来了

将ratings 服务恢复正常

kubectl -n bookinfo apply -f 3vs.yaml

注意kubectl -n bookinfo delete -f ratings_vs.yaml不是恢复，绑定关系是metadata:name: ratings，需更新。

比例分配流量

把 50% 的流量分配给 reviews:v1 和 reviews:v3

编写reviews_scale_v13_vs.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: reviews
spec:hosts:- reviewshttp:- route:- destination:host: reviewssubset: v1weight: 50- destination:host: reviewssubset: v3weight: 50

kubectl -n bookinfo apply -f reviews_scale_v13_vs.yaml

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

请求超时

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

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

编写reviews_timeout.yaml

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

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: reviews
spec:hosts:- reviewshttp:- route:- destination:host: reviewssubset: v2timeout: 0.5s

kubectl -n bookinfo apply -f reviews_timeout.yaml

注入延迟故障模拟超时

reviews 依赖于 ratings 服务，为了模拟这种超时情况，我们可以给 ratings 注入延迟故障。这样 ratings 会给所有请求都延迟 2s 才会返回响应，但是 reviews 要求所有请求 reviews 的流量在 0.5s 内响应。

kubectl -n bookinfo apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- fault:delay:percent: 100fixedDelay: 2sroute:- destination:host: ratingssubset: v1
EOF

访问测试

查看productpage 日志

恢复故障

kubectl -n bookinfo apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: reviews
spec:hosts:- reviewshttp:- route:- destination:host: reviewssubset: v1weight: 50- destination:host: reviewssubset: v3weight: 50
EOF
kubectl -n bookinfo apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- route:- destination:host: ratingssubset: v1
EOF

熔断

什么是熔断

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

熔断器模式的工作原理如下：

正常状态：熔断器处于关闭状态，允许请求通过（熔断器会监控请求的成功和失败率）。
故障检测：当失败率达到预先定义的阈值时，熔断器就会启动。
熔断状态：熔断器处于打开状态时，将拒绝所有新的请求，并返回错误响应。这可以防止故障级联和给故障服务带来更多的压力。
恢复状态：在一段时间后，熔断器会进入半打开状态，允许一部分请求通过。如果这些请求成功，则熔断器将返回到关闭状态；如果仍然存在失败请求，则熔断器继续保持打开状态。

使用熔断器模式可以提高微服务系统的弹性和稳定性。这些工具提供了熔断器模式的实现，以及其他弹性设计模式，如负载均衡、重试和超时等。

创建 httpbin 服务

部署httpbin

https://github.com/istio/istio/tree/release-1.11/samples/httpbin

kubectl -n bookinfo apply -f  httpbin.yaml

暴露httpbin

访问测试：

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

httpbin_circurt.yaml

apiVersion: networking.istio.io/v1alpha3
# （目标规则）用于定义访问特定服务的流量策略
kind: DestinationRule
metadata:name: httpbin
spec:# 指定了该规则适用于名为 httpbin 的主机host: httpbin# 允许为服务指定全局的流量策略，这些策略包括负载均衡设置、连接池设置、异常检测等。trafficPolicy: # 定义了连接池的配置，包括最大连接数限制connectionPool:tcp:maxConnections: 1 # 限制了 TCP 连接的最大数量为 1http:http1MaxPendingRequests: 1 # 限制了允许排队的最大 HTTP 请求数量为 1maxRequestsPerConnection: 1 # 限制了每个连接的最大请求数量为 1# 定义了异常检测的配置，用于检测出现异常的后端服务实例并对其进行隔离。outlierDetection:consecutive5xxErrors: 1 # 定义了允许的连续 5xx 错误次数为 1interval: 1s # 定义了异常检测的时间间隔为 1 秒baseEjectionTime: 3m # 定义了基础隔离时间为 3 分钟maxEjectionPercent: 100 # 定义了最大隔离百分比为 100%，表示当异常检测条件满足时，可以隔离的服务实例的最大比例为 100%

这个 DestinationRule 的配置限制了对名为 httpbin 的服务的流量，包括连接池的最大连接数限制和 HTTP 请求的限制，并配置了异常检测策略，以便在出现异常时对后端服务实例进行隔禽。

kubectl -n bookinfo apply -f  httpbin_circuit.yaml

创建熔断时也可以设置重试次数

    retries:attempts: 3perTryTimeout: 1sretryOn: 5xx

创建访问者服务

部署一个服务请求 httpbin，才能观察到熔断过程。Istio 官方推荐使用 fortio 。

编写fortio_deploy.yaml

apiVersion: v1
kind: Service
metadata:name: fortiolabels:app: fortioservice: fortio
spec:ports:- port: 8080name: httpselector:app: fortio
---
apiVersion: apps/v1
kind: Deployment
metadata:name: fortio-deploy
spec:replicas: 1selector:matchLabels:app: fortiotemplate: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: fortiospec:containers:- name: fortioimage: fortio/fortio:latest_releaseimagePullPolicy: Alwaysports:- containerPort: 8080name: http-fortio- containerPort: 8079name: grpc-ping

kubectl -n bookinfo apply -f  fortio_deploy.yaml

执行命令请求 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

或通过可视化界面进入到 fortio 容器中，执行命令请求 httpbin

/usr/bin/fortio curl -quiet http://httpbin:8000/get

模拟大量请求，触发熔断

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 熔断

编写productpage_circuit.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: productpage
spec:host: productpagesubsets:- name: v1labels:version: v1trafficPolicy:connectionPool:tcp:maxConnections: 1http:http1MaxPendingRequests: 1maxRequestsPerConnection: 1outlierDetection:consecutive5xxErrors: 1interval: 1sbaseEjectionTime: 3mmaxEjectionPercent: 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 200 -loglevel Warning http://192.168.31.21:32666/productpage

访问页面

发现被熔断了

删除熔断配置

kubectl -n bookinfo apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: productpage
spec:host: productpagesubsets:- name: v1DestinationRulelabels:version: v1
EOF

再次访问页面正常

再次fortio 测试 productpage 应用

kubectl -n bookinfo exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 20 -loglevel Warning http://192.168.31.21:32666/productpage

请求全部成功