OpenShift 4 之Service Mesh教程(5)- 跟踪访问后端服务超时

本文说明如何在Istio中的VirtualService中设置访问的timeout特性。将请求各发给后台backend-v1和backend-v2微服务,其中backend-v2返回会超过3秒,因此会超时。
OpenShift 4 之Service Mesh教程(5)- 跟踪访问后端服务超时_第1张图片
本文可在完成《OpenShift 4 之Service Mesh教程(3)- 用Kiali监控微服务运行》后进行操作。在开始正式操作前需要运行以下命令将运行应用的my-istio-app项目里的内容清空即可。

$ scripts/teardown.sh
  1. 部署上图中的frontend-v1和backend-v1微服务,以及相关服务。
$ oc apply -f ocp/frontend-v1-deployment.yml -n my-istio-app
$ oc apply -f ocp/frontend-service.yml -n my-istio-app
$ oc apply -f ocp/frontend-route.yml -n my-istio-app
$ oc apply -f ocp/backend-v1-deployment.yml -n my-istio-app
$ oc apply -f ocp/backend-service.yml -n my-istio-app

确认backend-v1-deployment.yml访问的是v1版的backend应用。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: backend-v1
  # labels:
  #   app: backend
  #   version: v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: backend
        version: v1
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      containers:
      - name: backend
        image: quay.io/voravitl/backend-js:v1
        imagePullPolicy: Always
        resources:
          requests:
            cpu: "0.1"
            memory: 60Mi
          limits:
            cpu: "0.2"
            memory: 100Mi
        env:
          - name: BACKEND_URL
            value: https://httpbin.org/status/200
        ports:
        - containerPort: 8080
  1. 运行命令,从返回结果确认可以访问到backend-v1微服务。
$ curl $FRONTEND_URL
Frontend version: v1 => [Backend: http://backend:8080, Response: 504, Body: upstream request timeout]
  1. 运行命令发测试请求。
$ scripts/run-50.sh
...
$ Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-pppzc, Elapsed Time:0.774024 sec
Backend:, Response Code: 504, Host:, Elapsed Time:3.193873 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-pppzc, Elapsed Time:0.787584 secBackend:, Response Code: 504, Host:, Elapsed Time:3.724406 sec
Backend:, Response Code: 504, Host:, Elapsed Time:3.147017 sec
Backend:, Response Code: 504, Host:, Elapsed Time:3.207459 sec
========================================================
Total Request: 50
Version v1: 25
Version v2: 0
========================================================
  1. 在Kiali控制台中查看微服务访问请求链和响应时间。
    OpenShift 4 之Service Mesh教程(5)- 跟踪访问后端服务超时_第2张图片
  2. 执行命令部署backend-v2微服务。
$ oc apply -f ocp/backend-v2-deployment.yml -n my-istio-app

确认backend-v2-deployment.yml访问的是v2版的backend应用。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: backend-v2
  # labels:
  #   app: backend
  #   version: v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: backend
        version: v2
      annotations:
        sidecar.istio.io/inject: "true"
    spec:
      containers:
      - name: backend
        image: quay.io/voravitl/backend-js:v2
        imagePullPolicy: Always
        resources:
          requests:
            cpu: "0.1"
            memory: 60Mi
          limits:
            cpu: "0.2"
            memory: 100Mi
        env:
          - name: BACKEND_URL
            value: https://httpbin.org/delay/5
            #value: https://httpbin.org/status/503
        ports:
        - containerPort: 8080
  1. 执行命令发测试请求,查看backend-v1和backend-v2的响应时间。可以看到是轮训访问这两个后台服务的,调用backend-v1的响应比较短(小于3秒),而调用backend-v2响应时间比较长(大于3秒)。
$ scripts/run-50.sh
...
Backend:v2, Response Code: 200, Host:backend-v2-7655885b8c-4l4xx, Elapsed Time:5.802549 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-kx7r7, Elapsed Time:0.799221 sec
Backend:v2, Response Code: 200, Host:backend-v2-7655885b8c-4l4xx, Elapsed Time:5.807315 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-kx7r7, Elapsed Time:0.830107 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-kx7r7, Elapsed Time:0.818900 sec
Backend:v2, Response Code: 200, Host:backend-v2-7655885b8c-4l4xx, Elapsed Time:5.823480 sec
...
  1. 在Kiali控制台中查看微服务访问请求链和响应时间。
    OpenShift 4 之Service Mesh教程(5)- 跟踪访问后端服务超时_第3张图片
  2. 执行命令创建DestinationRule。
$ oc apply -f istio-files/destination-rule-backend-v1-v2.yml -n my-istio-app
  1. 在Kiali控制台中查看微服务访问请求链,此时请求访问路径和(7)看到的是一样的。这是因为destination-rule-backend-v1-v2.yml中的DestinationRule只是定义了当有backend-v1和backend-v2有多个运行pod实例的ROUND_ROBIN的分发策略,而请求在backend-v1和backend-v2之间轮序不是由上面的DestinationRule定义的。
  2. 确认在virtual-service-backend-v1-v2-50-50-3s-timeout.yml中VirtualService中为微服务定义了3秒的timeout。然后执行命令创建一个VirtualService。
$ oc apply -f istio-files/virtual-service-backend-v1-v2-50-50-3s-timeout.yml -n my-istio-app
  1. 执行命令发测试请求。可以看到backend-v2响应时间比较长(大于3秒)已经按照“Response Code: 504”处理了。
$ scripts/run-50.sh
...
Backend:, Response Code: 504, Host:, Elapsed Time:3.008774 sec
Backend:, Response Code: 504, Host:, Elapsed Time:3.007154 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-kx7r7, Elapsed Time:1.078945 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-kx7r7, Elapsed Time:0.823204 sec
Backend:v1, Response Code: 200, Host:backend-v1-6ddf9c7dcf-kx7r7, Elapsed Time:0.824504 sec
Backend:, Response Code: 504, Host:, Elapsed Time:3.009229 sec
...
  1. 在Kiali控制台中查看微服务访问请求链和响应时间。其中由于发给backend-v2的请求会由于超时而被系统标记为红色。
    OpenShift 4 之Service Mesh教程(5)- 跟踪访问后端服务超时_第4张图片

你可能感兴趣的:(OpenShift,4,ServiceMesh,微服务)