如何确认外部服务（ServiceEntry和VirtualService）的断路（通过DestinationRule）是否在起作用

Question

问题摘要

我试图为我的网格外部的外部端点强加断路器参数，该外部端点托管在其他地方。但是，似乎并没有强加我设置的参数，因为当我期望HTTP 200响应会因HTTP 503失败而失败时，仍然可以成功获得HTTP 200响应。

工具版本为：

• Istio-1.2.4
• Kubernetes：v1.10.11
• Docker Dekstop版本2.0.0.3

值得注意的配置：

• global.outboundTrafficPolicy.mode是REGISTRY_ONLY。
• 网格内为mTLS。外部流量策略，TLS为DISABLED

相关资源

ServiceEntry

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-service
spec:
  hosts:
    - external-service.sample.com
  location: MESH_EXTERNAL
  exportTo:
    - "*"
  ports:
    - number: 80
      name: http
      protocol: HTTP
  resolution: DNS

VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: external-service-vs
spec:
  hosts:
    - external-service.sample.com
  http:
    - timeout: 200ms
      retries:
        attempts: 1
        perTryTimeout: 200ms
      route:
        - destination:
            host: external-service.sample.com
            port:
              number: 80

DestinationRule

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: external-service-dr
spec:
  host: external-service.sample.com
  trafficPolicy:
    tls:
      mode: DISABLE
    connectionPool:
      tcp:
        maxConnections: 1
        connectTimeout: 200ms
      http:
        http2MaxRequests: 1
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
        maxRetries: 1
        idleTimeout: 200ms
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

测试

我在网格内注入了Envoy代理的应用程序。该应用程序基本上只为HTTP1.1 GET external-service.sample.com/endpoint运行并发负载。

我调整应用程序中的并发用户数（1到10）和每个用户每秒的请求数（1到20）。

我期望响应随着斜坡上升而开始失败。但是事实并非如此。我一直都成功。

关键问题

1. 如果您看到非常刺眼的东西，请指出。

2. 我已经从Envoy代理中检查了日志和/ stats（发送请求和响应）。我还需要检查其他哪些istio日志以进一步了解istio是否对请求进行了处理并评估了目的地规则？

Answer 1

除了Istio Mixer从嵌套的Envoy实例中收集的统计数据之外，您还可以考虑从Envoy Access logs获取电路断路器事件。

自从跨Istio网格平面进行访问日志记录enabled以来，您就可以提取相关的断路器日志条目，并按特定的响应flags进行区分：

  

UO：除了503响应外，上游溢出（断路）   代码。

并从容器的特使代理访问日志中获取记录，即：

[2019-09-18T09:49:56.716Z] "GET /headers HTTP/1.1" 503 UO "-" "-" 0 81 0 - "-"

Answer 2

我还没有真正直接解决这个问题。 但是，我从一开始就通过设置istio重新完成了整个设置。之后，它已经抛出了预期的HTTP 503。

要知道断路器的状态，这比挑战更具挑战性。应该有一个ticket记录下来，但是似乎还没有针对这种功能的开发。

尽管如此，在进行验证时，我确实查看了一些遥测指标以了解断路器的状态。我认为这种方法会更好，因为我只想知道电路是一次闭合还是断开，而不是根据多个输入数据进行分析。

谢谢。